3

For instance, my site contains two roles:

  • employer.
  • company.

Every company has to be able to add, edit and delete there own employees.

As you may understand, companies should not be able to edit or delete users created by other companies.

How can I achieve this?

0
3

The Organic groups module (as already suggested in another answer) is indeed a possible answer to your question. But you should also have a look at the (fairly new) alternative for it, which is the Group module (with it roots close to where Dries started Drupal ...). Some more details about it (from its project page):

Organic Groups allows content itself to be groups, which isn't always what people want. It relies on an entity reference field to keep track of the ties between a group (node, term, ...) and its content (node, term, user, ...).

Groups instead creates groups as entities, making them fully fieldable, extensible and exportable. Every group can have users, roles and permissions attached to it. Groups can also act as a parent of any type of entity. Seeing as a group itself is also an entity, creating subgroups is very easy.

Even though it only has a beta release for D7 so far, its Usage statistics seem to indicate it is like a "rising star". And I've heard it mentioned recently in various occasions as a valid alternative for the "heavy" Organic groups module.

The Group module also integrate nicely with the Rules module, as explained in comment #2 of issue 2603136, which states the following:

... you can already use Rules to:

  • Add a new Group
  • Create a new GroupMembership and save it (the equivalent of $group->addMember())
  • Add or remove a GroupRole from a GroupType
  • React on new GroupMembership or Group entities

What hasn't been done yet is custom Rules actions or conditions. Seeing as 90%+ of Group is pure Entity API CRUD-operations, there has been no custom Rules code yet given how much you can already accomplish out-of-the-box.

Useful Rules we may add could be:

  • E-mail all members of a Group, optionally filtered by GroupRole
  • Easier-to-understand labels for the above list: "Member joined group" sounds easier than "GroupMembership entity is created"

...

Refer to Integrations with other modules and its "Related issues" about other modules for which integrations already exist, or are in the pipeline.

PS: Refer to How to implement an option for users to limit access to nodes/comments to users with the same role while posting it? for an interesting illustration of how this module can be used.

2

OG is one way to do this as others suggested. But for this particular use case you can get away without using it. However, you may find OG useful if it plays well with other parts of your application.

Here is what you can do:

  1. Add an entity reference field (field_company_ref) to the user object. This field will store the company user id of an employer.

  2. Use hook_menu_alter to alter the access callback of the user/%user and user/%user/edit pages. The result will be that the system will run your custom access functions before it displays the pages:

    /**
     * Implements hook_menu_alter().
     */
    function mymodule_menu_alter(&$items) {
      $items['user/%user']['access callback'] = 'mymodule_user_view_access';
      $items['user/%user/edit']['access callback'] = 'mymodule_user_edit_access';
    }
    
    /**
     * Hook_menu access callback
     */
    function mymodule_user_view_access($user) {
      // Add logic to determine if the user visiting the page  user/%user has permission to view it. Return TRUE or FALSE.
      // You may want to look this for the default access callback: user_view_access() 
    }
    
    /**
     * Hook_menu access callback
     */
    function mymodule_user_edit_access($user) { }
    
  3. Additionally, you will want to do a hook_form_alter() to alter the properties of the user form page:

    • Add you custom validation function in $form['#validate'] array to make sure that the user submitting the user form is legit.
    • Add a custom submit function in the $form['#submit'] array to set the value of the field_company_ref to the user id of the company creating the user.
    • Add a $form['field_company_ref']['#access'] = FALSE so that the user will not be able to view/change this field when editing his user details
2

When I asked this question I actually thought of an answer like Mike gave me, till I started experimenting with this really interesting group module a few hours ago.

Using the group module I was able to:

  • Enable companies to edit fields of employees on special group member profiles.
  • Give employees in a group, owned by a company, the permission to create, edit and delete certain nodes.
  • Enable companies to add existing users to their company group.
  • Enable companies to remove existing users from their company group

I wasn't able to:

  • Enable companies to edit the basic account information of employees (username, e-mail and password).
  • Enable companies to delete their employees.

It doesn't really matter to me that companies aren't able to edit and delete their employees as they are able to remove them from their group. This is why I 'll probably continue using the group module.

2
  • Fantastic to read what you were able to achieve already. For the things you weren't able to do, you might want to post a new "followup question" maybe (referring to this question to describe why you're using the group module now)? Variation: use most of the content of your answer here as the new question (and delete your own answer here). With that some day you might also mark any of the answers to this question as "accepted" then (via the checkbox below the up/downvote icons next to each answer). Feb 12 '16 at 18:09
  • Hi, I am struggling to to something similar as this. Were you able to restrict the companies profile view of their own users? For example: Company A cannot see users from Company B, even if they change the user ID in the URL.
    – Drii7
    Apr 3 '16 at 23:23
1

I would recommend using og module, with help of og module you can define a group(company as in your case) and then there can be members of the group(employers in your case) and with in group you can have group admin which can have permission to edit other members in the group.

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