Role assignment modules - Unite!

Posted by ilo on May 25, 2009 at 10:56pm

Hi, all, I just started helping Alan with a Registration module and realized there are a lot of similar modules, all duplicating functionalities, and I would like to notice that to all the module mantainers.

The objective will be to have all functionality listed and see if really there's the need of so many modules. Maybe some of these funcionalities would have merged and splitted into two very different modules at all, or some of the included as helper modules of a main Role registration module. After a quick review I made this quick project list:

http://drupal.org/project/autoassignrole
http://drupal.org/project/user_autorole
http://drupal.org/project/registration_role
http://drupal.org/project/rolekey
http://drupal.org/project/regcode
http://drupal.org/project/og_joinrole
http://drupal.org/project/rolereferral

Some of the modules are half abandoned, some others don't support D5.x and others don't have a D6.x branch yet. Almost all provide the same funcionality: give roles automatically (optionally given a registration password or code). Where additional functionality is enabled for one version, it's broken for the other, and now it's a "tell me drupal version and functionality and I will tell you wich one to use"..

Also I've found external references to this functionality:
http://www.francescobrunetta.it/en/node/232

Others involved in this conversation would be:
http://drupal.org/project/roleassign (as it provides permissions to manage roles which can be shared between all the modules)
http://drupal.org/project/role_delegation (quite similar to previous)
http://drupal.org/project/role_watchdog (track changes in roles)
http://drupal.org/project/role_limits
http://drupal.org/project/role_change_notify

And not sure if they should be here:
http://drupal.org/project/openid-teams
http://drupal.org/project/shib_auth

Why don't we all take over this nightmare and start a formal community contribution? I kindly invite all the involved people to post their impressions and end with just a solution for the contrib on role assignment.

PD: if I left someone or somewhat, and you think it should be included, please contact him directly. I'll try to contact the listed modules mantainers.
Updated: more modules included.

Comments

Steps

Posted by danielnolde on May 27, 2009 at 3:00pm

Great, this module review group is a perfect base to work on - joined.

You're right, we should take other functionally related modules into consideration.

The idea then should be to unite modules and efforts in the field of "changing the user's status based on provided key" into one modular and extensible approach, right?
Then we have to define what will be included, what will be supported/extensible and what not, what's inside and outside of a united module's focus.
Then comes the feature list and review, then the decision what feature to implement/integrate how and where.

I personally currently tend towards the approach that we together build a new unified module.
Not implemented from scratch, since we have plenty of code for single aspects and approaches in the different modules (like implementing hook_user and handling registration etc.).
But planned from scratch, fresh and with a newly thought-over modular and extensible architecture.
The features and implementations themselves can then be drawn together from the different modules, refactored and integrated in modular ways into a common base/api (this way we can also perfectly split this work between all collaborators of us).

Btw.: If we get this working within the next 3 months, we could provide a session/workshop or BoF at DrupalCon Paris about how to practically approach collaboratively merging and refactoring modules... that'd be nice :)

So currently, i see the tasks as followed:
1.) Set the field, scope and focus of our effort (that's quite important)
2.) Identify the modules to take into consideration (you've already done that - check).
3.) Identify the current and the future feature-sets we have to map or support (a feature-sheet)
4.) Identify a suitable common extensible modular architecture as basis of the new module
5.) Identify what features we want to implement at which point of time, what features to base on or to leave to others modules (if there are generic implementations of features like a CRUD-interface, an import-facility etc.)
6.) Map/combine feature to modular units / sub-modules / add-ons, and what to implement in a lean base module.
7.) Assign the implementation of the lean base module and features to collaborators - each one could decide where to draw code from for the implementation of each.

What do you think?

I agree with almost all the

Posted by ilo on May 27, 2009 at 6:02pm

I agree with almost all the steps, even if some of them could be paralelized.. I mean, having a 'current feature set' is as important as a 'final feature set', being the features coded or not. What I've seen most important, and should be step 1, is to get all the current mantainers joining this effort, and this is probably the most critical path. There are work for almost every mantainer and probably even more. Also, we could reach a scope creep with a 'modular/extensive/flexible implementation, finishing in the same situation we are right now. When should we introduce current module users into the conversation? I guess they would have something to say also here.

For me, Items that are clear could be: Keywords are "role" and "assignment". The rest of terminology: automatic or not, on registration or on promotion, based in token, word or url etc, are functionalities using the role assignment feature and for sure deserve it's own space, as they will lead and settle requeriments for the whole keywords.

Because of this, I would understand not all modules should be merged. I mean, "role assignment by keyword" modules could be merged separatelly from this group right now, and later integrate into the whole effort. Am I right?

Other important Idea is to move from here to Wiki based or something more flexible than a group conversation.. who takes the lead on this?

While this starts to move on, we are trying to do the merge of regcode and rolekey, the way we do may help others in this worfklow to join the group.

Good roadmap, state this somewhere and lets begin!!

steps, parallelizaton:

Posted by danielnolde on May 27, 2009 at 10:19pm

steps, parallelizaton: agreed
danger of scope creep: Let's have tightly maintained "core featureset" via a fixed set of submodules - and the architectural possibility/basis for more specific/exotic add-ons (role model: OG or CCK with their tightly maintained core functionality and add-on biosphere)!
field for our work: role-assignment is definitely too narrow and on the otherhand also too wide/ambiguous, since a huge jungle of "role assigment" modules are out there, which has in large parts no affiliation to what we talk about (what's with all the "buy role via übercart", "manage group-specific role only in specific og groups" etc. ... ??). The incredible broad field of use case "role assigment" already has got a well craftet and extensible api basis: The user.module and its hooks. This is not the area we're talking about. I'm sure we have to:
a) include the aspect of code-input as third main field (reg.key/code-word, whatever) to make sense of half your module list
b) be more specific in the field-definition as to what use-cases of role-assignemnt-via-code/action we want to cover, and what not.

My suggestions is to define the field of our effort by a suitabe overlap of the three aspects

alter...the...user's/registration-status...via...user-given codekey.

This definitely needs a better definition, but in any case, the api basis of the united module we're to built should concentrate in this use-case-wise narrow but functionally generic overlapping-field. It should be the base for more specific (not more general) use-cases, extendable by api-based add-ons - It should not be just a pimped version of user.module's role-related hooks, and we're hopefuly not talking about any assignment of a role to a user by any event, are we?

Well, actually I disagree

Posted by ilo on May 27, 2009 at 11:02pm

Well, actually I disagree with this: 'Let's have tightly maintained "core featureset" via a fixed set of submodules'. This is the indirect purpose of the contrib modules, and a better or worse approach is our hability to handle this.

Ok, so you want to move the whole thread to:
- Focus on registration
- Focus roles
- Focus on a third factor (key, refering url, whatever)

Let's hear the rest of module mantainers once they join this thread, just for consideration.

I would suggest you can take the lead on this roadmap.. can you?

CiviCRM Role sync

Posted by matt2000 on May 27, 2009 at 11:38pm

If we're talking about role integration with other systems like OG, this might also be worth noting:

http://drupal.org/project/civimember_roles

Matt

Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000

Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000

scope of merge

Posted by Olarin on June 1, 2009 at 8:07pm

I think this effort to identify and merge duplicate modules is a great idea. However, I don't believe my module "Role Referral" belongs in your initial list of duplicates. All of the other modules you listed involve means of auto-assigning roles on registration, or allowing registered users to self-assign roles. "Role Referral" allows for the temporary assignment of a role to an anonymous user who comes to the site via a special link from a specified partner site. It is a very specialized module which was created to address a particular and slightly uncommon use case (our client wanted registered users of other sites which we do not administer to be able to immediately see private content on our site without having to register an account). As such, I think it is wisest to keep it as its own, separate, self-contained module.

Hang on

Posted by aidanlis on June 17, 2009 at 8:29am

I think you're getting ahead of yourselves - our aim should not be to build a huge monolithic module that encompasses many different tasks, but to allow these various modules to work well together. That's the Drupal way.

Role assignment has nothing to do with registration codes. If people want to set a role for people using a certain registration code, then use the Rules module (registration codes module should fire an appropriate event), or create a separate module that depends on registration codes, and listens on hook_user.

Both of these approaches give you the desired control, and keeps each module lean.

you're absolutely

Posted by danielnolde on June 17, 2009 at 8:43am

you're absolutely right.
Personally, my goal is to build an open, modular an d extensible framework for "registration code", as well as "role assigment via third factor" (as suggested by ilo).
Of course you can build many things with generic tools like rules.module - however, having to install rules only to be able to simply assign a role via registration code (which a great deal of reg-code-users want to do!) would be totally overkill and also a problem for many non-technical thinking users (we have to adress them, too!).

So, yes, the goal should not be a monolithic module, but a lean extensible framework around the ideas of "registration code" and "role assigment via third factor", that allows a small biosphere of submodules to do different tasks involved selectively as needed.

drupal has many paths, all of them reach heaven..

Posted by ilo on June 17, 2009 at 9:11am

You are right, we can have several modules doing different things.. This is the CURRENT status.. just take a look at the list included in the first post. Currently, we have confirmation of other mantainers and we are going to merge "rolekey", "regcode" and "role keyword registration", providing support for drupal 5, 6 and 7. This one, regcode is included and as Colan stated, the goal should be "the best for the users".

I can't force you to not continue on this, do your own, you already have cvs access, so it's up to you. I would dissagree totally in this. We should focus on cleaning the issue queue, and this probably will increase the number of issues in this module.

Are we overloading the purpose of the module? may be.. if this is the case, any help would be appreaciated, feel free to consider providing help and contribute with your own support in this effort.

ilo, not shure what post you

Posted by danielnolde on June 17, 2009 at 9:44am

ilo, not shure what post you answer to.
There's perhaps some misunderstanding, and it would be helpful if you say clear, what you mean with "I can't force you to not continue on this".
"This"?

sorry Daniel..

Posted by ilo on June 17, 2009 at 10:00am

it was a reply to aidanlis (http://groups.drupal.org/node/22567#comment-80709), regarding continuing with the development of regcode. I guess I didn't click the reply button and answered in the whole thread disc.

I mean, I would preffer to not continue evolving regcode in favor of the merge, but if people want to do, there's nothing I can do, but encourage and help.

Something is better than nothing

Posted by aidanlis on June 17, 2009 at 11:57pm

Hi ilo,

Although I appreciate what you are trying to do, and surely such a module would be nice, but isn't something better than nothing? It's been a full year and no progress has been made. There wasn't even a branch for Drupal 6!

The option you present entails a few more months of discussion on which modules would merge and how best to handle it. Instead, I have provided a limited subset of functionality, a clear scope, and made it all available immediately!

Whatever direction we go in now, nothing has been lost, all doors are still open.

This is what I think should happen:
a) The registration code module provides exactly what the name says, registration codes. It allows registration codes to be used during registration, and it allows the import, export, listing and generation of registration codes.

b) The registration roles module also provides exactly what the name says, registration roles. On a registration event, the module kicks in and based on certain conditions (be it a certain registration code being used, or registering after visiting a referrer, or even the time, date or country) a role is set for the user (either permanently or for a fixed amount of time).

This is all quite easy to achieve given the various hooks and signals that can be used, and it means that all of the functionality is separate and maintainable. I have no interest in the registration roles module, but I will ensure the regcode module does its best to provide adequate hooks and signals.

I look forward to everyone's support. Also danielnolde I'd still love to have you maintain the D5 version and enhance the D6 version, do you want to apply for a CVS account?

For sure..

Posted by ilo on June 18, 2009 at 12:45am

I agree with you at all. As I said, now I can do nothing but help you if you need some support from us. Don't worry, despite the work we have already started, we can roll back some of our time and efforts, and rewrite the 'feature list' again just because this module has been removed from the list, we can also re-design the upgrade path, and yes, a task planned for 1 or 2 months will take more than expected, but just because of interruptions like this.

You were very excited in having a "one year stopped module" working and supported in almost for every version of drupal in just one day. Amazing, I've never had such brave inititative. in fact, I've to schedule my time in several dev groups, I don't like to go my own. But the excitement is not a good fellow (I have some experience in this), and is the worst fellow if you are alone on your own.

You now have published a "condened" module as stable for d4, d5 and d6. Good work after all. We may have inifinite number of modules (we now do have several modules in the list) and all of them will end doing the same more or less, as already happened with some of the listed, and this is the reason why are they being merged.

All of them finish sharing the same problems also (read the issues with login toboggan in almost all the registration listed modules). We run slowly in the approach, because we'll never publish a stable version not working. And this is not my fault, but take a look to issue http://drupal.org/node/494792 : "Incomplete database schema, module is not working"

For sure, in a short future, once we have finished the merging or whatever we could achieve, someone will realize your A) and B) potins can be mixed, and ask for: "I would like to have a code that grants me a role during registration". What should we do? create another module? ask you to please implement this "out of scope" feature? or just ask for registration role to create a "code based" feature?

And now that you mention drupal way, lets talk about drupal way:
- about collaboration? no one word about..
- about design and proposal? no one word about..
- did you realized the group name you are writting in?

Did you at least request the status of the merging operation? NO
Did you offer your support on the module merging and your intention to support this module separately? NO
Did you test the module before creating the stable releases? should I say NO also here?
Did you tell the module users about the future (or present) changes?

Damm, I don't know much about drupal's way, but not sure if this is the right one!

I'm running out of the scope of this thread, so to resume: as I said, I aggree in the goal, not in the path. I will remove this module from the 'confirmed' list. In fact, I can't understand why are we talking about this now, and not had an earlier discussion about it just to share ideas.

Despite the hard language/expressions in this answer, just ask if you need some help or would like to consider other approaches.

mmm must be a joke?

Posted by ilo on June 18, 2009 at 1:00am

Aidanlis, just reviewed the regcode project page and realized this:

"This module is designed to be extended by "Registration Roles" modules, which allow assigning a role depending on the registration code used."

So, should I guess do we have to care about integrating this module in our design efforts? did you forget to tell us?

I'm a busy person

Posted by aidanlis on June 18, 2009 at 8:22am

Hi ilo,

To address your previous post: I have absolutely no interest in "schedule my time in several dev groups". I am a busy person, a client needed a registration code module, there were none available (ostensibly because you're all sitting around in here discussing how to pull your thumb out), so I wrote one and released it. It took a day, done, sorted, no hassle.

Last night I developed a basic Registration Roles module that ties in with Registration Codes, it took one night. No writing feature lists, no merging and branching and building a team, just you know ... actually doing it. I'm going to polish it up and release it as a new module later this month, when I have some more free time.

You are welcome to continue planning, and umming and arring over which modules are going to be merged, etc, and I'm always open to any suggestions you have, but this module solves an immediate problem that many users have not had a solution to for 12 months. You've spent more time here discussing the issue than it would have taken to solve.

In summary, I would love you all to feel welcome to contribute to either regcode or regroles, either through planning new features, helping out on the issue queue, or backporting changes to D5.

All the best,
Aidan

Talk is cheap. Code is

Posted by Garrett Albright on June 18, 2009 at 5:54pm

Talk is cheap. Code is golden. Well done, aidanlis; you had a problem and you solved it. This is a good example of why I can't subscribe to the "duplicate modules are inherently evil" mindset.

The Boise Drupal Guy!

Documentation is golden

Posted by Alan D. on July 23, 2009 at 10:09am

Both features are available via the role key (optionally available via registration and my account forms), which has been available via the forums for over a year for D5 and recently pushed into D6. I'm guessing better doco would have been helpful to prevent duplication

@aidanlis If you combine the features into a single module, I'll direct users your way. Having to activate Rules is a bad performance hit / complication that many users can not handle easily, and resources (as a general rule) are exponentially consumed as you activate modules. We still haven't had any sites that actually require this type of feature, so we have had no paid support. Happy to push these features to someone that is actually getting paid for it.

It is incredibly trivial to implement these features in the user edit forms that adds some nice icing to the module.

Having already tried implementing multiple roles per key, I have not yet seen a valid use case for this. I would not recommend going down this path. As they say, KISS ;)

I dig parsimony

Posted by brst t on June 19, 2009 at 2:34pm

I just happened upon this group while looking at another comparison, noticed this and since I recently revisited this issue of role assignments, thought I'd share what I found to be a nice and neat solution.

For many, /admin/user/user is good enough. In 5, I met a few projects requiring more and found userplus to be pretty handy. Not bad and decent integration with og, but becomes unwieldy and can't filter on profile fields.

For this recent build, this process had to be easy and tuned to the purpose. So, I did it with a mix of views and views bulk operations which is one pretty fantastic swiss army knife.

First I added a new view and then a small set of relevant fields - First Name, Last Name, Roles, userid, etc and added a couple sorts and filters according to certain profile fields. Start simple, refine later.

Then I added a display 'Page' - and in the 'Basic settings', set role-access (if it's not just /user/1) and in 'Page-settings' gave it a path of /mypath/role-edit (and later added that path to my admin menu) If you're new to Views2, to edit settings, you click settings selection, edit beneath, maybe 'Override' the the default, click 'Update'. Preview below and Save as desired.

Then, back to 'Basic settings' once again, I changed the style of that display from the default 'Unformatted' to 'Bulk Operations'

Before updating the display, I then chose the bulk operations option to 'adjust settings'

'Grouping on' my often changed condition (for me it's a text field containing year eg 2009 - I find the date fields in profile in 6.x to be wonky at best )

Selected operations^*:
Modify user roles (views_bulk_operations_user_roles_action)

Update. Preview. Save as necessary.

Load the page and lo, and behold. I can now quickly edit roles on the field I set to 'group on' I can also sort, search and select individuals. Maybe make another display, overriding a few things to select on another condition. Customized ease and function. Modules I use and reuse for this or that.

^{*Note- permissions for each of these must be set if you have an editor/admin role who will be performing this function. Visit /admin/user/permissions to set before you pass it along.}

One less module for the mix

Posted by Alan D. on October 22, 2009 at 1:23pm

I'm not going to port the registration role key module in Drupal 7. As Ilo pointed out this area is a bit of a mess of duplicated functionality.

Here is a complete list of features that the module provided. Only 3/4 of these features appear to are covered in some form by the other modules mentioned above. Feel free to rip as much code as you like from this module, although I'm not sure how useful this will be in Drupal 7.

Features

The module allows you to assign 0 or more Drupal roles to a user defined key. There is no limit on the number of keys that a site can have. Keys can then be used during registration or in the "My account" area. The module needs to be configured before it is enabled on the respective areas.

Registration

Auto-assign
Just add one or more roles to the "default" key. These are automatically assigned during registration when enabled. The key should be left empty.

By a secrete
Use the password or textfield options during registration.

If there are no empty keys, then the user is forced to supply a valid key to register.

By having an empty key, this field becomes optional.

User selection

Radios, checkboxes, select list, etc, all provide the ability for the user to select the desired keys themselves.

My account area

Similar features to the registration process

There is no tracking of role assignment, it simply handles assignment of roles when the user joins.

User Selectable roles -

Posted by drecute on November 7, 2010 at 7:57pm

User Selectable roles - http://drupal.org/project/user_selectable_roles

t: @charyorde

role_delegation deprecates

Posted by lpalgarvio on November 7, 2010 at 8:16pm

role_delegation deprecates roleassign

Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org

thinking of new Role Assignment Module

Posted by tedbow on February 1, 2011 at 6:03pm

I found this thread b/c I was thinking making role assignment module and wanted to check if there was already module that did what I am trying to do. I have not found one but let know if I am missing one. I don't want to make(or at least release) a duplicate module.

Here is the proposed functionality:

1.Admin sets roles that are associated with content types
2.If a user has any nodes of the content type they are automatically given the associated role(s). This would be checked every time a node was created or changes ownership.
3.When ever a node is deleted or changes ownership the module would check to see if the previous author should have any roles removed b/c of which content types they now own(or don't own)(from #1).

Couple of reasons for this module:
1. Have made this functionality via the Rules Module before for a few sites and I think it would be easier and more flexible via a module
2. This allows for a user to a different experience or permissions based on what type of nodes they create or are given ownership of.

Other ideas for future development:
1. Have role changes be triggered by the number of values returned from an admin selected view(with author uid as the argument). This would allow for changes of roles based not just content type but other node/cck filters.
2. Have a permission such as "immune to role rule changes". If the user had a role with permission then their roles would not be changed.

Any feedback?

Core developer