Add a method to get all users with access to a file in OCP

[come-nc]

• Resolves: #

Summary

In a lot of places we need the list of users having access to a file, this is especially often the case in activity providers in applications, to notify all users of an event.
Currently the implementation is done differently each time, this is an attempt to bring a method in OCP that allows to get the list of users having access to a file and under which path.
For comments for example, this fixes showing the activity event to users having access to the file through a groupfolder.

TODO

• See if this is the right implementation
• Use it in all places that needs this feature
• Use it in applications where it makes sense, especially activity
• See how groupfolder ACLs could be integrated in there to avoid returning users which actually do not have access to the file

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[come-nc]

• Can this be added to the DI or is there a problem with that?

[icewind1991]

It might make more sense to move this method to the RootFolder instead

[come-nc]

Works nicely

[come-nc]

This already takes into account groupfolder ACLs, because $userFolder->getById($fileId) will return an empty array in this case.
What’s missing is a check for this to avoid returning an empty array for a user (in this case the user should not appear).

Also, the check if (isset($result[$mount->getUser()->getUID()])) { is problematic because it means for a user it will return only the first mount giving access to a file, but it should actually merge them.

That said, in the usecase of activity, which is the only one I found so far, we do not need to merge, we only want to get one path for each file. So I’m tempted to change the method to actually return only one path for each user who has access, as a string. This will make calling code a lot clearer.
The only usecase which needs more info is info:file command, to my knowledge.

[come-nc]

So in the end I splitted between getReadablePathByUserForFileId and getReadableNodesByUserForFileId.
The first one stops at first path found for each user, and is useful for activity listeners.
The second one is used by info:file command only for now, but I still think it’s nice to have it in OCP.

I would like to use getReadablePathByUserForFileId as well in https://github.com/nextcloud/activity/blob/master/lib/FilesHooks.php , but there IShareHelper::getPathsForAccessList is used, which returns paths for local users as well as remote users it seems, and I failed to figure out how to replace only the part for local users.
I failed to find the code filling $accessList['remotes'] so far.

But for comments and systemtags it works nicely with groupfolders now, even with ACLs. Let’s hope I did not break something else.

[come-nc]

I failed to figure out how to replace only the part for local users. I failed to find the code filling $accessList['remotes'] so far.

It’s

server/apps/federatedfilesharing/lib/FederatedShareProvider.php

Line 1090 in b78f3a5

public function getAccessList($nodes, $currentAccess) {

I missed it because I was searching for 'remotes', but in ShareHelper::getPathsForAccessList remote is turned into remotes actually.

(Thanks Robin for the pointer)

[ChristophWurst]

For the lib/public changes

[come-nc]

Rebased on master and fixed psalm errors

[icewind1991]

Looks good overall but I would like to ensure this is somewhat performant

[icewind1991]

I feel that there should be a more efficient way to do this here since we already know the mount.

Perhaps extracting some of the logic from RootFolder::getByIdInPath to create a RootFolder::getByIdInMounts or similar.

[icewind1991]

See #40482 (comment) for some alternate discussion around the same problem

[marcelklehr]

It seems that IUserMountCache#getMountsForFileId() does not include shares because they are not listed in oc_mounts. For shares we would need something like $shareManager->getAccessList in addition to the mounts. And for groupfolders we would need an additional piece altogether.

Something like this might work, but hopefully there's a less hacky way:

// Assuming you have the file ID
$fileId = 123; // replace with your actual file ID

// Get the root folder
$rootFolder = \OC::$server->getRootFolder();

// Get the file by ID
$file = $rootFolder->getById($fileId);

if ($file) {
    $filePath = $file->getPath();

    // Now we need to find the group folder ID associated with this path
    // Assuming the group folders are stored in a specific path, e.g., "/__groupfolders/<groupfolder_id>/..."
    preg_match('/\/__groupfolders\/(\d+)\//', $filePath, $matches);

    if (isset($matches[1])) {
        $groupFolderId = $matches[1];
    } else {
        throw new Exception('Group folder ID not found');
    }
} else {
    throw new Exception('File not found');
}

[icewind1991]

It seems that IUserMountCache#getMountsForFileId() does not include shares because they are not listed in oc_mounts

Shares should be listen in oc_mounts (once the recipient of the share has setup their filesystem)

[marcelklehr]

Aha! That explains a lot. I also used the wrong array concatenation method (:see_no_evil: ) so, groupfolders are afterall taken care of by this method, so: sorry for the noise, all good.

[marcelklehr]

Sad times.

[skjnldsv]

@marcelklehr if womeone wanna take over, or OP wanna work again on it, they can still re-open :)

[come-nc]

Reopening because we need to figure this out at some point, it’s causing trouble for groupfolders. The question is whether we can do that without making the experience worse in other places.

[come-nc]

Rebased