After a user is removed from a group, shares from that user remain in groupfolders

[simon-eller]

Steps to reproduce

1. create a group and add user-a and user-b to it
2. create a groupfolder and share it to before created group
3. as user-a upload a file to the groupfolder and share the file within the groupfolder with user-c with all permissions
4. user-b and user-c are now able to edit the file
5. user-b can see that the file was shared to user-c
6. delete user-a from the group

Expected behaviour

Ideal solution

After the deletion of user-a from the group the share to user-c should be deleted and only user-b should have access to the file in the groupfolder.

Alternative solutions

• user-b should have the option to edit the shares or delete them.
• Or all shares of user-a should should be transfered to user-b

Actual behaviour

In the sharing options of the file user-b notices that user-c is not in the list of shared-with anymore but user-c still sees the shared file in his file list, can watch the preview and is able to comment this file. (comments also get displayed to user-b)

user-c would have to leave the share by himself but will he do it? ...

Reading out the metadata of the file is btw not possible and causes the following error.

An error occured while trying to read xmp-data: File by id 157 not found

Server configuration

Nextcloud version: (see Nextcloud admin page)
27.1.5

Group folders version:
15.3.4

[SignFinder]

I can confirm this unexpected behavior humble. NC 28.0.2, GF 16.0.4

[nikkilocke]

This is now a very serious issue. On Nextcloud 31.0.9.

If you share a file from a groupfolder (belonging to group A) to a different group (B), then leave group A, it leaves a dangling share, which has the following properties:

• Anyone from group B trying to access the share gets a failure
• Attempting to add a new person to group B results in a failure

Analysis of the database and source code reveals that:
1 - the dangling share (type 1) still exists, but the owner no longer has access to it, so attempts to access it throw an exception
2 - When a new person joins group B, the system attempts to create a type 2 share to the file for the individual user. This now fails, preventing the user from being added to the group properly
3 - If you attempt to create a new user in the API, and supply Group B in the groups[] parameter, the creation attempt returns an error (despite actually creating the user - not sure what their group membership ends up as).

There is a command occ sharing:delete-orphan-shares that will delete these orphan shares.

Clearly, when a user is removed from a group, the groupfolders app should remove all shares belonging to that user for files or folders inside the groupfolders that the person will no longer have access to.

[nikkilocke]

P.S. I can no longer create a new issue - does this mean that development and bug fixing for group folders is stopping?

[come-nc]

Now that #56498 is merged, it’s at least possible to delete dangling shares. But the UI is not great as the shares do not appear at first.

I think we need to decide whether shares should be deleted when a user is removed from a group associated with a groupfolder. I would say it makes sense that they are deleted. That would mean groupfolders application should listen to the event when a user is removed from a group and delete impacted shares.
But then we should also improve how we handle broken shares. Maybe they should be listed in the UI, and marked as broken. The only alternative I see is deleting them as we encounter them but that’s too risky in my opinion, they could be only temporarily broken because a storage is offline or something.

[nikkilocke]

What is #56498 and where can I see the code changes?
Does this fix the fact that you can no longer add anyone to the group until the share is deleted?

[provokateurin]

@nikkilocke nextcloud/server#56498