When password protecting a previously created public link displays password policy error, the checkbox will be unchecked

[saw-jan]

Steps to reproduce

1. Enable Password Policy app on the server
2. Set minimum password characters to 8 for public links (from Settings -> Admin -> Security)
3. From desktop-client, open public link sharing dialog for a file and create a public link share
4. Edit previously created public link
5. Enable (check) Password protect and enter password 1234
6. Click Set password
   (throws error The password is too short... and the checkbox will get unchecked but password filed can be edited)

Expected behavior

expected Password protect checkbox to be checked

Actual behavior

Password protect checkbox will get unchecked

Client configuration

Client version: 2.10.0rc3.6436
Operating system: win10x64

[erikjv]

The password checkbox is unchecked, because the password has not been set. However, I do agree that this behaviour is a bit confusing. I think we should change it to either of the two following:

• leave the checkbox checked, but disable the Close button when there is an error
• move the line edit for the password and the error label into a modal dialog (with ok a
  nd cancel buttons), and when pressed Ok, will disable all controls until it has a server response, then make the UI like this:

@TheOneRing What do you think?

[TheOneRing]

Scenario 1sounds good.
One issue with the share dialog is also that it creates a share, and you can only modify it later.
So if you close the dialog, it will still exists and not be password protected.

I think you are right once the checkbox is selected, the close button must be disabled.
Same for expiration.

[fmoc]

I tested the dialog a bit. Seems like keeping the checkbox checked and the password field filled with the old value is what we do when creating new shares, too. The only difference there is that we do not (have to?) disable the close button there, since the link just hasn't been created.

I'm actually in favor with moving the editing controls into a secondary dialog. IMO this increases the usability, since with a modal dialog one cannot change to another entry in the list for instance while the other one's changes are sent to the server (IMO a "save"/"commit" button is missing anyway for editing, changes should be done in a "transactional" way). What do you think?

For a short-term fix, I'm evaluating the first option which will be easier to implement. But long-term, I'd like to rework the share dialog.