Unlock button and dialog

[bastianallgeier]

Changelog

🎉 Features

New option to unlock changes

In some cases, the unlock expiry time of 10 minutes might be too long and you really want to take over the changes of another user. The new unlock button in the dropdown will make this possible. It's now bound to a new unlock permission for fine-grained control. In comparison to Kirby 4, this will no longer destroy and overwrite the existing changes. The unlocking user can simply pick off where the editor left and either keep on editing or discard those changes.

CleanShot.2025-07-24.at.13.37.47.mp4

This feature includes the following additions and enhancements to the core and panel:

• New Kirby\Content\Version::unlock() method
• New Kirby\Content\VersionRules::unlock() method
• New POST: /api/(:all)/changes/unlock route.
• New async panel.content.unlock() method.
• New is-unlockable prop for the <k-form-controls> component
• New onUnlock method for the ModelView base component
• All model view components pass the unlock permission to the form controls and hook up the unlock dialog.

🚨 Breaking changes

None

Docs

• New unlock permission and blueprint option for all models.

For review team

• Add lab and/or sandbox examples (wherever helpful)
• Add changes & docs to release notes draft in Notion

[distantnative]

@bastianallgeier what happens when this is done while the primary user is still editing?

[bastianallgeier]

@distantnative right now, the next save request would fail and bring up the "content is locked" error dialog.

With the continuous requests, we are already on a pretty safe side when it comes to bigger content loss. But we could still improve this by adding an additional shorter expiry time that needs to pass before the button gets active. E.g. when there are no more save requests for one minute, the button will work, otherwise it will still be blocked.

[distantnative]

@bastianallgeier I would say that'd be good. I could imagine weirder effects when someone is right in the middle of writing and someone else unlocks it (even thinking in terms of race conditions of the two requests).

But then again we could also ask ourselves if decreasing the limit form 10 to 1 minute in general would be just the solution, without this unlock button?

[distantnative]

@bastianallgeier Would you like to pursue this further? If so, shall I try to resolve the merge conflicts?

[bastianallgeier]

To be honest, your last comment really threw me off and I'm no longer sure if we actually need it, but we also did not move further with the idea to explore what happens with lower locking times.

[lukasbestle]

I think it depends on the UX on the other end (editing user A). The Panel of editing user A won't know that another user B has unlocked the page. So the new state will only be visible once user A starts being active again. This is not great.

So far we assumed that a user who wasn't active for 10 minutes was not going to continue working on the model, so it was a compromise to cover most cases well.

Idea: We could add a route that allows the editing user to clear the lock. We wouldn't need to add a button for this, it would automatically get called when the model view is closed (be it by navigating to another model or by closing the Panel entirely). This would cover the most common case of a user really leaving their work so another user can pick it up. This would leave the case of "editing user keeps the page open and grabs a meal", but not sure if that's a problem in real life. So with auto-unlocking, we maybe don't even need manual unlocking from the other side.