Multiple link shares and UI adjustments for share dialog

[ckamm]

See #5655

For servers that support it:

For older servers:

[pmaier1]

Great work! Fine for me as it is.

[SamuAlfageme]

This is a great PR, I like the new design of the sharing dialog a lot! 😊

There's some thoughts result of testing this for a bit now:

• Server sets the name of the file as default name of the public link.
• Links can be created in the web UI with no-name: some users might want just to create an old-school link share and now they're forced to set an explicit name.
• The "Create" button is enabled even when it does nothing, related with the previous points; maybe we can create a link with no explicit name and display the name from the "token" field on the response like the server does? (Also note that the server uses this value to list the public links when no name was set; the new dialog shows "Public link")
• When clicking a link on the list and "Password protect"/"Set expiration date" do update the link's properties but the name field still applies only for creating new links (update the textbox on click and change the button label to "Update" instead of "Create"?)
• Also, updating the link name by directly clicking its name on the list does not perform the PUT request to update the name on the server.
• Actions for each link are stacked in a drop menu (open, copy, send link), when there's enough room for them in the list view
• The detailed permissions are still shown on the "Users and Groups" tab (ref. ckamm@3d92c2c)

Again, this is an amazing change! 🎉

[ckamm]

@SamuAlfageme Thanks for checking it out, here are detail comments.

Server sets the name of the file as default name of the public link.

I didn't do this because then the nice help text in the edit box typically isn't visible. We could have a label and pre-fill the edit box as suggested. I'll try that.

Links can be created in the web UI with no-name: some users might want just to create an old-school link share and now they're forced to set an explicit name.

Why would someone go "I absolutely want a nameless link share!"? I doubt this is a real use-case and think having a straightforward default-name as you suggested above is sufficient.

The "Create" button is enabled even when it does nothing

Will fix.

display the name from the "token" field on the response like the server does? (Also note that the server uses this value to list the public links when no name was set; the new dialog shows "Public link")

I didn't realize it was still possible to create nameless links on the server. Then we must be consistent with the names displayed there. I didn't like the token-based name because it looked too technical, but believe consistency is more important.

the name field still applies only for creating new links (update the textbox on click and change the button label to "Update" instead of "Create"?)

The flow for creating/updating is hard to get right. If I did as you suggested and made the creation box do double duty as the name-edit box, one could not create new links unless there also was a way to deselect the current share: and it wouldn't be discoverable that deselecting was necessary to create more shares. I think the current way is comparatively clear. Adding a "Link properties" label might be helpful.

Also, updating the link name by directly clicking its name on the list does not perform the PUT request to update the name on the server.

Yes, there currently is no way of editing the name of a share. I'll look at it.

Actions for each link are stacked in a drop menu (open, copy, send link), when there's enough room for them in the list view

I used the menu because in my opinion it's easier to discover what the actions do this way, because there's obvious text. The button should probably get a "..." label to make it clearer more actions are hiding there. I have no strong opinion here.

The detailed permissions are still shown on the "Users and Groups" tab (ref. ckamm/owncloud-client@3d92c2c)

This patch was merged to 2.3 and hasn't yet been merged to master. It's just not included in this branch.

[ckamm]

@SamuAlfageme Updated with some fixes!

[SamuAlfageme]

@ckamm lookin' great 😎 I think it's good to be merged. Last comments:

The flow for creating/updating is hard to get right. [...] Adding a "Link properties" label might be helpful.

+1 to try how a label that separates somehow explicitly a "create" section from an "update" section; It might be also useful if possible to have the ability to deselect any entry on the table by clicking outside/on empty space.

I used the menu because in my opinion it's easier to discover what the actions do this way, because there's obvious text. The button should probably get a "..." label to make it clearer more actions are hiding there. I have no strong opinion here.

Agreed on the menu; however I think the most common use case for sharing links is to get copied, so a shortcut could also be nice.

And last difference with the web UI would be that there they have consecutive numbering on the name (by appending (n) to the link's default name) and we reuse the same name. I don't think this is necessary to be addressed at all.

As said, from an user's pov, this is good to go.

[guruz]

Code looks ok to me 👍

However

hudson.plugins.git.GitException: Command "git merge 8cb3a77022dfc8c688e3aeaf9fb08b6ddd305521" returned status code 1:
stdout: Auto-merging src/gui/shareusergroupwidget.cpp
Auto-merging src/gui/sharelinkwidget.ui
CONFLICT (content): Merge conflict in src/gui/sharelinkwidget.ui
Auto-merging src/gui/sharedialog.ui
CONFLICT (content): Merge conflict in src/gui/sharedialog.ui
Auto-merging src/gui/sharedialog.cpp
Automatic merge failed; fix conflicts and then commit the result.

[ckamm]

@guruz Rebased on top of master with some minor adjustments due to conflicting changes. I'll merge it now.