Changing visibility to password-protected without entering a password does not warn user

[markel]

Tested on r15182.

If the status of a post is set to Password Protected, and a password is not specified before the user clicks the OK button in visibility and then either publishes, saves, or updates the post, no warning is given to the user that not setting a password forces the post or page to remain Public.

In fact, if updating a post, and this is the only change made, the success message (1) for updating the post appears instead, even though no change was made to the post.

If the post was previously published as Private, and switched to Password Protected without entering a password, then saved, the post switches to Public on save instead of remaining Private.

Either a failure message upon updating or a warning to the user before saving should be displayed to the user to remind them that they didn't properly set a password.

To reproduce the last case above:

1. Create a post. Publish it as Private.
2. Edit the post. Change the visibility to Password Protected, but do not enter a password. Click OK.
3. Update the post.
4. The post visibility will be changed to Public.

[kapeels]

Replying to markel:

Either a failure message upon updating or a warning to the user before saving should be displayed to the user to remind them that they didn't properly set a password.

I second this.

Would like to do this for gci.

[nacin]

A post that is private should not revert to public, either.

Making a GCI task.

[nacin]

Sorry for the delay on this.

Patch doesn't work.

[nacin]

Ideally, the "OK" button should simply be visually disabled and functionally not clickable unless there is a value in the password box.

On the button click, verify that there's a value. On the text box change, toggle the disabled class depending on there being a value.

No need for validation otherwise.

[kapeels]

This one has less green part and trims password before check

[nano8blazex]

I'm not sure how to edit post.js - compress post.dev.js into it or something. The patch attached only modifies post.dev.js but post.js needs to done too.

[nano8blazex]

As the GCI task was reopened, and I'm not really sure whether kapeels' patch works or not, I've just submitted another patch.

[westi]

Replying to nano8blazex:

As the GCI task was reopened, and I'm not really sure whether kapeels' patch works or not, I've just submitted another patch.

Marked as Completed.

This patch is cool really good UX improvement.

[nacin]

Might want a small JS cleanup on it, but that's it.

[MikeHansenMe]

Problem still exists. Patch needs a refresh, it did not prevent or notify me I had not entered a password.

[MikeHansenMe]

refreshed based on previous patch

[kovshenin]

Tested and did a little js cleanup in 13821.diff​. The disabling works for the OK button that is supposed to close the status area, however, the user can still update or save the post, so:

1. Publish a private post
2. Set the visibility to password protected, don't type in a password
3. Hit Update, your post is now public

We can either disable the Update/Publish/Save button just like we do with OK, or we can revert the post status to whatever was chosen previously (private in the above case) upon post save/publish, if the password was blank. I like reverting better than disabling buttons. Thoughts?

[samuelsidler]

Too late for 3.9, sadly. It's a decent amount of churn this late in the cycle. Let's get it early in 4.0.