Skip to content

Relax editing metadata on published/posted materials #10263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
asmecher opened this issue Jul 31, 2024 · 46 comments · May be fixed by #10335 or pkp/ui-library#398
Open

Relax editing metadata on published/posted materials #10263

asmecher opened this issue Jul 31, 2024 · 46 comments · May be fixed by #10335 or pkp/ui-library#398
Assignees
Milestone

Comments

@asmecher
Copy link
Member

Describe the bug
Currently, when content is published/posted in OJS/OMP/OPS, editors are restricted from making further changes:
image

In practice, however, editors want the ability to tweak/edit metadata in published content. This has led to anti-patterns like unpublish/edit/republish cycles.

In OMP, there is an additional problem, where certain data on Publication Formats can't be accessed/reviewed because the edit links disappear once the content is published.

Accepting that editors are going to want to tweak metadata after publication, we should keep the warning message present, but stop restricting edits. We should trust the editors to understand the implications of making edits, but not try to prevent it.

@asmecher asmecher added this to the 3.5.0 LTS milestone Jul 31, 2024
@Hafsa-Naeem Hafsa-Naeem self-assigned this Jul 31, 2024
@ewhanson
Copy link
Contributor

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.

@Hafsa-Naeem
Copy link
Contributor

@asmecher
Copy link
Member Author

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

@jardakotesovec
Copy link
Contributor

@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.

@ajnyga
Copy link
Contributor

ajnyga commented Sep 18, 2024

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.

@asmecher
Copy link
Member Author

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.

@jardakotesovec
Copy link
Contributor

@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.

@asmecher
Copy link
Member Author

asmecher commented Jan 7, 2025

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

@Hafsa-Naeem
Copy link
Contributor

@asmecher it needs to be reviewed

@asmecher
Copy link
Member Author

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

@defstat
Copy link
Contributor

defstat commented Jan 28, 2025

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

Hafsa-Naeem added a commit to Hafsa-Naeem/pkp-lib that referenced this issue Feb 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ui-library that referenced this issue Feb 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ui-library that referenced this issue Feb 28, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ui-library that referenced this issue Feb 28, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/pkp-lib that referenced this issue May 20, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ojs that referenced this issue May 20, 2025
Vitaliy-1 added a commit that referenced this issue May 21, 2025
#10263 Follow-up to clean up canEditPublication method per review feedback from PR#11225
@asmecher
Copy link
Member Author

@Vitaliy-1 and @Hafsa-Naeem, this one is still a blocker for 3.5.0-0, and needs some time for testing before we can get the release out. It looks like it's nearly ready, but please consider it a high priority!

@Hafsa-Naeem
Copy link
Contributor

Hafsa-Naeem commented May 22, 2025

@asmecher This has been merged to stable-3_5_0.

@asmecher
Copy link
Member Author

Excellent, thanks, @Hafsa-Naeem! Please don't forget the forward-port to main, if you haven't done that already.

@Tribunal33, this is ready for some testing as a high priority!

@Tribunal33
Copy link
Contributor

This passes QA. Couldn't find issues with it but hard to tell as there are no requirements. Even added the URN plugin to throw it for a loop. Seems solid. Here is the testing summary.

Test scenarios for OJS:

  1. As Editor, can make changes to submission in the published stage
  2. As Editor, the red warning message banner reads "Warning: This version has been published. Editing it may impact the published content."
  3. When changes are made and then Save button is selected no additional warning message appears and a green check mark appears by the button showing the changes have been saved.
  4. As Editor, all fields including language translations in the Title & Abstract can be altered and saved
  5. As Editor, Unpublish and Create new Version buttons still function normally
  6. As Editor, Top level action button View can see the published result changes.
  7. As Editor, Top Level action button Activity Log will display the Date, User and Event "Submission metadata updated"
  8. As Editor all options to modify Contributors can be saved
  9. As Editor, all Metadata keywords can still be added and saved
  10. As Editor, All JATS XML functionality works and previous saved changes are reflected in the generated JATS XML printout
    a. Can check for keyword updates done on previous test by using ctrl-f and finding the keyword.
  11. As Editor, All Galleys functionality works (can add a galley, view, change file, and delete)
  12. As Editor, all fields from Permissions & Disclosure can be updated and saved
  13. As Editor, all fields from Issue can be updated and saved and should be visible with View button (Journal display)
  14. As Editor, Adding new and clearing old URN Identifiers works (plugin needs to be installed).
  15. As Author it is locked down with the Save button being disabled and changes are not saved even though fields can be altered
  16. As Author the red warning message banner reads "This version has been published and can not be edited."
  17. Repeat all for OMP excluding those that don't apply
  18. Repeat all for OPS excluding those that don't apply

@Hafsa-Naeem
Copy link
Contributor

Hafsa-Naeem commented May 26, 2025

@Tribunal33 Thanks! I forward ported it to main and currently running tests on cypress, once they I'll close this PR 🙂

@asmecher
Copy link
Member Author

@Hafsa-Naeem Is this one ready to be closed?

@Vitaliy-1
Copy link
Contributor

Requires porting to main

@Vitaliy-1 Vitaliy-1 modified the milestones: 3.5.0 LTS, 3.6 May 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/pkp-lib that referenced this issue May 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ui-library that referenced this issue May 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ojs that referenced this issue May 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/ops that referenced this issue May 27, 2025
Hafsa-Naeem added a commit to Hafsa-Naeem/omp that referenced this issue May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment