Support CRUD share permissions

[artonge]

Support fine-grained permissions for external shares of folders.

• This PR does not implement the new design suggested by 🤝 Improvement to sharing design and flow #26691.

Design change

Comment	-------------Before-------------	-------------After-------------	-------------After-------------
Before/After view. Note the new "Custom permissions" button at the bottom. When clicking on it, a new menu replaces the "Bundle permissions" view.

Comment	-------------------------------------	-------------------------------------
When clicking on "Custom permissions", a new view is displayed, showing the checked permissions reflecting the selected "Bundled permissions". Here, "Create" is checked because "File drop" was selected.
As expected, the user can check any set of permissions without limitation, except selecting none. When navigating back to the initial menu, no "Bundled permissions" is selected because none reflect the set of checked permissions. Underneath "Custom permissions", there is a summary of the selected permissions. This summary is currently also shown when a "Bundled permissions" is selected. When a set of custom permissions is selected, the "Custom permissions" view is opened by default.
The UI will prevent checking or unchecking permissions if the resulting permissions set is invalid. - UPDATE and DELETE need READ to be checked. - One of READ or CREATE must be checked at all times. If the permissions set somehow end up in an invalid state, some red outline are displayed.

Technical changes

• The SharePermissionsEditorVuejs element has been created to remove the logic from the gigantic SharingEntryLink.
• I changed the limitation on the allowed permissions sets in the ShareAPIController. See above tab for the allowed permissions set logic.

Interogation/Additional work

• Any argument in favour of hiding this new feature behind a config option as suggested in CRUD permissions for internal & external shares #30227?

Meta

Fix #30227
Fix https://github.com/nextcloud-gmbh/server/issues/118

[nimishavijay]

Really nice flow! Love it!
My only tiny bit of feedback would be that the wording "Bundle permissions" was a bit confusing to me, at first glance I thought it was an action that was to be applied.
I think it would be okay if there is no wording there, just the back icon, what do you think?

[artonge]

I think it would be okay if there is no wording there, just the back icon, what do you think?

It was the best that I could think of, and I wanted some wording because the user can have the "Custom permissions" view opened by default. Having no wording then might be non-intuitive, no? Maybe "Bundled permissions"?

But I have more trust in your opinion than mine on that matter ;)

[jancborchardt]

@artonge as per the comment at #30227 (comment), it would be nice if the "Custom permissions" is actually a submenu like in Deck which moves all the rest away, not just replaces some parts (because that way it’s a bit confusing).

[PVince81]

👍 code looks fine

[come-nc]

Looks good (not tested)

[artonge]

@artonge as per the comment at #30227 (comment), it would be nice if the "Custom permissions" is actually a submenu like in Deck which moves all the rest away, not just replaces some parts (because that way it’s a bit confusing).

As the user can have the "Custom permissions" view opened by default, wouldn't it be weird to hide all other fields?
Or I can remove the automatic opening of the "Custom permissions" view.

[nimishavijay]

because the user can have the "Custom permissions" view opened by default. Having no wording then might be non-intuitive, no?

Hmm, good point. In that case having some wording there makes sense. I think "Bundled permissions" sounds nicer :)
Also, noticed another thing here: we could maybe change the wording "Create", "Read", "Update", "Delete" so that it's more similar to the wording in the bundled permissions:

• Upload
• Read
• Edit
• Delete
  Will likely be easier for someone who is selecting these options :)

[artonge]

Labels updated to match Nimisha's suggestions.

@jancborchardt an opinion on my answer to your feedback?

[jancborchardt]

@artonge in which case would the custom permissions be opened by default? Was that specifically requested? (If not, I'd say yep let's remove it.)

Cause since they are custom they should stay behind a submenu like that, and behave as the submenu does in Deck.

[artonge]

@artonge in which case would the custom permissions be opened by default? Was that specifically requested? (If not, I'd say yep let's remove it.)

@jancborchardt In the case where custom permissions are selected. The user would be prompted with the custom permissions panel instead of the bundled permissions one, which would be empty. Not requested, but it felt better to me.

Also, keeping the other options visible prevent the resizing of the whole menu which feels clunky.

[jancborchardt]

@artonge ok, then it’s fine, especially as ideally it’s a stop-gap solution anyway before the new sharing flow comes in :) 👍

[artonge]

CI failure unrelated

[Alwaysin]

Thanks for this PR!

Does anyone know if it is going to be backported to 23?

[AndyScherzinger]

Does anyone know if it is going to be backported to 23?

We don't plan to backport it since we usually don't backport features but just bug fixes and security fixes but version 24 isn't that far away anymore :)