Support locking even without files_lock

[juliusknorr]

For general WOPI compatibility it would be good to support locks even if the files_lock app is not enabled by implementing a custom locking table use for wopi.

[joshtrichards]

Any particular reason you're lean towards a fallback implementation versus just adding a setup check that gives an INFO or WARN level message when files_lock isn't installed alongside richdocuments?

Adding a parallel internal - and essentially duplicate - app-level locking mechanism just seems like more to maintain.

[joshtrichards]

For a setup check, maybe something like:

Warning: No WOPI-compatible locking provider found. Only lower level locking is available. WOPI-level locking behavior can be added by installing the files_lock app.

Maybe with the addition of a line like "This may {impact, case} [...]"

I always struggle with how to articulate the different layers of "locking" for an administrative / end-user audience (and myself!). Since we might want to link to an explanation in the docs, here's one I just spent some time on this evening (over a beer plus some back and forth with GPT-5.4 to refine):

richdocuments supports WOPI/app locking through Nextcloud’s ILockManager. When a compatible higher-level lock provider such as files_lock is available, WOPI lock requests can be honored and lock-scoped operations run in that lock context. Without such a provider, lock-scoped operations fall back to unlocked execution and explicit WOPI lock requests cannot be enforced, making WOPI-aware locking in richdocuments effectively a no-op. In that situation, protection is limited to Nextcloud’s lower-level path-based locking and any limited retry/conflict handling built on top of it. That is not a substitute for higher-level collaborative locking, especially when multiple users, clients, tabs, or sessions may interact with the same document concurrently.

Right now it's more developer-oriented than purely admin-level but I think it gets the key points across (and is a start).

[joshtrichards]

This may change things: nextcloud/server#60192

Though unless it's always enabled still relevant.