Problem/Motivation

Ever since time began it has been confusing for users who don't have the "Administer Content" (aka "Administer nodes") permission, because they don't see if saving a new node will publish it 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

Members fund testing for the Drupal project. Drupal Association Learn more

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.

Berdir’s picture

I still think exposing this is a bad idea for many uses cases where you do not want to expose to users that there's such a concept.

This actually does change the form for normal users, which #2068063: Change "Save and keep un-/published" buttons to a "Published" checkbox and an included "Save" button did not, it only affected it for users with administer nodes (without adding contrib modules). So this will automatically affect sites that update and e.g. have node forms for anon/auth users (that are then for example published after a review), some of which *will* have customizations to the form, like a different submit label.

I'm still not convinced this is something that core needs to solve. Nor do I see why it is all of a sudden such a big problem, this behavior existed for many years like that.

But, if others are convinvced this needs to be done now and in core, then what about adding a new permission to control this? Something like "view publication status in node forms"?

Also, looks like #16 contains the media patch as well.

timmillwood’s picture

Issue summary: View changes

@Berdir - Thanks again for clarifying this is actually an old and long standing issue, I have updated the issue summary to reflect that. I was aware it was/is an issue in Drupal 7, but assumed the drop buttons in D8 fixed it (where a user would see the one relevant button) although I guess I was wrong. I then assumed #2068063: Change "Save and keep un-/published" buttons to a "Published" checkbox and an included "Save" button brought the issue back, but in fact, it was never gone.

I would really like to find a solution to this in core, as it has hit me personally, and I have seen it affect others too.

"view publication status" is an interesting concept, but with Seven theme (if a user has permissions to view the node form in it), the publication status is already shown by default, up in the top right. However, this issue I have with this, it's not shown until after saving the node. Therefore when creating new content, it's still not sure what the save button will do.

Berdir’s picture

Good point with seven, maybe we can improve that sidebar and also show the status there when creating new content? then it won't affect the use case that I described, and you're right, users who can use seven already can see that status for existing content.

That also conflicts a bit with the other issue about moving (some?) of that information out of the seven theme. Tricky stuff.

timmillwood’s picture

Right, here's the issue about moving the sidebar out of the theme #2803875: Node form meta information should not come from a theme. In Bartik it'll just render as vertical tabs though.

jonathan1055’s picture

what about adding a new permission to control this? Something like "view publication status in node forms"

If a user has the authority to create/edit content then is there really a good use case for hiding the publication status? I cannot think of any reason why you would not want a user to know whether it is published or unpublished when they click 'save'.

Also, looks like #16 contains the media patch as well.

Yes the patch in #16 had a lot of extra accidental changes, although the interdiff was correct.

kiamlaluno’s picture

Is showing the published status exposing sensitive data? I would say no.

Maybe spammers would be happy to know they are creating a node that is directly published, but not showing the published status would not stop them from spamming. It's the normal users who, not knowing if a node is going to be directly published, could be not at ease with creating nodes.

yoroy’s picture

@berdir:

I'm still not convinced this is something that core needs to solve. Nor do I see why it is all of a sudden such a big problem, this behavior existed for many years like that.

It's true that it's always been like that. It's been noted as a serious problem since at least 6 years ago: #1123696: Does 'Save' publish my content?. And because publishing content is still kind of a primary task in a CMS, we should worry about it and improve things were possible.

I suspect it's not so much about whether to expose that a (not) published state exists or not, it's about giving people confidence and a sense of control. I like @kiamlaluno's suggestion to add the explanation in a tooltip over the visible, disabled checkbox.

I imagine this could be the case for some content types and not for other content types, for the same user/role. Would be good to keep as similar as possible across both cases.

Manuel Garcia’s picture

Status: Needs work » Active

Apologies for the bad patch on #16, clearly I was working on too many things that day.

I'm tempted to prepare a patch following the proposed tooltip over the disabled checkbox, however I feel we need some consensus here, and perhaps define the scope a bit more... so even though I'm risking some bikeshedding, here are some questions for this I think we have a think about:

  • Should we do this for all "publishable" entities? I'm guessing we shouldn't do it for comments, but Media could use this as well for example.
  • Should this be configurable? per bundle?
  • Should we provide a permission to see these? Per entity? Per bundle?
  • Should we first do a MVP then expand on it? If yes what would be the MVP? fix Nodes first?

I'm holding back until we have a clearer path forward, but I'll happily work on patches for this... let's do it!

timmillwood’s picture

Media are looking to follow the pattern in #2068063: Change "Save and keep un-/published" buttons to a "Published" checkbox and an included "Save" button with #2863431: Change "Save and keep un-/published" buttons for media module. I think it would be good to move that to \Drupal\Core\Entity\ContentEntityForm, then we could do this change there too.

I'm not sure it needs to be configurable, Drupal is confusing enough already. Contrib can override this with a form alter.

Similar with permissions, we already have enough, contrib can handle this if needed.

We should just fix nodes first, until the $form['footer'] from NodeForm is moved to ContentEntityForm.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.