File locks are not respected by nextcloud office or for core actions (rename, move, delete) by the same user

Hello,

I just upgraded to Nextcloud 28.0.2 from 26.x

File locking behaves unexpectedly and inconsistently with respect to actions by the user who did the file lock.

Steps to reproduce

Scenario 1: Correct behaviour while locking and editing MD files

• User A creates a .md file with contents
• File is locked
• File cannot be edited by either User A or User B while locked. This is expected behaviour.

Scenario 2: Unexpected behaviour while locking and editing NC Office files

• User A creates a .odt file with contents
• User A locks for external editing via NC desktop client. User A is actively editing file in Libreoffice.
• User B is not able to edit the file using NC Office. This is expected behaviour.
• User A is able to edit the file using NC Office, and save new contents, creating collision with local editor. This is new and unexpected behaviour.

Scenario 3: Expected behaviour when editing starts in NC Office

• User A creates a .odt file with contents
• User A starts editing the file inside Nextcloud Office
• File shows icon with "locked by Nextcloud Office"
• File cannot be renamed, deleted, or edited locally by User A or B (appears as read-only in NC desktop client). User B is able to edit inside Nextcloud Office if the file is shared with them. This is expected behaviour.

Scenario 3: Unexpected behaviour with file operations while file is locked.

• User A creates any file
• User A locks file using web interface
• User B cannot move, rename, etc. This is expected behaviour.
• User A can still move, rename, etc. This is unexpected behaviour.

In all cases, I see the icon and generate a file lock which does appear in the database table (oc_files_lock).

According to Zendesk's bug severity guidelines, this bug would be classified as "High" severity as the feature does not behave as expected and causes data loss in certain cases.

Any ideas on how best to proceed in terms of further debugging or resolving this bug?

Versions:
Collabora 23.05.8.4
NC 28.0.2
Files_lock 28.0.1

tarek : )

Start by reproducing the three locking scenarios against Nextcloud 28.0.2, Collabora 23.05.8.4, and Files_lock 28.0.1, then inspect the oc_files_lock database entries while testing Office edits and rename, move, and delete actions. Done means a lock consistently prevents conflicting edits and core file operations according to the reported expectations, including for the user who created the lock.