Hey guys,

I have a small issue, that might be a bad configuration, but probably is something that has been overlooked by either Rules or Content Permissions.

So the scenario is that I have a Rule set up that sends a notification email to a specified email address whenever a node of a particular content type is created. The template for the email includes tokens for all fields inside the content type. However, some of those fields are not allowed to be viewed by anonymous users through the CCK-provided Content Permissions submodule.

The issue is that when an anonymous user adds a new node, the email that is being sent out does not include these fields that the anon can't view. However, as the email is configured by an admin and is sent out to admin-specified emails only, the access permissions should really be based on the admin user and not an anon.

Please let me know if this doesn't make sense, and if it does - if you can help!

Thanks a lot in advance!

Comments

arski’s picture

arski commented
Component: Rules Core » Rules Engine

*poke*, some help please?

itangalo’s picture

itangalo commented
Status: Active » Closed (works as designed)

Sorry, no can do on this one.

I guess that it would be possible to write PHP code that collects stuff from the database, but as long as the acting user doesn't have access to the information you'd have to do bad things to make it happen. (And when you think about it, this is as it should be -- Rules shouldn't allow restricted information to be fetched.)

A suggestion for a workaround is to send out the 'open' information and then link to the created node, or a View with all information summarized.

Sorry for the bad news.
//Johan Falk
I'm a part of the Rules Issue Squad, helping out in the issue queue. You can join, too!

arski’s picture

arski commented

well, in the case where an email is being sent out to user B when user A creates some content, the "active" user should really be user B, because he's the one who's getting the email, i.e. he's the one so to say "viewing" the content.. so basically all that needs doing is changing the $user object when sending the email, something that I think is quite common practice..

*sigh*