I have a set of rules that will send an email to users when new content is created based upon a field in their user profile.
So, a user can edit their user profile and select to receive email notifications when, say, a new General Announcement is created.

I have a rule that is triggered "After Saving New Content" and, in the Rule Action, it fetches Users by Property where the User's email preferences contains "General Announcements".

This rule works great IF an administrator creates the General Announcement but doesn't send any emails if a non-administrator creates the announcement.

I turned on debug logging and the rule fires and there are no errors. It looks like the rule fires normally but found no users to send the email to. That is, it appears that when the rule fires in the case of a non-admin content save, the list of users is empty even though there are users configured with the setting and even though the same rule will send an email when an administrator sends content.

I've attached the exported rule and the debug log.

Edit: I have 3 different types of announcements, General, Booster Club and Team announcements. I realized today that the debug log is from creating a Booster club announcement. I mention this to avoid any confusion when reviewing the log because I mentioned General Announcements in the original problem text but the problem is the same for all of them.

CommentFileSizeAuthor
rule.debug_.log_.txt1.75 KBescarecrow
rule.export.txt1.96 KBescarecrow
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

escarecrow’s picture

I should add that the non-administrator user(s) have the "View User Profiles" permission

acrazyanimal’s picture

I am experiencing a similar problem with the loading of a custom entity type. In my case it it a user changing their employer. The rule loads all of a user's past employers and sets their state to inactive. This works fine for an admin user, but if a non-admin changes their employer the relationship entities don't get loaded using the fetch entity by property; where the property is the uid which is their own uid.

It seems this only just started happening recently. Was there an update in drupal core may have changed things up a little?

escarecrow’s picture

I've been working on this today and I found that the key permission is "Bypass content access control". I can't grant that to the content creators and I doubt most other people could as well.

The other thing I think I've found is that I think this may be related to the Content Access module. I disabled the content access module and it seems to work as expected.

That being said, I also need that functionality so for the moment, I've created a workaround which is kind of ugly but is working for me. I created roles for each of the previously mentioned email preferences and I have rules assign and unassign the roles when the user profile is saved. The notification rules, then send to all users by role instead of fetching the users by property. This works for me but won't work for acrazyanimal.

I post this here to help anyone else who may be struggling with the same issue. I suspect, now, that the bug should probably go against Content Access but I'm not 100%.

@acrazyanimal: I would be interested to know if you also have the Content Access module installed and, if you do, does the behavior work if you disable it?

lord4gb’s picture

Having the same issue here with Rules and Organic Groups on sending mail to group members when new group content is added by a non-administrator. If the user is a non-administrator it will only send an e-mail to the admin. If the admin adds content it sends mail to all members of the group.

@escarecrow: Your workaround didn't seem to work for me, as the adding of a user-role isn't working fool-proof. Then again, I'd rather look for a real solution instead of a work-around. Thanks for posting though!!

I don't have the Content Access module installed here. The 'Bypass content access control' permission seems to solve the issue. This is, as escarecrow mentioned, not a workable solution, so I'm now trying to find ways to see which modules administer access control on these group nodes to see if I can turn them off. Does anyone have a clue how to check which access control rules apply? Does devel module supply this?

spazfox’s picture

Status: Active » Closed (duplicate)

Marking this as a duplicate of #1824570: "Bypass content access control" permission required for rules to work in some conditions, as the "Bypass content access control" or admin role requirement seems to be common to several different issues.

spazfox’s picture

Title: "After Saving New Content": Rule Action that Fetches Users by Property Not Working If Content Not Created by Administrator » "Bypass content access control" permission required for rules to work in some conditions
Version: 7.x-2.1 » 7.x-2.2
Status: Closed (duplicate) » Active

On second thought, it is probably better to keep this issue open (and change the title to be more general) since it has more details and examples of the bug. My apologies for mucking up the queue.

To reiterate, I am experiencing a similar issue (using 7.x-2.2, so the bug still exists in the latest stable branch) when using the "Collect view result rows" action of the Views Rules module, as collecting the view result works for admins or those with "Bypass content access control" permission, but not for any other users.

#1632224: Loop only works for Administrator role appears to be related to this, as well, and has been marked a duplicate.

spazfox’s picture

An update on my situation: it turns out the view I was using for the "Collect view result rows" was querying unpublished nodes, to which non-admin users did not have access. By making those nodes published by default, my rule now works without having to grant admin or "Bypass content access control" permissions to all users. So it appears that this is not a bug with Rules for my situation. I'm leaving the status as active, though, in case it is a bug for the other use cases described above.

Incidentally, since I do not want users to be able to directly access those now-published nodes, I use the Rabbit Hole to keep them from viewing them and it works like a charm.

spazfox’s picture

Issue summary: View changes

Update to explain the debug log shows a different type of announcement

ybabel’s picture

same here : I have a rules iterating on some private OG groups to auto subscribes some new users. But since the rules is executed as anonymous, all my groups are "invisible" to the rules.