The existing node module displays the log message after the node body if the moderation flag is set. See line 524 of node.module.

Since we're retro-fitting drafts onto the existing module, I don't think this is a bug in the node module. But we need to find a solution or workaround.

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I think the way to handle this is also to 'version' the moderate flag, so when a node is published and taken out of moderation, it doesn't show the log field.

Investigating now...

criznach’s picture

criznach commented

After having some time to think about this, I remembered this thread...

http://drupal.org/node/72343
and
http://drupal.org/node/73418

The purpose and possibly the future of the moderation flag seems to be undefined at the moment.

I think the creation of a revision above the current revision is enough to qualify which nodes have drafts. Could we, at least temporarily, stop using the moderation flag and just use the revision stack and vid pointer to keep track of which copies are drafts? That way, we wouldn't depend on a schema change or the moderation flag.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Sure, except... how do you tell when you want a revision to just be published instantly (like wikis, the handbook), vs. when to NOT publish it and leave the old one there?

Should we simply check on the published flag yes/no? If it's yes, then publish it straight away, if it's no, then assume you want to keep the old version published while the new version's pending?

Actually that sounds like it makes sense, so I'll go with that. :P

yched’s picture

yched commented

Yes, but what happens is what I want to do is actually to unpublish the node ?
I go to node / edit / uncheck publish / save => new draft gets created ?
(OK, I can still unpublish it using the admin/content overview, but still...)

I agree with criznach about the moderation flag, though. It's now out of core, so if we still envision this as a future core-candidate, we have to stay away of it...

I guess that's what I meant when I wrote (somewhere else, i think) :
if my user rights don't allow me a choice, then a draft is created
if my user rights do allow me a choice (to draft or not to draft), I need a "Save as draft button"

Ok, what user rights... ?

As a side note : I'm sorry if I'm missing some point and just being dumb, these issues seem kind of complex to me :-)

criznach’s picture

criznach commented

Random babbling...

Published vs unpublished makes sense to me in it's current form as a flag which only affects visibility of the current version. I think it works well being completely separate from the drafts model we've been discussing.

For unpublished nodes, does it matter which revision the node table points to? Maybe it should always point to the top-most draft. This way you could reference the most recent draft by URL without specifying a vid.

I don't think unpublishing should create a new draft.

I personally don't think the default publish behavior should be stored with each node. And I agree that it looks like the moderation flag is fading away. Maybe a preference somewhere in the module for "instant publish" vs "create draft", but like yched has said, more of an edit-time option than a per node flag. If your rights allow instant publishing, then show the publish button. If not, display a save as draft button. If you have rights to both, show both.

It would be really cool to, abstract the checkboxes away. The end users that I've talked to have been pretty confused by publish, create new revision, etc... I wouldn't say do away with them entirely, but make the submit buttons take care of some of the workflow details.

Now that I think about it, with a global setting that was off by default, we could roll this into core without much impact. The settings could be: "Always Create Draft", "Always Publish", or "Ask". The current behavior "Always Publish" - especially since the moderation flag doesn't do anything. For usability purposes, flipping the switch to "Always Create Draft" should give the user the right to publish their own drafts unless specifically revoked.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I think this is fixed now, with the addition of the "New revisions in moderation" workflow setting.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)