fix: Show lock status for read only files and allow unlocking

[juliusknorr]

Fix #305

There may be cases where a file is locked but the lock owner no longer has write permissions. This PR ensures that

• The unlock option is always available if possible
• We also always show the lock status (which was not the case before on read only files

[juliusknorr]

/backport to stable28

[juliusknorr]

/backport to stable29

[Mika-6-9]

Hi.
It seems to me that read-only should not be associated with a user, but should be an attribute that everyone should be able to put on or take off.
Otherwise we lock the file and we do not make the file read-only.

[Jerome-Herbinet]

Hi.
It seems to me that read-only should not be associated with a user, but should be an attribute that everyone should be able to put on or take off.
Otherwise we lock the file and we do not make the file read-only.

@juliushaertl what do you think about that comment ?

[juliusknorr]

Not sure I understand the suggestion correctly but the lock is ensuring that other users cannot write to the file, the lock owner still needs to be able to write it so I don't see why a separate read-only flag would make sense. It also makes things way more complex.

[Mika-6-9]

Hi.
The principle of read-only is that no one can write to the file, not even the one who set the read-only attribute.

the lock is ensuring that other users cannot write to the file, the lock owner still needs to be able to write it.

What you described @juliushaertl is the "classic" file locking function performed by the file_lock module.

[juliusknorr]

Then this would be a new feature, probably not related to the files_lock app, but I don't really see a use case. In any case maybe you can file this separately,.

[Mika-6-9]

Hi.
Should we just modify the current function a little?
The advantage of the files_lock app is that it already exists and is supported by the Nextcloud desktop application and that files are recognized as read-only when they are locked.
You "just" should not assign a user to this lock or a fictitious "read-only" user for example.

[juliusknorr]

Sorry, but while it might be a small code change this is a large logical change, so please file a separate feature request for this and also elaborate a bit on why this would be useful in terms of use cases. Then we can properly evaluate if that makes sense.