If you run cron, it runs as anonymous. Database gets populated with user 0 creating revisions etc. In addition, other workflow modules that use scheduler modify their states as anonymous. You should be able to specify which user you want to act as the publish/unpublisher.

CommentFileSizeAuthor
#13 publish_and_unpublish_specific_user-2397423-13.patch11.1 KBlily.yan
#9 publish_and_unpublish_specific_user-2397423-9.patch11.16 KBlily.yan
#7 publish_and_unpublish_specific_user-2397423-7.patch10.61 KBiStryker
#5 interdiff-2397423-1-5.txt2.75 KBiStryker
#5 publish_and_unpublish_specific_user-2397423-5.patch10.58 KBiStryker
#4 2014-12-24_Workbench_publish_anonymous.png49.95 KBiStryker
#1 publish_and_unpublish_specific_user-2397423-1.patch10.36 KBiStryker
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

iStryker’s picture

iStryker CreditAttribution: iStryker commented
FileSize
publish_and_unpublish_specific_user-2397423-1.patch10.36 KB

I know this module want to keep things simple, but publishing and unpublishing stuff anonymously doesn't make sense. This should be an option to the site managers.

jonathan1055’s picture

jonathan1055 CreditAttribution: jonathan1055 commented
Issue summary: View changes

Hello iStryker,
Thanks for this - it's a nice idea. Do you think this is widely needed? It's never been asked for before, as far as I know. If a node is published by scheduler doesn't it add confusion if the revision appears to be authored by a real person? I'm not slamming your idea, just want to have a discussion about it. I'll try out your patch and see how it goes.
Jonathan

pfrenssen’s picture

pfrenssen
Location Sofia
CreditAttribution: pfrenssen commented

The messing with the global $user and session juggling looks scary to me. We are allowing external code to run by invoking hook_scheduler_api(). This means that all code that uses that hook will also have the tampered session data and global $user. This might break existing implementations.

iStryker’s picture

iStryker CreditAttribution: iStryker commented
FileSize
2014-12-24_Workbench_publish_anonymous.png49.95 KB

@jonathan1055, I think this is widely needed, but no one cares about it. Not a lot of people check to see who create/revised the content. All they care about is that on Monday morning at 9 am the content is published, or the end of the school term the content is unpublished.

doesn't it add confusion if the revision appears to be authored by a real person?

I do not think it does. The person who specify the user, knows what they are doing. They want that person to one who publish it. One example, say you have 1 user edit the content and set a publish date. Then another person or two make edits to it before it publishes. When the cron runs it will be published as anonymous and you will never know which user set the publish date (unless you use some kind of diff program/module).

Attached is a screenshot of Workbench moderation to give you a better idea after a cron job run to publish and unpublish a node.

FYI the messing with global $user follows Safely Impersonating Another User on drupal.org

@pfrenssen, yes messing with global $user is messy. I cannot think of any existing implementation this could break (unless they are trying to do a similar thing....ie run all cron jobs as a user called "Cron Job User" instead of anonymous).

iStryker’s picture

iStryker CreditAttribution: iStryker commented
FileSize
publish_and_unpublish_specific_user-2397423-5.patch10.58 KB
interdiff-2397423-1-5.txt2.75 KB

New Patch.

Fixed:

  1. Variable spelled wrong in publish and unpublish function in scheduler.cron.inc
  2. On cron run, if user enables 'specific user' configuration setting but there is no user set for scheduled node(s) then no nodes well get published/unpublished. This is because specific_user variable is set, however all users are set to -1.
iStryker’s picture

iStryker CreditAttribution: iStryker commented
iStryker’s picture

iStryker CreditAttribution: iStryker commented
FileSize
publish_and_unpublish_specific_user-2397423-7.patch10.61 KB

New Patch. If you try to edit a node that doesn't have an publish_on or unpublish_on then it

Warning: Creating default object from empty value in _scheduler_form_alter() (line 59 of/var/www/drupal/profiles/uw_base_profile/modules/contrib/scheduler/scheduler.edit.inc).

Error. Solve by adding one line: $defaults = new StdClss;

jonathan1055’s picture

jonathan1055 CreditAttribution: jonathan1055 as a volunteer commented

Hi iStryker,
Thanks for your patch, and the explanations. The patch file no longer applies due to newer code committed to .install. I fixed it manually and tested the change but there seemed to be an unwanted side-effect of blanking the scheduled date when editing an existing scheduled node. I reversed out the changes and the pre-existing scheduled dates reappeared.

However, I do not think we would add this feature anyway - it is a major change to make a new field in the Scheduler table specifically for this one purpose, a relatively minor enhancement that no other users have asked for. If you still want this functionality, it would need to go into 8.x first, anyway.

I do not consider it a good idea to give editors the power to make a node appear to be published by someone else. The revisions log currently clearly shows that Scheduler has done the publishing. Scheduler does not alter the owner of the node, so your change is only for information/logging. I do not think we want to "Impersonate Another User" even if the code changes are done via the accepted method. This will just add more confusion than it resolves.

So, unless pfrenssen has significantly changed his view from what was said above, I agree with him that this is not something we want to do.

I have some ideas about how we can expand the capabilities of Scheduler in 8.x in a generic customisable way, so that sub-modules or third-party modules could add bespoke modifications for these types of requirement without 'hard-coding' all the changes in the module codebase. If/when that happens then it could also be ported back to 7.x so keep a watch-out for that.

Thank you for your interest in this module - your contributions and comments are always useful and thought-provoking, even if we don't actually implement them they way you want.

Jonathan

lily.yan’s picture

lily.yan CreditAttribution: lily.yan commented
FileSize
publish_and_unpublish_specific_user-2397423-9.patch11.16 KB

I worked with iStryker. The patch is based on the current 7.x-1.x-dev and currently works with 7.x-1.5.

Liam Morland’s picture

Liam Morland
Primary language English
Location Ontario, CA 🇨🇦
CreditAttribution: Liam Morland at University of Waterloo commented
Status: Active » Needs review

The last submitted patch, 7: publish_and_unpublish_specific_user-2397423-7.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 9: publish_and_unpublish_specific_user-2397423-9.patch, failed testing.

lily.yan’s picture

lily.yan CreditAttribution: lily.yan commented
FileSize
publish_and_unpublish_specific_user-2397423-13.patch11.1 KB

New Patch. The patch is based on the current 7.x-1.x-dev (acf0a892).

iStryker’s picture

iStryker CreditAttribution: iStryker commented
Status: Needs work » Needs review
hmdnawaz’s picture

hmdnawaz CreditAttribution: hmdnawaz commented

The patch is not working. I can still see Revised by Anonymous (not verified)
The $node object does not contains the publisher_user property. $node->publisher_user

jonathan1055’s picture

jonathan1055 CreditAttribution: jonathan1055 as a volunteer commented
Status: Needs review » Closed (won't fix)

Hi hmdnawaz,
This enhancement is not going to be added to Scheduler, see my comments in #8 above. The issue should have been closed before now.
Jonathan

Liam Morland’s picture

Liam Morland
Primary language English
Location Ontario, CA 🇨🇦
CreditAttribution: Liam Morland at University of Waterloo commented

Perhaps a better solution is #3077633: Anonymous (not verified) after scheduler updates.