Hi,

The new rule "create user from LS if not exists" uses the last name field that is specific to the survey you had created. Since my survey id will be different, this will lead to an error (resolved by picking the appropriate last name field from my token entity).

In addition to this specific problem, there are fields that all tokens will have in common as they are in all limesurvey tokens. Rules that use only these fields should, ideally, not have to be rewritten for each new survey, imo.

Whether through entity and bundle or another approach, might there be a way to have the basic token entity not be survey-specific, while allowing for additional fields such as multiple attributes? This would avoid the sort of error I just encountered and allow for more flexible rules.

Thanks.

Comments

jsibley created an issue. See original summary.

thedut’s picture

thedut CreditAttribution: thedut commented

Hello,

I don't understand which error you mean saying :

The new rule "create user from LS if not exists" uses the last name field that is specific to the survey you had created. Since my survey id will be different, this will lead to an error (resolved by picking the appropriate last name field from my token entity).

The creation of user is based on the Token email. Lastname is used only to populate the Drupal User name property.
You need to replicate (clone) Rules for each survey ID.

In addition to this specific problem, there are fields that all tokens will have in common as they are in all limesurvey tokens. Rules that use only these fields should, ideally, not have to be rewritten for each new survey, imo.
Whether through entity and bundle or another approach, might there be a way to have the basic token entity not be survey-specific, while allowing for additional fields such as multiple attributes? This would avoid the sort of error I just encountered and allow for more flexible rules.

Yes, you right. But the it will consome more developements, and the result will be less robust regarding synchronization. Consider this as a feature request I won't implement soon. Hopefully, the LimeSurvey Sync module provide default rules for each Survey ID and you can clone Rules in order to easily use the "same" rules for each survey ID.

jsibley’s picture

jsibley CreditAttribution: jsibley commented

I'll try to explain the issue.

When updating to this version, a rule component is added that is marked as not working, because a step in the rule refers to the last name field in a token that is unlikely to match the local setup, as it is token XXXXX (I forget the actual number) while anyone else is going to have token YYYYY.

It's not a big deal to go in and change the reference to the correct token, but if that's the plan it should probably be documented at some point.

thedut’s picture

thedut CreditAttribution: thedut commented
Status: Active » Closed (cannot reproduce)

I guess you are talking about the Rules component : LimeSurvey sync Token XXXXXX : create user from LS if not exists (at admin/config/workflow/rules/components/manage/rules_limesurvey_sync_token_XXXXXX_create_user_ls2dp)
I can't reproduce this issue.
Anyway you have fixed it on your drupal install.

jsibley’s picture

jsibley CreditAttribution: jsibley commented

I think you can't reproduce the issue because your XXXXXXX matches the rule, understandably.

For anyone else, it won't match. Again, not a big deal, but without future documentation, folks might wonder why a rule starts out marked as having an error.