fix(files_sharing): stop ignoring shares without a usergroup entry when filtering by path

[artonge]

Previously, this was preventing users without a specific USERGROUP entry to see GROUP shares.

The path filtering is now done at resolution time. This is less efficient, but keeps the old behavior. (crossed out from Salvatore)

I think we should probably update the other share providers to follow the same logic.

[come-nc]

Won’t that cause an issue with non-accepted group shares?
Or if the user left the share?

Moving the path filtering to the resolve step would remove the filtering on the "parent" share, having the result of returning all shares received by a user where the only resolved ones are the ones where the path condition matches. This is not what we want.

[salmart-dev]

Edited the PR to avoid filtering by path only during the resolution step, as that would cause only the shares with a specific path to be resolved + would return shares unrelated to the path, since the first step would not filter by path any longer.

The new changes:

• keep the join query as a way to filter by path (customised paths are only present in the usegroup row, while the unchanged path can be present both in the usergroup or in the group rows, also the usergroup row could be missing but we still want the share)
• moved where clauses that belong to the to the join into the join condition instead of where
• changed the path query to target either file_target in s or in sc

This fixes the case where a share's permission get reduced because some usergroup rows may be missing for a specific share/user and others may be present resulting in incorrect permissions.

[provokateurin]

In all cases on master I am able to share and access the share and its contents

Try the same on stable33, there seem to be some things working on master that aren't working on stable33 for some reason.

[salmart-dev]

In all cases on master I am able to share and access the share and its contents

Try the same on stable33, there seem to be some things working on master that aren't working on stable33 for some reason.

Do you have more context? I can reproduce this issue also on stable33

[salmart-dev]

/backport to stable33

[come-nc]

I cannot see any problem anymore, does not mean there are none 🙈

[salmart-dev]

I will open a separate PR to apply the same changes to the deck provider, which also seems to have a wrong join condition

[salmart-dev]

Notes on the additional changes: we agreed with Louis and Kate to replace the _% LIKE query with /_% and remove the trailing slash from the path instead, to prevent confusion. I also adjusted the formatting.

[provokateurin]

Thanks!

[artonge]

@salmart-dev I can't approve, feel free to do so for me 👍