Problem/Motivation

In #2068063: Change "Save and keep un-/published" buttons to a "Published" checkbox and an included "Save" button we replaced the drop button with a "published" checkbox, however if a user doesn't have permission to publish content (or even view the checkbox) they don't know if clicking save will publish the content or not.

Proposed resolution

If the user doesn't have permission to change the publishing status, make them aware of what will happen when they click save.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

timmillwood created an issue. See original summary.

Manuel Garcia’s picture

So what would be the way to handle this, say for example if a user doesn't have permission to publish content, show the published checkbox as a disabled form element perhaps?

kiamlaluno’s picture

Since the linked issue uses a unique label for the Save button, I would say that showing a disabled checkbox for the Published status is what we should do.

timmillwood’s picture

Status: Active » Needs review
FileSize
707 bytes

Maybe it could work like this?

Manuel Garcia’s picture

Issue tags: +Needs usability review

@timmillwood that would definetly be one way to manage this situation. I'm not too convinced because we just removed that functionality, and also this will further complicate tests.

Tagging for usability review, as far as I can see we have a few ways to deal with this:

  • Display a message to the user in the line of "You are editing a published node, your edits will (not) be published."
  • Display a disabled checkbox to keep in line with what you'd see if you did have the right permissions.
  • Display a (un)Published status text in the place where the checkbox would appear.
  • Change the value of the submit button as proposed in #4
  • Any others?
timmillwood’s picture

Just as a note / reminder for me later, the access control for this field is handled in \Drupal\node\NodeAccessControlHandler::checkFieldAccess.

Status: Needs review » Needs work

The last submitted patch, 4: 2886569-4.patch, failed testing. View results

Berdir’s picture

Summery looks a bit as if this is a regression, but it really isn't, without administer nodes, users always only saw a save button.

Not trivial to improve as users might not need to know.

Not sure this is a bug. Maybe a UX bug but changes here should be backed by data/tests and thought about carefully as it might affect end users, not just privileged/admin users.

timmillwood’s picture

ah, thanks for the insight @Berdir, I kinda assumed users would see one of the buttons within the drop button.

This issue came to my attention when I saw a user using a Drupal 7 site where they only had the option to "Save" a node, with no context on if it would publish or not. They were really worried to press the button as they didn't want to mess up the site. Therefore I am looking to mitigate this issue by providing context.

CatherineOmega’s picture

I agree that this requires some thought, but I can say that this is something my employer's own internal user testing found just this month: that it wasn't at all intuitive to users from the button alone whether or not they were submitting a "job" node for review or automatically publishing it.

So obviously, we've overridden this for our specific application, and added more up-front help text, but I definitely think this is something that we should improve for core.

Berdir’s picture

I fully agree that there are UX issues for some of those cases. But I'm not so sure it can be fixed with some general changes or settings (or whether that should be in core). The example above can be improved, as done there, with a different submit button label, but adding a UI setting for a configurable submit button label is non-trivial, it would likely need to be per node type and dynamic (only shown to some users, possibly if they don't have status access, but that also might not apply in all cases).

Maybe those kind of customizations are better left to contrib modules/custom code?

timmillwood’s picture

I agree it's a complex issue, but not sure it's something we should leave solely to contrib.

We really need UX input, but if changing the button text is not an option we should add some textual context near the button. Similar to in #2753717: Add select field to choose moderation state on entity forms where we're aiming to show the what will happen "on save".

jonathan1055’s picture

Maybe those kind of customizations are better left to contrib modules/custom code?

No, surely this can be solved/improved in a neat efficient way in core. Please we cannot go back to having the varying text on the button. It was a huge effort and extremely worthwhile to make the 'save' text consistent. Any of the first three ideas in #5 are preferrable to changing the button text or doing nothing.

I might try to see if I can do the change to add the 'published' textbox for all users but make it disabled if no access. But if anyone else also wants to work on this, carry on and do so. I might not get time today ...
Jonathan

Manuel Garcia’s picture

Status: Needs work » Needs review
FileSize
2.02 KB

Here's a patch taking the disabled published checkbox route. Including also test coverage on Drupal\Tests\content_moderation\Functional\NodeAccessTest.

jonathan1055’s picture

Issue summary: View changes
Status: Needs review » Needs work

This looks good to me. Showing the checkbox and having it disabled is the best option, I think. Given all the css work done on the previous issue, we know that it will look fine on all displays. Just a couple of points:

  1. You could add $form['status']['widget']['value']['#description'] = t('You can not change the published status.'); so that users without the permission are really clear about why the box is shown but not clickable.
  2. Would be good to explain more in the comment, so change 'Show a disabled Published checkbox if user has no access.' to 'Show the status checkbox but make it disabled if user has no access.'
  3. -    // Access that the status field is no longer visible.
    +    // Access that the status field is no longer enabled.
    

    Not your mistake, but you could fix the 'Access' which should say 'Assert'

Good work, thanks for doing this.
Jonathan

[edit: p.s. I did not mean to change the status to 'needs work', somehow that just happened]

Manuel Garcia’s picture

Status: Needs work » Needs review
FileSize
1.66 KB
15.28 KB
14.7 KB

Thanks for the review and suggestions @jonathan1055 makes sense to me.
Tackling #15 in this patch.

node add disabled status field screenshot

timmillwood’s picture

Status: Needs review » Needs work

We discussed this issue in this weeks UX call.

Gabor thought it might not be clear that the published checkbox is disabled.
Jozef suggested we add a drupal_set_message style notification above the save button telling the user they cannot change the publishing status and saving would save as published (or unpublished).

kiamlaluno’s picture

I am not sure there is the need of putting a message for that. From a UX point-of-view, it's better to show a disabled interface element, rather than hiding it. (I think it's called principle of minimum surprise.)
To make it clearer, the tooltip of that form element should say the user doesn't have the permission to change the published status.