6

I've set up a rule which is triggered by "after saving a new user account". This rule simply sends an e-mail. The e-mail contains various tokens, one of them is the field [account:field_country].

I've enabled "custom permission" for this field, and through the Field Permissions module I've configured the following permissions :

All users (selected permissions):

  • Create own value for field Country
  • View own value for field country.

Moderators (all permissions) :

  • Create own value for field Country
  • Edit own value for field Country.
  • Edit anyone's value for field country.
  • View own value for field Country.
  • View anyone's value for field Country.

The problem is : the [account:field_country] gets replaced with an empty string when the rule sends the e-mail. Only when I let all users View anyone's value for field Country does the rule properly replace the token with the actually selected country value.

Why do I need to do this? Which user does the rule module run as since the rule apparently need to View anyone's value for field Country to be able to get the value for that field.

Improve this question
7
  • You might find this interesting: Rules action to impersonate a user. And I would think it runs in the context of the current session. – J. Reynolds Mar 4 '16 at 9:49
  • @J.Reynolds : i agree, I also thought that rules would run in the context of the current session - but then the original permissions should be sufficient. – sbrattla Mar 4 '16 at 9:55
  • Yes I agree. And to expand on your question, what if the Rule is executed in a scheduled Cron job? – J. Reynolds Mar 4 '16 at 10:19
  • Please enhance your question by including an export of your entire rule to send that eMail. That may help to help you understand what your actual problem in your rule is, and possibly also why your apparent permission work around prevents that problem from happening. – Pierre.Vriens Mar 4 '16 at 10:39
  • @J.Reynolds : I'd suggest you undelete your answer, and still refer to the module you mentioned. And add something like a rhetorical question like "it must be the user who triggered the Rule, because if not then what would be the reason-to-exist for this module? Get my point? Alternative: I post my own answer similar to that (together with some extra motivations to (try to) proof my point). – Pierre.Vriens Mar 4 '16 at 10:43
1

And here is a module that could assist:

Rules switch user

This module adds two new Rules actions:

  • Switch to another user
  • Switch back from another user

These actions could be useful when you have an operation that you want an unprivileged user to use but it fails because the user doesn't have sufficient permissions.

Create a fictitious user with sufficient permissions and switch to this user when performing the Rules action and switch back again when done.

EDIT This answer is just a workaround and does not speak to the question directly, namely why the current permissions doled out are not allowing the Rule to execute successfully.

Improve this answer
2
  • I'm not asking for a new module which can solve a potential problem with the original module. I'm simply after a reasonable explanation of what's going on here. Either there is a good explanation for this, or it's an error. If it is the latter, then that problem must be fixed - and installing a new module is not a way to fix another module's bugs. – sbrattla Mar 4 '16 at 9:59
  • I somehow agree with @sbrattla that I wouldn't want to add a module like this as a work around. But at the same time I would massage this answer into something like "Have a look at this module ... not to actually use it (as a work around), but as some kind of indication (proof?) that Rules does (should?) respect the permissions granted to the user who triggered a rule ... Because if that would not be the case, then why would anybody ever need this module?". Feel free to reword / refine / enhance my suggestion here if you do want to consider it. PS: I would like to see "the" rule in the OP! – Pierre.Vriens Mar 4 '16 at 11:03
1

IMO your "issue" (that the value of your field is blank) is because of the event (= "after saving a new user account") you are using, which might simply not be the right event. If this user is still "blocked" (= in case your registration procedure requires admin approval), it could make sense for the Rules module to not show the content of this field yet.

Moreover, have a look at issue # 430274, about an event which is a variation of your event here, and somehow explains that "after saving something" actually happens ... "before saving something" (which is not a bug, simply how Rules works ...).

A possible compromise to avoid these kind of issues, is to transform sending your eMail into a Rules Component, so that your original Rule "schedules the execution" (using the Rules Scheduler submodule) of that Rules Component (eg X secs or mins "after saving that new user account" ... if your cron job runs frequent enough, if not it'll be next time cron runs). This compromise will ensure that at the time the Rules Component is executed, the new user account is for sure saved ... (so that can't be the reason anymore then why that field would still be blank ...).

Using this Rules Component approach, you might even take into consideration that you only want to have this eMail send if the user account is "no longer blocked" (if it is still blocked, add some extra Rules logic to reschedule the same component to re-execute somewhere later on).

And by the way: anything about Rules that uses the Rules Scheduler, runs for sure with "Anonymous" authorizations. There are cases (Rules Actions) for which that auth is insufficient of course (eg: create a new nod is not allowed by Anonymous). Even for these cases there is a way to resolve that also (if you want to know how to do that: post a followup question about it).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.