Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
For our needs, we have build a contrib module to define roles to assign for user when subscribing to subs type. It depends on subs status (add/remove roles to user).
Indeed, we cannot use rules as each time a new role/subs type is created, we also need to create a new rule.
I don't provide more details as a description is available into the readme.txt
It still need works, reviews and testings.
All feedbacks will be appreciate.
Thanks you for testing, review, bug reports if you are interesting by this feature !
Comment | File | Size | Author |
---|---|---|---|
#5 | subs-subs_roles-1691454-2.patch | 15.69 KB | chaby |
#1 | subs-subs_roles-1691454-1.patch | 11.28 KB | chaby |
Comments
Comment #1
chaby CreditAttribution: chaby commentedhere the patch
Comment #2
alexweber CreditAttribution: alexweber commentedI've taken a look at the module and it looks good and the functionality is kinda specific but interesting to have as a submodule.
The patch doesn't apply cleanly but it works. I'm going to commit this and then gradually work on cleaning it up.
Comment #3
alexweber CreditAttribution: alexweber commentedI've reviewed the code in detail and whereas I like the feature, I think we can implement it in a better way.
I don't really like how we can only pick one status and how its risky to get roles accidentally removed.
Here are some suggestions:
Could we maybe create a new set and unset roles rule per subs type instead?
If not, we should allow the user to specify N conditions; for each status we should be able to add/remove any number of roles.
Personally I think the rules approach is cleaner but I'm not sure if it fits your use case. Please let me know so we can decide where to go from here.
Comment #4
chaby CreditAttribution: chaby commentedhi,
First of all, thanks for review and feedback !
That's true. This is only for simple use case...Otherwise, i fear that it begins to be more complex...
I agree but thinking this is more in charge to the administrator to deals and take care about this. For e.g :
- a user have already a role 'foo' for particular reason. He subscribe to a role which set the role 'foo' again. When subs will be expired, this role will be removed even if he have this role before being subscribe.
- a user have a role 'foo' assign by subs '1'. He is also subscribe to subs '2' which set the same role 'foo'. If only one of this subs have been expired (in fact match the subs status triggered), for e.g subs 1 expired, role 'foo' will be removed even if he is still subscribe to subs '2'.
- sure i have miss some other use cases ? Did you have any other ideas ?
So, we could conclude that limits are :
- create specific roles which are only deals with subs status
- set further roles to only one subs type which are trigger by only one subs status
Indeed, if you have a lot of subcriptions types and roles to assign, it begins to be a real mess...!
Did you means creating automatically rules (for administrator which don't know and don't have to administer rules) ?
I confess that i'm not a rules expert...! And it could be a real pain to implement it (mostly if administators could manage to use rules directly...)
Of course ! If an administrator could create a rule each time there is a new role to assign to a particular status (and mostly if further conditions need to be matched), this is definitively better and this module don't have to be used ! But in our simple use case, administrator just cannot manage with rules module...
To resume, this simple module aims at :
- adding/removing further specific roles to only one subs type which are trigger by only one subs status. It means that :
-> this roles are specific to only one subs types
-> this roles needs to be added/removed only through subs status
-> it concerns only simple use case (otherwise, use rules module or custom code)
- to be an helper module for administrator which don't know how to use rules and mostly don't have permission to use it !
- provide a way for similar simple use case to project which don't need to use rules module...
These points underlines that it still needs some work :
- on the subs type edit page, check that a role isn't already used by an another subs type
Finally, i think we could say that :
- this module haven't to be added to subs project. If needs are more complex, just used an another way to do it (rules, custom code). So subs could clearly live without this module !
- open a new project instead ?
Are you agree with this or i miss something ?
Thank you again for feedback
Comment #5
chaby CreditAttribution: chaby commentedAnyway where to go from here, here an another patch which :
- fix issue above :
- a simple views integration (field handlers for roles to add/remove per subs types)
Comment #6
chaby CreditAttribution: chaby commentedAs see with alexweber, live into its own project now.
Currently available in sandbox but would be soon promote to full project.