Hi! User edits published node (state=live), but there is no new revision, so the modifications became public. I'm doing wrong something, or it's a bug? My content-type settings: Published=0, Moderate revisions=1. Content moderation settings: Edit stop on revision-moderation=0, Force publishing on new nodes=0.

Comments

eugenmayer’s picture

you realy need to be more detailed...

No revision is created at all or is the new revision "live" automatcally?
What does the history show you?
what does the revision table show you?

shp’s picture

Ok, I'll describe my experiments in details (content moderation & content-type settings - see my first message). NOTE: I have fixed bug with array_search() before my experiments (http://drupal.org/node/775782).
1. USER creates node. He sees messages, revisions block. Moderation history is empty. Node published=0. All is ok.
2. USER edits this node. No new revision appears in "node_revisions" table (current revision was overwritten). So, the node still has 1 revision. Node is unpublished, moderation history is empty.
3. MODERATOR changes pending revision's state to "live". Node became published automatically, the first item appears in moderation history. All is ok.
!! 4. Then USER edits this live node. Again, no new revision was added to "node_revisions" table, so current revision was overwritten and thats why changes have been made public without moderator's review!

eugenmayer’s picture

Well this is all related to the revisioning of drupal. In normal cases this is forced you can see it that the checkbox on the node-type form and in the node form which tells you "create a new revision" is not uncheckable ( and checked ).

This should force every save to be a new revision. This works for me in the non-draft mode, so there must be a sideeffect.

Can you tell me if that checkbox is checked and visible for you (during editing the node)?

broon’s picture

This may be related or not: For my client I am using the draft support, say there is no forcing on publishing, but still new revision is forced on any edits. There's a group (role) A which may create and edit content (but not publish it) and a group B which may (un)publish content. Since group A is responsible for content they are also able to view revisions. Therefore they also see the fieldset "revision information" on node edit forms (it only displays the revision message/log box, but not the "create new revision" checkbox as group A does not have administer node persmissions).

My client doesn't want group A to see this fieldset though, so at first I just unset $form['revision_information']. This caused the exact same error as described by you, now there weren't any new revision created as with unsetting the fieldset the hidden checkbox "create new revision" and its value was lost also.

eugenmayer’s picture

Well unsetting the form element is not the right way to do it, use #type=hidden in you case.

While i undestand that in sin.stars case the revisions are not created, iam not sure what happens in shp case.

shp’s picture

Yes, I have forgotten to check a "create a new revision" for my content-type. After enabling it all works properly: user edits live-node, but previous (live) revision is still active. Thank you!

So, maybe it will be beter to force create a new revision for moderated content-types (like in previous versions of Content moderation was, if I'm not mistaken). Generally, who needs such combination ("moderate revisions"=1 && "create a new revision"=0)?

P.S. By the way, now I am thinking over the ideal process of moderation in Drupal :) , including the nodes moderation. If you are interested, we can discuss it.

eugenmayer’s picture

Title: No revisions after editing » Create revisions not forced
Category: support » bug
Priority: Normal » Minor

Well actually this is not the expected behavior. New revision should be forced in all cases, if moderation is switched on. Need to be fixed.

To your ideas.: Well write a proposal but really try to find people helping to implement it, before you spent to much time planning. For me, iam here actually to maintain content moderation, so i will spend all time i have left from client work with bugfixes rather then any new features.

eugenmayer’s picture

Status: Active » Fixed

fixed, checking the "Create new revision" checkbox is forced when you select to moderate a node type

eugenmayer’s picture

Status: Fixed » Closed (fixed)

released in in 1.4

david.a.king’s picture

Version: 6.x-1.3 » 6.x-1.4

Hi,

I had a problem with this - i had existing content types, only one of which i wished to add moderation to.

I installed the module, then edited a content type. When i saved, i got the error "If you chose to moderate this content type, you must switch "Create new revision" in the workflow tab on" even though i didn't choose to moderate that particular type. - i.e. it forced me to enable revisions.

I removed the helper function

/*
 * Helper to ensure, that Create new revision is always checked, when a node type is selected to be moderated
 */
function _content_moderation_validate_node_type_form($from,&$form_state) {
  if($form_state['values']['node_options']['node_content_moderation'] == 'node_content_moderation' && $form_state['values']['node_options']['revision'] === 0) {
    form_set_error('node_options',t('If you chose to moderate this content type, you must switch "Create new revision" in the workflow tab on'));
  }
}

to "fix" the problem - i don't know what the above should be, but i'm guessing there's something odd going on!

eugenmayer’s picture

Status: Closed (fixed) » Active

Hmm, to be seriuos, i have completely no idea why it fails.

Could you please try a === here

  if($form_state['values']['node_options']['node_content_moderation'] === 'node_content_moderation' && $form_state['values']['node_options']['revision'] === 0) {

and try again?

If that still does not work out, could you dsm $form_state['values']['node_options']['node_content_moderation'] when you save and not activate it?

Thanks for the feedback!

eugenmayer’s picture

Status: Active » Fixed

fixed, it was the issue stated above

Status: Fixed » Closed (fixed)

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

eugenmayer’s picture

Status: Closed (fixed) » Fixed

Status: Fixed » Closed (fixed)

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

eugenmayer’s picture

Status: Closed (fixed) » Fixed

Status: Fixed » Closed (fixed)

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