Add a 'schedule this revision' fieldset on the node edit form

I need this for a project of mine. So if this isn't worked on currently, I'll start it.

We have the exact same issue with a customer project and need this functionality in the next 1-2 weeks.
We would suggest this workflow:

Our editors (only rights to create drafts, not publish) should have the possibility to suggest a publication date.
If the publisher (rights for publish) tries to publish the node before the suggested date, he gets an notification if he would to create an scheduled publication.
If he publishes the revision after the suggested date the revision is published immediately. And the cron does not check for the suggested date.

What do you think of this suggestion?

how is the status with you dixon_? Because we could also provide some coding force to achieve this solution

I haven't started work on this yet.

@Schnitzel Your workflow is different from what we had in mind. It sounds more complex than the average solution.

Our workflow would be more straight forward, where one role will have the permission to schedule state changes. Everyone of the same role can change the scheduling. We identified that this won't be a problem as long as it's visible on everyone's Workbench when an article is scheduled for state change.

But again, I haven't started anything yet. We will probably start within the coming 2 weeks. But our sprint prioritization might change. I'm unassigning myself, since I can't guarantee anything :/

So you would allow to Editors to schedule a publication even if they don't have the permission to publish?
That's the problem we try to fix in our solution.

So assigning this to me, because we will work on it this week, if it is then too hard for the average solution we will see :)

Yes, in our workflow normal editors will actually have permission to publish and schedule. Review is done peer-to-peer on a general consensus basis to keep the editorial workflow a bit quicker and agile.

But it should be configurable, the same way as workbench are today. I have looked at the code quick, and it seems to be so that users can schedule state changes to state they have access to. So we already have a great deal of flexibility in the current code.

Here is a patch that adds a new option in the Publish options fieldset (in the case of nodes) to schedule an operation at a certain date.

The above patch does not check if the user has access to schedule revisions. Use this patch instead.

So a short explanation what this patch is doing:

This patch will allow Users which have the right to create new Schedules directly while creating a new Revision.
It is not fixed to Schedule only to the publish state, it can be any transaction scheduled.
If you want to make it plain simple (for example to allow only schedules to the publish state) you need to change the code, but this is the most general way we found (@Dave agree with this?)

In our Customer Project we had a more complex workflow:
The Editors didn't have the publish rights, so they had to enter an "suggested schedule". For this we added a "state" field for each Schedule, which can be "suggested" or "active". If the Editors create a new Revision with a "suggested schedule" it creates a new RevisionSchedule with the "suggested" state.
Then the Publisher have in the moderate area not only the possibility to publish the Revision, they also have the possibility to "activate the suggested schedule".

We are testing now this Patch and probably will contribute it tomorrow.

We splited up these two functionalities because the second case is a bit complex and also changes some stuff from the module which maybe is too much, what do you think @Dave?

Cheers

One issue with this patch involves there being no check to see if the entity is capable being revised by workbench. For instance, the field_attach_form will apply to users and taxonomy terms which in turn errors out when attempting to add/update/delete these types.

Adapted the patch to check if the entity supports revisions or not.

@vasi1186: make sure you roll your patches relative to the module's directory, rather than from your Drupal root. See #707484: Making a patch for more info.

Here is the patch in #10 rerolled for patch -p1.

The patch in #11 applies cleanly to the latest dev code, and it works as advertised: scheduled revisions transition on the correct time.

I do feel that the user experience can improve quite a bit though. For example when creating a revision we could output the information that is available on /moderation/schedule on this edit form as well. If an older revision is scheduled to be published, then an editor creating a new revision will want to be aware of this. Another good place to put this information is on /moderation as part of the information displayed for that revision.

Maybe this belongs in separate issue, but it definitely needs some more attention.

Sorry, needs review. Maybe one extra before it gets committed?

I do feel that the user experience can improve quite a bit though.

In our solution for the customer we show the information about existing schedules in the yellow information box on top of the node and also in the moderation tab, check the screenshots (unfortunately a bit german).
If you think this would make the UX better (I think so) we could write a patch for it.

Schnitzel, screenshots look very primising. A patch would be great!

Agree would love to see this module go stable!

This works for me - further enhancement can be a new issue and/or subsequent patches imho

With the current validation handler being attached to the submit button the node_validation callback is never called. I have tracked this down to http://api.drupal.org/api/drupal/includes!form.inc/function/form_execute...

From form_execute_handlers().

  // If there was a button pressed, use its handlers.
  if (isset($form_state[$type . '_handlers'])) {
    $handlers = $form_state[$type . '_handlers'];
  }
  // Otherwise, check for a form-level handler.
  elseif (isset($form['#' . $type])) {
    $handlers = $form['#' . $type];
  }
  else {
    $handlers = array();
  }

From the patch

// Add some validation and submit handlers.
if (isset($form['actions']) && $form['actions']['submit']['#type'] == 'submit') {
  $form['actions']['submit']['#validate'][] = 'revision_scheduler_field_form_validate';
  $form['actions']['submit']['#submit'][] = 'revision_scheduler_field_form_submit';
}
else {
  $form['#validate'][] = 'revision_scheduler_field_form_validate';
  $form['#submit'][] = 'revision_scheduler_field_form_submit';
}

I have moved the validator out of the conditional locally but left the submit in(It does not seem to be affected in the same way, although I am not sure why).

// Add some validation and submit handlers.
if (isset($form['actions']) && $form['actions']['submit']['#type'] == 'submit') {
  $form['actions']['submit']['#submit'][] = 'revision_scheduler_field_form_submit';
}
else {
  $form['#submit'][] = 'revision_scheduler_field_form_submit';
}
$form['#validate'][] = 'revision_scheduler_field_form_validate';

I am not really sure why it was attached to the button so I just left it for now. If I have a chance this week I will re-roll the patch accordingly.

Changing to needs work

Attached is a patch that implements these features (in addition to the one provided in #11. Also, the change in #18 is included):
- on the view published, view draft, edit draft and view revision pages you can see a list with the scheduled operations for that revision and the user can run or cancel each operation.
- also, on the moderation page (where you see all the revision), just below the moderation form you should also see a list with the scheduled operation of that revision, and you can run or cancel each operation. The next step would be to put show the scheduled operations in the moderation page for all revisions, but I don't know if it possible without some changed in the workbench_moderation module (didn't spend to much time to find a solution).
Maybe some small adjustments are needed, and also maybe some documentation... but feel free to test it and give your feedback.

Patch does what it says on the tin.

However, my editor-level users generally do not have the "administer content" permission, which means they do not see the "Publishing Options" fieldset, and the scheduler form is dumped into the top level. In this case, the scheduler form should be added to the "Revision Information" fieldset.

Revised patch attached.

It appears the patch at #20 or earlier added the function revision_scheduler_get_revision_schedule() - this does not check that the revision nid and vid are actually set, which they are not for a new node. A PHP error warning results.

Re-rolled patch attached - this adds a check for nid and vid, and returns an empty array if those are not set, so any calling function foreach loops do not break.

Any updates on the status of this patch and commit?

Thanks,

Any way to get help reviewing this work?

Thank you!

You can always review it yourself - if you have applied the patch to the latest dev version and believe it works, change the status to RTBC.

@John Pitcairn thank you for suggestion. I tried to apply to patch --

drush patch http://drupal.org/node/1342824#comment-5642652

but did not take. any help please?

http://drupal.org/patch/apply

Tested the patch and worked as noted.

Advise review by someone with commit ability and commit it.

I've had this patch running on 2 sites in production since February. What are the chances of a commit?

Same -- have running on our site for 30+ days.

This patch may be slightly too over-reaching. When you've got the latest Field Collection dev release installed, the patch's new revision scheduling subform gets adding into each field collection. I don't know if this is a problem on Field Collection's side or this patch's, though, since I'm not entirely familiar with what either module is doing.

I would also say the patch shows up on Drupal Commerce Order Page.

Confirming that this doesn't always appear where it belongs.

This changes revision_scheduler_field_attach_form() to guard instead of nesting, and checks for available schedule operations (in addition to existing checks for a revisioned entity and user access to schedule operations) before modifying the form.

On my current project at least, this resolves the cases where forms were being inappropriately modified (commerce order form).

Ive also addressed some code style issues throughout the patch.

Some lines - mostly calls to t() - are excessively long and should consider splitting out and preparing some values in advance.

I also feel some of the API additions are in poor taste. For instance, revision_scheduler_get_revision_schedule(), which is node-specific and superfluous. It seems the patch should extend revision_scheduler_operation_load_multiple() to support loading scheduled operations based on passed conditions (entity type, id and/or revision id).

@lotyrin is #34 Ready for testing? or still needs more work?

Good question.

I'd like to see my concerns from #34 addressed, but they could be follow-ups to this, I suppose.

This patch contains some improvements to version provided in #34.

First, it only show the scheduled option in the 'Revision' tab. In my opinion, there is no point to allow to schedule a revision if the user cannot create a new revision.

Also, the options to schedule a revision are only available after check the option "Create new revision". And the date widget is only visible after select an operation.

Sorry wrong patch, here is the interdiff from #34 and the right patch.

#39 does not play weil with workbench_moderation - I suspect as there is no 'new revision' option the scheduler fields never are shown.

I hope #34 can be comitted or #39 revised

I applied the patch from #34 per @HyperGlide's recommendation in #39. Works great! Thanks all!

Tried to improve the support for workbench_moderation in the patch from #38. Hope it helps!

The patch in #41 works for me.

Some comments though:
There is an implementation of hook_install() in the patch, is this really necessary? If it is, there should be a hook_update_N() that does the same thing for people who already have the module installed.

This is the same basic functionality as provided at: node/%/moderation/schedule/add
but there is zero code overlap or reuse, is there some way to fix this up to reuse some of the code in these 2 spots?

Patch - 41 is good for us..

@seanB - Your patch applies but contains some white space errors.

Glenns-MacBook-Pro:revision_scheduler glenn$ git apply -v revision_scheduler-in_node_edit_form-1342824-41.patch
revision_scheduler-in_node_edit_form-1342824-41.patch:46: trailing whitespace.
  // Try to put the schedule field in the Publish fieldset when the
revision_scheduler-in_node_edit_form-1342824-41.patch:47: trailing whitespace.
  // workbench module is enabled for the node type, else place it in
Checking patch revision_scheduler.install...
Checking patch revision_scheduler.module...
Applied patch revision_scheduler.install cleanly.
Applied patch revision_scheduler.module cleanly.
warning: 2 lines add whitespace errors.

I just tested the patch #41 on http://simplytest.me/
Went to the article content type settings - checked "Create a new revision"

Note: I did not have workbench_moderation installed.

Went to Create Article at node/add/article

Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).
Notice: Undefined property: stdClass::$nid in node_access() (line 2999 of /home/sc4e2e469902ecd5/www/modules/node/node.module).

The settings do appear in the correct place under the "Revision Information" tab on node/edit. I was able to scheduled an operation and my node saved fine. After saving the node and re-editing, I no longer see the PHP Notices.

It does seem strange that you can't choose the revision that you want to schedule.

That might be solved with the patch at #1828646-7: Provide a regular publish/unpublish revision operation (without workbench), but there is a conflict when trying to use both patches at the same time. Only one patch or the other can apply at one time.

Hope that information/testing helps

More testing shows that the patch in #38 also throws the same Error Notices when trying to add a new node.

I'm still able to the Schedule the operation, but there is no way to see what is scheduled unless you make two revisions on the node.

After you make two revisions on the node, then the "Revisions" tab appears on the node where you can then view the scheduled operations. That is a Drupal core behavior that might need to be overridden to always show the revisions tab when viewing the node if a revision has be scheduled? Otherwise how would a person see the scheduled operation?

Regarding my comment in #44:

It does seem strange that you can't choose the revision that you want to schedule.

-This could be easily solved/clarified by changing the help text under "Scheduled operation" to "Please select an operation that should be scheduled for this revision."

Hopefully someone could chime in hear with a fix to the error notices

I'm not sure if this correct, but I modified the patch in #41 and added an if wrapper to the function:
if (isset($entity->nid) && isset($entity->vid)) {

/**
 * Implements hook_entity_revision_operation_access().
 */
function node_entity_revision_operation_access($operation, $entity_type, $entity, $account) {
  if (!empty($entity) && $entity_type == 'node') {
    if (isset($entity->nid) && isset($entity->vid)) {
      if (function_exists('workbench_moderation_node_type_moderated') && workbench_moderation_node_type_moderated($entity->type)) {
        return TRUE;
      }
      if (node_access('update', $entity, $account)) {
        return TRUE;
      }
    }
  }
}

That seems to make the errors in #44 go away for me. Note: I haven't tried this with workbench_moderation.

Also with #41 I seem to be getting these notices when I try to add a node as a person that doesn't have access to the publish fieldset.

Notice: Undefined variable: input in revision_scheduler_field_attach_form() (line 544 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/revision_scheduler/revision_scheduler.module).
x
Notice: Undefined variable: input in revision_scheduler_field_attach_form() (line 556 of /Users/glenn/websites/7c9d097f-0bc1-457d-8314-1d9e37f102bf/profiles/cmf/modules/contrib/revision_scheduler/revision_scheduler.module).

If I give the user the "Administer content" permission, then the error goes away.

I'm guessing it would need some kind of permission check here?

This is so it can work with workbench moderation 2.x

Very similar to the last patches just without any of the workbench_moderation 1.x stuff and a little more generic.

41: revision_scheduler-in_node_edit_form-1342824-41.patch queued for re-testing.

@Dave Reid - Testing the patch in #53. If I choose revert on the node/edit form under Revision Scheduler, am I supposed to see a revision drop down list to choose which revision? or is it assumed that you are reverting to the previous revision?

See the attached images for clarification.

In combination with the patch in #1828646-13: Provide a regular publish/unpublish revision operation (without workbench), I have successfully reverted, published, and unpublished an existing node. I also tested creating a new unpublished node and scheduled it to be published.

Hope that helps