Bug 22557 - Delayed authority merges looses the user in the action_logs
Summary: Delayed authority merges looses the user in the action_logs
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Authority data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Marcel de Rooy
QA Contact: Testopia
URL:
Keywords:
Depends on: 9988
Blocks:
  Show dependency treegraph
 
Reported: 2019-03-21 15:16 UTC by Tomás Cohen Arazi
Modified: 2023-09-25 11:32 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomás Cohen Arazi 2019-03-21 15:16:47 UTC

    
Comment 1 Marcel de Rooy 2020-01-10 09:07:51 UTC
Is it really a bug? If the merge is delayed, the user did not (technically) execute the merge so we could argue that he should not be listed as such in the log.
Comment 2 Katrin Fischer 2020-01-10 09:31:32 UTC
But the user did the action that triggered the merge by changing the authority - I think it makes sense to record those.
Comment 3 Marcel de Rooy 2020-01-10 09:34:12 UTC
(In reply to Katrin Fischer from comment #2)
> But the user did the action that triggered the merge by changing the
> authority - I think it makes sense to record those.

Yes, but the authority change itself has been recorded as such.
Comment 4 Katrin Fischer 2020-01-10 09:48:05 UTC
Yes, but it will not be so easy to see if the change recorded caused a merge (main heading was changed). I was just saying I see advantages of tracking the number.

I haven't checked how the merges show up in the logs, but I assume they might as updates on bibliographic records? (UPDATE?) Or can you see it was a merge caused update somehow?
Comment 5 Marcel de Rooy 2020-01-10 09:55:36 UTC
(In reply to Katrin Fischer from comment #4)
> Yes, but it will not be so easy to see if the change recorded caused a merge
> (main heading was changed). I was just saying I see advantages of tracking
> the number.
> 
> I haven't checked how the merges show up in the logs, but I assume they
> might as updates on bibliographic records? (UPDATE?) Or can you see it was a
> merge caused update somehow?

Differentiating them might be interesting and perhaps another solution direction?
I am not against passing the user to the automatic merge process, but not wanting to spend time on something that most people wont care about.
Comment 6 Katrin Fischer 2020-01-10 10:00:03 UTC
(In reply to Marcel de Rooy from comment #5)
> (In reply to Katrin Fischer from comment #4)
> > Yes, but it will not be so easy to see if the change recorded caused a merge
> > (main heading was changed). I was just saying I see advantages of tracking
> > the number.
> > 
> > I haven't checked how the merges show up in the logs, but I assume they
> > might as updates on bibliographic records? (UPDATE?) Or can you see it was a
> > merge caused update somehow?
> 
> Differentiating them might be interesting and perhaps another solution
> direction?

I agree, if you know the changes are 'heading merges' that might be enough. You could then check on the last change of the record that caused it.
Comment 7 Katrin Fischer 2023-09-23 21:20:41 UTC
I believe we are using the background jobs here now - has this changed the situation?
Comment 8 Marcel de Rooy 2023-09-25 11:32:19 UTC
(In reply to Katrin Fischer from comment #7)
> I believe we are using the background jobs here now - has this changed the
> situation?

No this is not done via background jobs. Separate cron job.
Report is still valid.