We had previously relied on the act of publishing (e.g. Repo::publication()->publish()) to indicate that metadata (new or changed) is available for downstream service to consume and used this as a jumping off point. By making it possible to edit this metadata post publication, I propose that we should treat each save event of the metadata as a MetadataChanged event and make use of the MetadataChanged and BatchMetadataChanged events.

I would propose a naive approach that simply always dispatches the MetadataChanged event when the form is saved/updated post publication, and let each individual implementation be in charge of deciding what metadata is important to process.

This approach has the advantage of using already existing events and jobs and allows any updates to happen asynchronously to the web request. It is also extensible for any future services or third-party plugins that need to know when metadata has been updated.

Examples of downstream services that would make use of this (either currently implemented or future implementations):

• Mark DOIs for a submission as stale. The DOI logic already handles resubmitting stale DOIs. This should already implemented for major the registration agencies we support.
• Update ORCID records for authenticated users in their ORCID profile. I don't think this has been implemented yet, but it could be added independently of this work.

@asmecher Ready for review
OJS_main:
ojs: pkp/pkp-lib#10263 Relax editing metadata on published/posted materials #4410
pkp/pkp-lib: pkp/pkp-lib#10263 edit metadata post publication #10335
pkp/ui-library: pkp/pkp-lib#10263 Relax editing metadata on published/posted materials #398

Thanks, @Hafsa-Naeem! @Vitaliy-1, would you be able to review this one?

@asmecher @Hafsa-Naeem On ui-library side of things this make sense to apply to the new side modal workflow page. Trying to get that side modal workflow page as default on main branch ASAP.. Its probably 2-4 weeks away.

This is a good change, because journals get stuck and create new versions easily without any good reason (correcting a typo etc.)

Just asking that when we now edit the metadata, is this visible in the editorial history? ie. do we stamp who did what? I think this is important especially after something has been published.

There would be an event in the event log, but if the editor chooses not to create a new version, the change will not be tracked.

Note that we'll be extending versioning further with #4860 -- description there.

@Hafsa-Naeem Hi Hafsa,
I am still active on this codebase, but risk of code conflicts is lot lower as most things are getting settled.

Permission to edit publication is now calculated here - https://github.com/pkp/ui-library/blob/main/src/pages/workflow/composables/useWorkflowPermissions.js#L70 . So that might be only place you need to adjust on frontend.

Let me know if you have any difficulties.

@Hafsa-Naeem, just checking in on the status of this one -- is it ready to resume?

@asmecher it needs to be reviewed

Thanks, @Hafsa-Naeem! @defstat, can you review this one?

@Hafsa-Naeem thanks. I have added a comment here regarding that.

@asmecher yes, this conversation was resolved as after the meeting discussion we decided on that: if any publication of the submission is published, we don't allow authors to make any changes to any publication of that submission, even if there are other unpublished version publications here. That’s why the fix ended up taking a different approach.

Let me quickly apply your suggested change and rebase to fix all the recent conflicts.

Thanks, @Hafsa-Naeem! All merged. Keeping this issue one as it also requires porting to the main

I've added extra comments to the PRs, but the only important thing is to avoid using ===/!== with non-string fields, due to a bug where the database values are retrieved as a string, until we come up with a generic fix.

@jonasraoni Thanks for the clean-up suggestions. Since the original branch has already been merged, I’ve opened a small follow-up PR 11386 to address the feedback