2

My organization wants to create access to specific resources and materials based on a role, but the issue is that there is the potential for dozens of such roles, each granting access to specific materials.

Is there a better way to manage this without having to have dozens of roles and permissions in the system, such as to use taxonomy or something else that is set up to accommodate such a volume?

Scenario:

A user can access our site and pay for and subscribe for special access to sections A, B, and C, each separately. Then we would need a way to track who has paid for access to which sections. I believe the section would include text, downloads, and possibly a forum and training videos.

Note: CiviCRM takes and tracks payments and memberships.

  • If these "roles" only gate content (no other permissions needed) you could possibly add a user field for these "roles" that's attached to a taxonomy, then create some custom access permissions for your content types. But it seems like just as much work as setting up roles... what are your concerns about having dozens of roles? it shouldnt affect performance too much IMO – longboardnode Jan 18 '18 at 1:32
  • My concern was having a list of permissions associated with each role multiplied so many times, editing and saving them taking extra processing power and stability issues. As well as the amount of work to the system each time the organization wants to add content. It just seems messy. – Christia Jan 18 '18 at 1:39
  • what do you have available in your site to actually facilitate, track, those payments and subscriptions in your site ( per the scenario in your updated question)? – Pierre.Vriens Jan 18 '18 at 21:45
1

Have a look at the Group module (commonly perceived as an alternative for Organic Groups).

Group allows for creating arbitrary collections of your content and users on your site, and grant access control permissions on those collections. It is available as of D7, and has a D8 version also. The Group module creates groups as entities, making them fully fieldable, extensible and exportable. Which also makes it integrate very well (out of the box) with commonly used modules such as Rules, Views, etc.

Some more questions you may want to look at for more details:

Sample configuration

Below is an example of a possible configuration, which may help to get you started with possible configurations (using the Group module):

Group type ID ! Group type ! Group role ID ! Role
--------------+------------+---------------+------------
 1            ! Class      ! 3             ! Instructor
 1            ! Class      ! 4             ! Student
 2            ! Customers  ! 5             ! Lead
 2            ! Customers  ! 6             ! Prospect
 2            ! Customers  ! 7             ! Licensed Customer
 2            ! Customers  ! 8             ! Sales
 2            ! Customers  ! 9             ! Support
 2            ! Customers  ! 10            ! Accounting
 2            ! Customers  ! 11            ! R&D
 3            ! Project    ! 12            ! Project Manager
 3            ! Project    ! 13            ! Developer
 3            ! Project    ! 14            ! Customer 

Group Types

The above example consists of 3 group types:

  • Class.
  • Customers.
  • Project.

Group Roles

For each of the 3 group types, there are specific Roles defined, some more details about some of them:

  • for the Class group, these are the 2 roles that are configured:
    • Instructor.
    • Student.
  • for the Project group, these are the 3 roles that are configured:
    • Project Manager.
    • Developer.
    • Customer.

These are the Group Specific Roles: these roles can be configured per group type and will only be available on groups of that group type. As an example, for group type "Class", the defined roles are Instructor and Student (which are not available for the other group types.

On top of the group specific roles, there are also Special Global Roles: These are the special (hardcoded) roles named Outsider (= a signed in user that did not join a group) and Member (= a signed in user that did join a group). These cannot be defined by the Drupal administrator, and they are always available for any group. These roles can have different permissions sets for each group type. Special case: the role Anonymous is related to a user that is not signed.

Groups

Each of the configured group types can have any number of Groups.

Examples of groups:

  • for the Class group type, there could be these Groups:
    • Getting started with Drupal.
    • Drupal for site builders.
    • Become an expert in using the Rules module.
  • for the Customers group type, there could be these Groups:
    • Service Requests.
    • Order Processing.
    • Sales Orders.
    • Relationship Management.

Permissions

For each of the configured group types, you can then also configure for each Content Type which Role has what kind of access (= none, view, create, edit, delete). Be aware: even though this looks similar to Drupal's permission configuration, these permissions are not the same permissions (they are specific to the Group module).

Rules integration

Since you seem to be using CiviCRM also, you should definitely also consider using the CiviCRM Entity module, especially because of its integration with the Rules module ... combined with automagically creating (or deleting) so called "Group memberships" (which you can do via Rules). For an example of how to use Rules to create or remove such group memberships, refer to my answer to "How to add and delete a user to another group using the Group module?".

Resources

Note

About your concern (as in your additional comment), which includes:

... having a list of permissions associated with each role multiplied so many times, editing and saving them taking extra processing power and stability issues. As well as the amount of work to the system each time the organization wants to add content. It just seems messy.

You're right, using standard Drupal permissions (with a zillion of roles) it would indeed become messy. But after you realize/discover how the Group module's roles/permissions work, your concern should be addressed ...

  • Thank you! We are also using CiviCRM and want to use that to manage the subscription process. I didn't mention this in my original post, but it sounds like the Group module is what we need. I'll need to see if it will work with the CRM and get back to you, thank you! – Christia Jan 18 '18 at 17:35
0

The Monster Menus Module was developed especially for educational organizations, but can be used outside of that context as well. It allows you to have many different groups with different permissions that are controlled by the module instead of Drupal itself.

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.