Mutations should respect edit locks

[jasonbahl]

In the WordPress dashboard, when a user is editing a post, an edit lock is set on the post.

Any other user in the dashboard will see that another user is currently editing the post. They can take over, but it requires action on their behalf to acknowledge that they are going to override the other users changes.

WPGraphQL enables remote clients (editing content outside of the WP Dashboard). Those remote clients should have insight into who is editing the post (currently supported by WPGraphQL by querying the post's editLock field), but the remote client should also respect not editing a locked entity by default, without declaring intent to override.

I think mutations for nodes, starting with posts because WP has native locking for posts, should have an input $arg like ignoreEditLock => boolean! or something to that tune.

That way, default GraphQL mutations will throw an exception and return an error if the post is already locked and the mutation will not occur. This allows for remote clients to respect the lock by default. If there is intent to ignore the lock (like clicking the "take over anyway" modal in the WP Dash), then ignoreEditLock can be set to true in the mutation, and the mutation can succeed regardless of being locked

[CodeProKid]

I believe this is already working?

[jasonbahl]

@CodeProKid I'm not sure it actually is. 🤔

[CodeProKid]

I think it just changes the UI. It doesn't actually prevent an update mutation from happening. I'm not sure if that's the intention here or not.

[jasonbahl]

I think if a user submits a Mutation, during the execution of the mutation the EditLock should be checked, and if it's determined that another user owns the lock, we should prevent the mutation from proceeding.

In the age of headless WP, a user could be editing from any number of clients, not just the WP-Admin, and until we figure out how to add real-time UI updates across clients, the server should be responsible for checking the lock before proceeding with executing any changes.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[markkelnar]

I'm able recreate and confirm that a mutation does edit a post even when the post is actively being edited by another user in wp-admin.