[OJS 3.4] variable{$editorName} not replaced in activity log for decisions

[forgive38]

Describe the bug
When you take a decision, you see that in activity log

2024-09-03 Administrator Testdrive {$editorName} sent this submission back to the copyediting stage.
2024-09-03 Administrator Testdrive {$editorName} sent this submission to the production stage.

What application are you using?
OJS (testdrive 3.4 or 3.4.0.6)

[aleskl]

I can also see placeholders not populating in the Activity log, it seems to be specific for editors:

2024-10-09 {$editorName} requested revisions for this submission.
2024-10-09 Editor {$userName} has confirmed a review for the round 1 review for submission 3286.

What application are you using?
OJS 3.4.0.6

[kaitlinnewson]

PRs for review:

3.4:

• pkp-lib 3_4_0: pkp/pkp-lib#10362 include editorName when logging an editorial decision #10628
• OJS 3_4_0 (submodule update for tests only): [tests only] pkp/pkp-lib#10362 include editorName when logging an editorial decision ojs#4530

main:

• pkp-lib main: #10362 include editorName when logging an editorial decision #10646
• OJS main: #10362 include editorName when logging an editorial decision ojs#4535
• OMP main: #10362 include editorName when logging an editorial decision omp#1779
• OPS main: #10362 include editorName when logging an editorial decision ops#821

@Vitaliy-1 are you able to review?

This only covers cases of new editorial decisions being logged though, and there still may be missing or incorrectly named editorName values in the event_log_settings table - I can try another PR for migrations if it makes sense to do so.

For the cases where $userName is not populated, another option could be to replace $userName with $editorName in the locale files instead, but it looks like it was writing values to the DB as $userName in 3.3 so that will still lead to some other inconsistencies.

[Vitaliy-1]

Thanks! This also requires porting to main.

This only covers cases of new editorial decisions being logged though, and there still may be missing or incorrectly named editorName values in the event_log_settings table - I can try another PR for migrations if it makes sense to do so.

For 3.5 it makes sense. If we ever release 3.4.1, we can add migration there too.

For the cases where $userName is not populated, another option could be to replace $userName with $editorName in the locale files instead, but it looks like it was writing values to the DB as $userName in 3.3 so that will still lead to some other inconsistencies.

And for 3.2 it was $editorName? If it always was $userName, we can stick with it

[kaitlinnewson]

For PKPReviewerGridHandler, it was $userName in 3.3 and 3.2, and it was only $editorName in 3.4 - so in that case it makes sense to stick with it and migrate any discrepancies created in 3.4 for 3.4.1 (if released) and 3.5. I'll look at those next.

[kaitlinnewson]

@Vitaliy-1 I've forward-ported, added the migration, and listed the PRs above - ready for another review.

I made a small adjustment to change userName to editorName in the locales file instead, as I noticed this was changed in a previous PR in order to make it less ambiguous (in some settings in event_log_settings username refers to the account username and not the full name). In the DB it was migrated to editorName for 3.4 already so that part is covered for that event type (SUBMISSION_LOG_REVIEW_CONFIRMED).

[asmecher]

@kaitlinnewson / @Vitaliy-1, I'll leave this against the 3.4.0-8 release for a few more hours -- but I am planning to release that today, and will defer this to 3.4.0-9 if it's still outstanding by the afternoon. Up to you two whether you want to rush it.

[kaitlinnewson]

Hi @bozana, this is the issue I mentioned - would you be able to review? PRs are listed above and I've rebased. I see some test failures but I think they are unrelated. Thanks!

[bozana]

Hi @kaitlinnewson, the PRs look good. I left just two minor comments for the migration SQL.
I understand that the problem was that that setting was missing in the DB for the two event types.
Is there any problem with data being wrong in the DB?
Thanks a lot!

p.s. let me know if I should then immediately merge...

[kaitlinnewson]

Hi @bozana, for the 2 events SUBMISSION_LOG_EDITOR_RECOMMENDATION and SUBMISSION_LOG_EDITOR_DECISION, the data gaps in the DB are covered by the migration - and the data gap has only been present for 3.4.

For the SUBMISSION_LOG_REVIEW_CONFIRMED event, this fixes the locale files instead of touching the database, as it's just the locale files that were missed (the data for this event was migrated for 3.4).

[kaitlinnewson]

@bozana I adjusted based on your feedback for the migration and merged to main, just the 3.4 PR left to merge - thanks!