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.
But the user did the action that triggered the merge by changing the authority - I think it makes sense to record those.
(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.
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?
(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.
(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.
I believe we are using the background jobs here now - has this changed the situation?
(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.