if a content type has revisioning active, the published checkbox in the node/#/edit page becomes irrelevant.

infact it's always unchecked, and trying to change its value has no effect.

shouldn't it be hidden, to avoid confusion?

Comments

rdeboer’s picture

Title: hide published checkbox in node/edit page when revisioning is active » Hide Published checkbox on node/edit page when "Create new revision and moderate" is pressed
Assigned: Unassigned » rdeboer
Category: bug » feature

Hi xlyz,
I think I understand what you are saying.
You are referring to the scenario whereby the user that edits the content has "Administer content" permission, right?

[By the way, for others reading this, granting the "Administer content" permission is not at all mandatory. It just means that the user can opt-in and opt-out of moderation on a per-node and per-edit basis. In other use-cases you may not want the user to have that choice and just force moderation upon them based on the content type in question. In those cases you would NOT grant "Administer content" to those roles.]

It is true that when the "Create new revision and moderate" radio button is pressed it overrides whatever you do with the "Published" check-box. That is the nature of moderation: the new revision MUST initially be unpublished.

So I hear you when you say that it would be less confusing for the user if that checkbox isn't there if that radio button is pressed. A minor complication is that when the user presses one of the other radio choices, the "Published" check-box IS relevant and needs to reappear.
Looks like a few lines of javascript could do the job.
I will look into it.

Rik

rdeboer’s picture

I checked an improvement into the repository, master branch.

rdeboer’s picture

Status: Active » Fixed

Fixed it some more. Available on master branch and in 7.x-1.1 when released.

rjacobs’s picture

It seems that unconditionally setting the publishing status to false can lead to confusion. In v7.x-1.0 that seems to be what's happening (revisioning.pages.inc around line 25):

if ($is_moderated_content) {
  // "Create new revision" must be set when the node is to be moderated
  $node->revision = TRUE;
  // Next lines aren't essential, just ensure all form options are
  // consistent with the edited content being subject to moderation.
  $form['revision_information']['revision']['#default_value'] = TRUE;
  $form['options']['status']['#default_value'] = FALSE;
}

If I have a published node, that is subject to moderation (in the content type settings), and then I select "Modify current revision, no moderation" or "Create new revision, no moderation" while making an edit, suddenly my content is no longer public... even though I don't want any moderation. This seems odd to me.

If a node's status is published, and an admin user makes an edit while selecting "Modify current revision, no moderation" or "Create new revision, no moderation" (because they just want a minor change to go live immediately) shouldn't the edited version of the node stay published (without having to manually check the "published" box again)? That would be my understanding, but I may also be misinterpreting some of the revisioning logic.

It looks like the recent changes to the master branch try to address this, but it only appears that there is javascript to uncheck the published box when "Create new revision and moderate" is chosen, but no functionality to check the published box when another option is chosen (such as "Modify current revision, no moderation" or "Create new revision, no moderation") and the previous revision is published.

If the module overrides the published checkbox setting when "Create new revision and moderate" is chosen anyway, then it would seem that maintaining the published status of the previous revision (in terms of the edit form) would be acceptable?

If I simply comment-out the line (in 7.x-1.0, revisioning.pages.inc around line 31):

  // $form['options']['status']['#default_value'] = FALSE;

I actually get the behavior I would expect. This is also what I remember from the D6 versions of revisioning. Still, I may be missing some bigger concepts about how the revisioning workflow is supposed to be....

Ryan

rjacobs’s picture

Title: Hide Published checkbox on node/edit page when "Create new revision and moderate" is pressed » Handleing of "published" status/checkbox when an admin overrides revisioning settings during an edit
Status: Fixed » Active

Just adjusting the title and status. Again, if my logic is off please feel free to change back.

xlyz’s picture

Title: Handleing of "published" status/checkbox when an admin overrides revisioning settings during an edit » Handling of "published" status/checkbox when an admin overrides revisioning settings during an edit

fix typo

rdeboer’s picture

Hi Ryan,
Agree with most points you've brought up in #4.

I think I need to save the value of the "published" box as the page is first loaded, so that I can revert to that when the user toggles back and forth between "Create new revision and moderate" (which should coincide with "published" UNticked) and the other 2 radio options (which should revert "published" to whatever it was set to when last changed or lacking that, to when the edit form was loaded).

Does that sound like a plan?

Rik

rjacobs’s picture

Thanks Rik,

Yep, I think what you described would consistently address the issue.

I also want to throw-out a suggestion that could potentially work without any moving parts. Since the module already overrides the published status of the form if the revision is to be moderated (making it false), and since non-moderated revisions should simply retain the published status of the previous revision, perhaps some text-based changes on the form would be sufficient? I was specifically thinking about using hook_form_alter() to adjust the text that appears by the "Published" check-box for content types that are subject to moderation. Adding a note like:

"Please Note: this selection will be overridden if you are saving a moderated revision. Moderated revisions are always initially 'unpublished', though your previous revision's published status will be unchanged".

Something like that. This way you could remove line 31 in revisioning.pages.inc and just depend on the text to clarify things to users (sans javascript). If something like this would do the same job, maybe it would save you some time?

In fact, even if you do go forward with the robust javascript solution, it might be helpful to still put some additional text by the "Published" check-box... just to clarify that it's status will be dependent on the moderation settings. After all, the workflow and revisioning options are on different panes, so users might not immediate see that the settings are connected.

Just some thoughts... thanks for your attention on this!

Ryan

rdeboer’s picture

Agree 100%. Thank you for your suggestions.
Will fix early next week.

rdeboer’s picture

Status: Active » Fixed

Fixed some more and checked in. Will be available in 7.x-1.1

rjacobs’s picture

Hi Rik,

I tested the changes via a copy of the master branch. Looks great! I like the way you simply hide the published status box altogether when it's not applicable, etc.

The only missing piece for me is the ability to set different defaults for different editor roles. For example I'm wanting roles with "administer content" to default to "Create new revision, no moderation" while all other editors default to "Create new revision and moderate". In order to have the latter I need to configure the content type defaults accordingly, but then these can't be automatically overridden for my "power editors" and admins (who have the "administer content" permission). Currently I'm managing this via a super-simple custom plugin that implements hook_form_alter (and has a high weight), but it may be something to consider as a future feature in revisionsing directly. Just though I'd mention that now as it ties-in a bit (from a tech perspective) with the points raised in this thread.

Thanks again!
Ryan

rdeboer’s picture

Glad you like it, Ryan!
If you want, attach your small module to this thread and I'll see what I can do re incorporating it in 7.x-1.2
Rik

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

monotaga’s picture

Any chance we can get this backported to 6.x?