For some reason 'published' doesn't appear in the 'from' dropdown at admin/config/workbench/moderation/transitions-- i need to create an 'obsolete' state for documents that should be unpublished but not deleted (for audit purposes we don't delete anything).

CommentFileSizeAuthor
#40 transition_from_published-1185678-40.patch11.69 KBstevector
#34 1185678-34-workbench_moderation-moderate_on_unpublish.patch12.08 KBbecw
#30 1185678-30-workbench_moderation-moderate_on_unpublish.patch11.17 KBbecw
#27 1185678-27-workbench_moderation-moderate_on_unpublish.patch4.29 KBbecw

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Hrm, it looks like this is by design, but I'm not sure exactly why. Will ask internally.

wiifm’s picture

wiifm
Primary language English
Location Wellington, NZ
commented

I have exactly the same requirement. NZ Government sites have a legal obligation to never 'delete' content on a site, but rather 'archive' it. This is the public records act 2005.

So my desired additional workflow state would be 'archived' and that only published items could transition into this state, and there would be an additional transition from 'archived' to 'draft'

Hope this makes sense

WorldFallz’s picture

WorldFallz commented

I also tried simply unpublishing the node but that sets the state back to 'draft' which is completely incorrect. I haven't been able to figure out a way around this yet.

WorldFallz’s picture

WorldFallz commented
Title: cannot tranistion from 'published' to another state » cannot transition from 'published' to another state

i'm happy to try and figure out a patch for it, but I'd rather wait and what dave has to say-- I'd hate to spend time figuring it out if it's by design.

Shadlington’s picture

Shadlington commented

Subbing

joekotvas’s picture

joekotvas commented

Subscribing... I need this functionality as well.

Tsubo’s picture

Tsubo commented

You need to create a new State (from the States admin menu) called 'Obsolete' or whatever.... then create a new Transition from Published > Obsolete in the transitions admin. This post should help on Views integration side: http://drupal.org/node/1138948

WorldFallz’s picture

WorldFallz commented

reread the original post-- tsubo. That's what I tried to do-- but 'published' doesn't appear in the 'from' dropdown in order to be do that, lol.

wiifm’s picture

wiifm
Primary language English
Location Wellington, NZ
commented

Thats the thing @Tsubo, out of the box (unpatched) workbench moderation does not allow transition to anything from published unless that is draft.

@Dave Reid was going to have a look as to why this decision was made internally. It is possible at the moment to patch the module to support transitions from the published state, but this introduces other bugs - e.g. a transition from published -> archived, should unpublish the revision, this does not happen at present.

WorldFallz’s picture

WorldFallz commented

fyi-- commenting out line #188 of workbench_moderation.admin.inc (unset($element['from_name']['#options'][workbench_moderation_state_published()]);), you can then transition from 'published' to another state. Other states are unpublished by default so for my use case of published->obsolete it makes sense.

I'm still testing to make sure this change doesn't affect anything else.

WorldFallz’s picture

WorldFallz commented

There's also the issue of the fact that unpublishing an item changes the state back to 'draft' by default-- it might also make sense to make that default unpublished state selectable. That might be a separate issue though.

WorldFallz’s picture

WorldFallz commented

Seems like this is already part of the plan, from workbench_moderation.module:

/**
 * Returns the key which represents the neutral non moderated revision.
 *
 * @TODO: make this configurable.
 */
function workbench_moderation_state_none() {
  return 'Draft';
}
WorldFallz’s picture

WorldFallz commented

Turns out that part is already being worked on: #1147646: Hard coded 'Draft' status in .module.

becw’s picture

becw commented
Category: bug » feature

Dave Reid is correct: it's intentional that you can not create transitions away from the published state. There's a special, non-transition permission in Workbench Moderation for unpublishing content. This is because sometimes unpublishing is allowed on revisions where moderation is *not* allowed; moderation isn't allowed on any but the current revision. A past revision may be published, but you can no longer moderate it. Likewise, you can only publish a revision that you can moderate. If there's an old revision that you want to publish, you have to revert (which makes a new revision that is a copy of the old revision), then publish.

If there is another way this should work, I'm open to discussing it.

WorldFallz’s picture

WorldFallz commented

That makes sense-- the only problem then becomes, when 'unpublished' the official way the state goes back to draft-- which is completely wrong and misleading in the case of unpublishing obsolete content that you don't want to delete.

perhaps adding adding a setting for the desired state to use when unpublishing?

clashar’s picture

clashar commented

I would like to have also this option "published" -> "expired/obsolete",
and the possibility to reverse like "expired/obsolete" -> "published" when author wants to renew his post.

eriknewby’s picture

eriknewby commented

+1
We are setting up a kbase system and the workbench workflow is perfect for what we are setting up. However we need this exact same functionality ... published -> archived.

becw’s picture

becw commented

Does anyone want to write and test a patch? This would require:

  • removing the current restriction on creating transitions from published to other states from the admin form logic (easy)
  • adding appropriate access checks for published -> other state transitions using the 'unpublish live revision' permission (more complicated)

Additionally, we should examine the utility of the 'unpublish live revision' permission; are the per-transition permissions enough access control?

WorldFallz’s picture

WorldFallz commented

Sure I can take a stab at a patch-- I just wanted to make sure I was working in the right direction first.

I've already done part one of this-- i'll see about the rest.

And personally, I can't think of a reason why I would need 'unpublish live revision' if i have per transition permissions-- anyone else?

becw’s picture

becw commented

Awesome, thanks!

Also, here's another thought: we can add a state dropdown to the 'unpublish' confirmation form that shows states based on whatever transitions are available.

WorldFallz’s picture

WorldFallz commented

Actually, now that I'm working through this, two different possibilities come to mind.

The first, which we've already mentioned, is to remove the restriction to move from published to other states (along with all the other downstream effects that might have).

The second, is to leave that restriction in place, and add an option (select list) for which unpublished state to use when 'unpublishing live revision'.

Though I've been playing around with the first option, I'm thinking the second is actually more intuitive and less intrusive.

thoughts?

nico heulsen’s picture

nico heulsen commented

+1
The workflow is perfect, however we need this exact same functionality ... published -> archived.

BenK’s picture

BenK commented

Subscribing

dekova’s picture

dekova commented

subscribing

dekova’s picture

dekova commented

When reviewing this enhancement, please consider allowing multiple published states for flexibility instead of assuming that content can only be published during one stage of the workflow.

example: Published -> Review for Expiry -> Expired

becw’s picture

becw commented

@dekova: multiple published states is a feature we've considered, but have not yet implemented--I've quoted your comment in the issue #1079120: State Properties.

becw’s picture

becw commented
Status: Active » Needs review
StatusFileSize
new 1185678-27-workbench_moderation-moderate_on_unpublish.patch4.29 KB

Here's a patch that:

  • allows creating transitions from unpublished to other states
  • adds a state dropdown to the unpublish form if there are transitions available
  • bonus: sets a sensible default state in the mini moderation form and the unpublish form

This patch does not remove the "Unpublish the current live revision" permission. If you review this patch, please feel free to comment on the wording and layout of the unpublish form.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Patch in #27 seemed to work pretty flawlessly.

becw’s picture

becw commented
Assigned: Unassigned » becw
Status: Needs review » Needs work

So, I'm now convinced that we should remove the "unpublish current live revision" permission, since there is a permission for each transition, and this patch gives us transitions away from the published state. I think that the unpublishing workflow should remain different from other moderation workflows (basically, it should keep using the "unpublish" link and the confirmation form).

Also, we should write a test for this.

becw’s picture

becw commented
StatusFileSize
new 1185678-30-workbench_moderation-moderate_on_unpublish.patch11.17 KB

Here's an updated patch.

  • fixes test breakage in previous patch
  • adds an update function that creates a published -> draft transition, and replaces the "unpublish current live revision" permission with the transition permission
  • updates the unpublish test to use the updated button name ("Unpublish" instead of "Confirm")

I think that we may not need a test for the unpublish moderation form, since there is a test to make sure that the content actually unpublishes, and beyond that moderation is done in the same way as with the mini-moderation form.

becw’s picture

becw commented
Assigned: becw » Unassigned
Status: Needs work » Needs review
stevector’s picture

stevector
he/him
commented

This patch works fine in my testing. Can anyone test this on real data? I'm working in a relatively fresh dev sandbox.

becw’s picture

becw commented
Assigned: Unassigned » becw
Priority: Normal » Major

I'd like to get this committed, since this feature has been through some iterations and seems like it's working. However, this will change based on #1160478: Machine names for states. I'll revisit this patch once that goes in.

becw’s picture

becw commented
Assigned: becw » Unassigned
StatusFileSize
new 1185678-34-workbench_moderation-moderate_on_unpublish.patch12.08 KB

#1160478: Machine names for states has been committed; here is an updated version of this patch to reflect the new machine names.

This version includes changes to the update function; for anyone who has tested this patch, note that the machine names for states patch included an 7006. You'll need to make sure that update gets run on your development environment. This patch's update is now 7007 (which may change again before it is committed--it depends what other criticals go in first).

@WorldFallz, @wiifm, other subscribers: please review and let me know how this works.

WorldFallz’s picture

WorldFallz commented

sorry... the project for which I was working on this ended up going a different way. I will definitely test out the new functionality and report back.

Rix-1’s picture

Rix-1 commented

Fantastic - now a newbie question: how to I install a patch? (blush)

becw’s picture

becw commented

@Rix -- if you are checking out the project using git, there are sketchy patching instructions under "Applying a patch" in the handbook page on making a Drupal patch with git.

becw’s picture

becw commented
Assigned: Unassigned » stevector

Hey Steve, will you review this during the sprint so we can move it forward?

becw’s picture

becw commented

Steve, this patch should also resolve #1209824: Order/default of moderation states in drop down when multiple states are present - Usability.

stevector’s picture

stevector
he/him
commented
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new transition_from_published-1185678-40.patch11.69 KB

This still seems good to go. I had to update the patch slightly to fit with commits since the last patch.

stevector’s picture

stevector
he/him
commented
Assigned: stevector » Unassigned
becw’s picture

becw commented
Status: Reviewed & tested by the community » Fixed

Thanks! Committed in b12a94.

Status: Fixed » Closed (fixed)

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