Closed (cannot reproduce)
Project:
Rules
Version:
6.x-1.x-dev
Component:
Rules Engine
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 May 2009 at 13:21 UTC
Updated:
5 Jan 2011 at 13:27 UTC
This is directly related to the thread: http://drupal.org/node/371728
Take the example Offer/Bid system from comment #5
The drupal user cannot, (which is what is wanted) access unpublished Bids.
Thanks to Rules and that example php code, when the drupal user publishes/unpublishes an Offer all associated Bids get published/unpublished.
This works properly in both directions when the drupal user selects/unselects the published checkbox. (thanks to override_node_options module).
The problem happens when I use the scheduler module's scheduled publish and unpublish dates.
see: http://drupal.org/node/457380
I cannot figure out why the published checkbox is different from the publish on schedule, but I cannot use it to publish unpublished nodes that the user cannot access through scheduler.
The problem continues with the File Framework files.
With the example code in comment #5 from the first link above, publishing of the files has the same issue as the scheduler publishing.
I can publish any files with the example php code as an admin user.
As the drupal user, I cannot publish files that are unpublished.
Unpublishing any published files works as the drupal user.
Why is this happening and how do I correct this problem?
Comments
Comment #1
fagoRules reacts only when a node is saved - it's invoked through the nodeapi. So if the scheduler module does a proper node_save(), rules is going to be invoked.
Comment #2
eric-alexander schaefer commentedScheduler issues 'node_publish_action' and 'node_save_action' for publishing of nodes and 'node_unpublish_action' and 'node_save_action' on unpublishing. It does not call node_save() directly in 6.x versions. Thats the way it is supposed to work. Am I wrong?
Comment #3
fagoNo, that sounds fine. The node_save_action should do a node_save().
Comment #4
thekevinday commentedWell if all the proper function calls are being properly called, then perhaps this is a bigger issue or an issue from yet a different project that is somehow being revealed through scheduler+rules.
I am using the ACL modules and Content Access modules.
I will attempt to reproduce this without ACL and Content Access modules on a clean server when I get the chance.
Comment #5
mitchell commentedAwaiting follow up from #4.
Comment #6
thekevinday commentedI created a clean server using the latest stable of all modules and was unable to reproduce the problem.
Perhaps it has been fixed?
Here is my configuration for the working condition on the clean server:
database: postgres 8.4.2
php: 5.3.2
all additional modules present and in use: acl cck content_access rules scheduler views
In my test case I created two content types: parent, child.
I created a test user and a test role (both called test).
The test role has edit perms on child but not parent.
The test role can access published
the parent has a node_reference CCK field for pointing to a single child node.
I created a view that loads all parents of a particular child node (called parents_of_child).
I then used the code from: http://drupal.org/node/457380 (replacing children_of_parent with the parents_of_child view) to both publish and unpublish the parent node via a rule+custom php.
(Yes, I did this backwards by accident and did not believe it worth the effort to correct the logic).
In theory, when I publish the child node, all parent nodes will get published.
When I unpublish the child node, all parent nodes will get unpublished.
My first test case gave the test user view permissions but no edit permissions on the parent node.
The parent node would successfully get published/unpublished properly when the child node changed.
My second test case gave the test user no view permissions and no edit permissions on the parent node.
The parent node would successfully get published/unpublished properly when the child node changed.
Therefore I conclude that one a clean system with all the latest versions this problem has been fixed.
However, before I close this, I will need to get back to the original system and confirm that this problem no longer happens there.
If the problem still happens on the original system with the latest versions, then this is a bug derived from some combination of additional modules on the system.
Comment #7
fagoAs this bug-report is rather old, please verify it's still valid in the latest dev version and re-open if so. For now, I'm marking it as closed.