Needs work
Project:
Revision scheduler
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
1 Nov 2012 at 00:29 UTC
Updated:
2 Apr 2015 at 20:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
cweagansPatch attached.
Comment #2
cweagansNew patch
Comment #3
robbertnl commentedFor some reason the operation dropdown is empty after applying your patch.
Doesn't your patch work with the latest dev or am i doing something wrong?
See attached picture.
Comment #4
robbertnl commented#2: 1828646_2-provide-node-operations.patch queued for re-testing.
Comment #5
robbertnl commentedProblem for #4 is caused by function node_entity_revision_operation_access, which always returns FALSE.
I made a new patch but i also removed the the scheduled revision states to draft/needs review. I think that dont make to much sense and will confuse people, because we now also have publush / unpublish.
Comment #6
robbertnl commentedModified patch (bugfix)
Comment #7
dagmarThis patch is based on #2. I think is cleaner and, after all, this issue is related to the use of this module when workbench_moderation is not installed.
I think the issue described in #5 was not properly fixed, in my opinion, node_entity_revision_operation_access() should return TRUE if the content type is moderated, or if the used can edit nodes of this content type and FALSE otherwise.
Comment #8
gmclelland commentedThanks for all the patches. I've successfully patched with #7 and it seems to work great without workbench. I haven't tested with workbench_moderation.
My concern is why do these patches blow away the Revision log message with "Scheduled publish." and "Scheduled unpublish." after the scheduled operation completes?
Should the "Scheduled publish" be appended or prepended to the Revision log message? Maybe those messages aren't needed at all, especially since we have node/%nid/revisions/schedule that shows the history of actions taken?
If I had a node that has goes through several revisions and publishings all I will see is "Scheduled publish". I will have no way of knowing the differences between the revisions.
Comment #9
gmclelland commentedOk after more testing with this module, I see that the patches posted here are just following the same thing that this module is doing which is also the same behavior as Drupal core.
I think this module is correct in following Drupal core with the revert operation, but I don't think the patches provided here should overwrite the Revision Log Message on Publish/Unpublished with "Scheduled Publish" and "Scheduled Unpublished".
Maybe we can just remove:
$node->log = t('Scheduled publish.');and$node->log = t('Scheduled unpublish.');?Comment #10
gmclelland commentedHere is the same patch in #7 without the
$node->log = t('Scheduled publish.'); and $node->log = t('Scheduled unpublish.');This way won't overwrite the Revision Log Message on a scheduled Published/Unpublished.
Comment #11
gmclelland commentedLooks like this needed a reroll without the node_entity_revision_operation_access() function. The new version of revision_scheduler already includes this function.
I tried merging the differences.
Here is a new patch. Hope that helps.
Comment #12
gmclelland commentedHmm... Patch in #12 throws a notice
added this to prevent the error
Here is a new patch.
Comment #13
gmclelland commentedHere is another patch. I split the function node_node_revision_operation_set_status into two functions and added a drupal_set_message just like the other operations.
I'm currently having problems with the latest 1.x-dev at #2303699: Running cron doesn't revert the revision
I'm still not sure on how the access control works in function node_entity_revision_operation_access in 1.x-dev
For now this patch works with 1.0-rc1
Comment #14
dave reidWhat is the effect of this if a previous (not-current) revision is scheduled to be published or unpublished?
Comment #17
dave reidWould be good to also get some review on #2364585: Implement entity revision operations as plugins which I'd like to land first since it does a major overhaul of the actual operation code itself.
Comment #18
dave reidNevermind, postponing #2364585: Implement entity revision operations as plugins which shouldn't block this.
Comment #19
dave reidSo I think we need some access control for:
- The entity is not under workbench moderation control
- The revision is the 'current' revision and not a past revision