Allow to mention groupfolder users in file chats

[nickvergessen]

Fixes #2139

[danxuliu]

Tested with group folders and external storages and mentions now work.

However, there is a problem with external storages. After mentioning a user with access to the file through the external storage, but not through a share, the mentioned user will not be able to join the conversation (there will be an error and the conversation will be removed from the list).

Either mentioning other users with access to the file should be limited only to group folders or something similar to #2102 should be done for external storages too.

[danxuliu]

Integration tests are not happy.

[nickvergessen]

Rebased as CI result was purged

[nickvergessen]

Rebased once more, lets see

[nickvergessen]

Fixed the integration test and rebased

[nickvergessen]

Three last failing tests:

/drone/server/apps/spreed/tests/integration/features/conversation/files.feature:223
/drone/server/apps/spreed/tests/integration/features/conversation/files.feature:450
/drone/server/apps/spreed/tests/integration/features/conversation/files.feature:476

They all 3 assume that the owner of a file can no longer access a room of a file they joined before when there is no share anymore. From my POV that is not the expected behaviour and with default expiration date can cause unintended information loss. I would therefor change the expected result.
Did I misunderstand something? @danxuliu

[danxuliu]

Yes, currently if a share is removed the participants can no longer access the associated room.

From my point of view that is the right behaviour, though :-) After all the room is linked to a file, so if the user can no longer access the file I would not expect the user to be able to access the room either.

Having said that, yes, if a share expires that could lead to information loss. Maybe if a share is deleted/expired the room should be innaccessible for any other participant except the owner, just like the file itself? Although if the owner never joined the room that could be a problem... 🤔

[nickvergessen]

From my point of view that is the right behaviour, though :-) After all the room is linked to a file, so if the user can no longer access the file I would not expect the user to be able to access the room either.

Well the test cases we talk about are from owner side, so they can still access the file.

[danxuliu]

From my point of view that is the right behaviour, though :-) After all the room is linked to a file, so if the user can no longer access the file I would not expect the user to be able to access the room either.

Well the test cases we talk about are from owner side, so they can still access the file.

Right, I missed the owner part 🤦 Fine by me then.

[nickvergessen]

Updated the tests

[danxuliu]

I adjusted again the integration tests, as the tests for non-owner users no longer with access to the file (participant2) are already covered in their own scenarios. I also moved again "joins room" after "deletes shares" in the first scenario, as that ensures that the owner will be able to join the room after the share is deleted even if she was not in the conversation before.

Independently of that, I found an issue:

• As an admin, add user A and user B to a group
• As an admin, create an external storage for that group (and allow sharing in the external storage)
• In the regular window, log in as user A
• Open the Files app
• Open the shared folder and create a file
• In a private window, log in as user B (this is needed for the mount cache to be updated)
• In the regular window, reload the folder
• In the Chat tab for the new file, start/join the conversation
• Mention user B
• In the Sharing tab, share the file by link
• In the private window, open Talk and join the conversation
• As an admin, remove user B from the group
• In the private window, reload Talk and try to join the conversation again

The user will be kicked out from the conversation. However, if the shared link is opened user B will be able to join the conversation in the sidebar of the share page, and it will be possible to open the conversation directly from Talk from that point on. If instead of an external storage a group folder is used the same problem appears (although I would swear that I also saw it working with a group folder 🤷).

This should not be a very common scenario, though, so fine by me to move it to an issue and fix it at a later point.

[nickvergessen]

Tests passed, fixing up

[danxuliu]

Tested and works 👍 (except for the issue mentioned before, and another small issue mentioned below)

Besides the mentions, file rooms also work now for files in external storages 🎉

One detail worth noting (not a blocker, only something to keep in mind): if a user who is not logged in is added to a group that user will not appear in the mentions until the user logs in again. The opposite is true if the user is removed, that user will still appear as a candidate in the mentions until the user logs in again.

I guess this happens due to the use of the user mount cache, which I think that will not get updated until the file system is mounted again for the user.

Similarly, the need for a cache update might cause too some unexpected behaviours for freshly created external storages and group folders, like the storage/folder not being seen as accessible by a second user and thus not being able to start/join a conversation in a file until that second user reloads the page after the storage/folder was created and the file was added to it 🤷

Probably there is nothing that can be done about that, but I have no idea.

[nickvergessen]

That's acceptable and also happens with activities and file comments 🥴