Users with just create content permission don't know publishing status

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?

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 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?

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.

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.

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?

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

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

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]

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

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.

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.

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.

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.

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.

@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.

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!

I stumbled upon a related issue to this one.

Simple scenario: specific user role needs to be able to Publish/Unpublish one specific content type.

I don't understand why this cannot be added as permission which would solve this issue too.

Instead of giving this user role the whole "Administer content" permission with all the caveats which apply to all content types and/or setting $form['status']['#access'] = TRUE;
in the form_alter.