nextcloud
Provide the internal file id in the web UI of the Files app
Is your feature request related to a problem? Please describe. (unrelated to this issue either my Nextcloud instances have a common problem or Nextcloud 24 has a file locking problem with readme.md and files touched by Nextcloud Office remain locked "by {0}" indefinitely)
In order to use occ files:lock I need the file_id. Lately I need it often, most of the time triggered by something suddenly being locked in the Web UI. I would really ike to get an easy way to get a file_id for copying and pasting
Describe the solution you'd like Add a tab "internal information" to the file properties where this (and other interesting facts about a file required for occ commands) can be inspected and copied from. You could of course also add tools like forceful file unlocking (or clearing the entire locking database table) to an admin-only section of the right-click pop-up menu)
Describe alternatives you've considered Sitting in a corner and cry. There is no alternative to unlocking the files manually right now s I need the information.
Maybe a workaround for you :
The fileid is visible on the open link, so when you hover the file, you should see its id at the end of the URL :
https://cloud.yourcloud.com/index.php/apps/files/?dir=/&fileid=123456#
You can copy and edit the link to keep only the fileid, or just remember the id.
Note : it doesn't work for folders but you can see the folder fileid in the address bar after opening it.
I did not really think of that (because I'm mostly using the web UI with all browser elements turned off to save screen real estate) but that will do.
What if support was added to the files_lock app to accept either the file id or Nextcloud path, similar to the other occ files commands? - e.g.
www-data@7c80b1635751:~/html$ occ files:get --help
Description:
Get the contents of a file
Usage:
files:get <file> [<output>]
Arguments:
file Source file id or Nextcloud path
output Target local file to output to, defaults to STDOUT
OC\Core\Command\Info\FileUtils::getNode() already supports this syntax (example for above command). So could probably be readily adapted to here. And it would introduce some additional consistency across the occ files commands, which is always a good thing.
