We would need full locked article banner support for locking an article via the draft/v1/lock api.
How it currently works:
the editor opens an article
after that, the article is locked via the draft/v1/lock API
the editor is not aware and continues to edit the article
the editor tries to save an article and gets an undescriptive error that something went wrong, and the article cannot be saved or published
How we would like it to work:
the editor opens an article
after that, the article is locked via the draft/v1/lock API
the editor gets the standard banner that the article is locked same way as if another editor would took over in another composer session
The editor waits for the lock session to be over. After that, their composer is refreshed and the latest revision is shown.
Why would we like that?
We are building a tool to automate some very specific processes connected with our internal data that is not part of the ArcXP ecosystem.
After the article will be processed parts of it will be modified and a new article revision will be saved. For this to be a seamless process (otherwise, we will run into all sorts of process issues with our editorial teams), we would need the functionality mentioned above for various reasons. One of them is that we clearly show to the editor working on the piece that another process/user is editing the article.
The second one is to ensure the seamless flow for the editorial that will be using this external tool - they will always start from the composer - move to the external tool, and process the content - after that, the tool should release the lock and the editor should have their composer version refreshed with the latest revision processed by the tool.
J. T.
Hi J.T. Thanks for submitting this, the detailed scenario is very helpful. We are tentatively planning and ideating around improvements with API locking and will see how this might fit in int the future. Thank you!