3

My site has roles for administrators, students, and teachers. Students create nodes, and each student has exactly one teacher. Teachers should be able to view all content created by their students, but no content created by other students. In other words, I'd like to have some kind of per-user setting that allows me to select one specific other user who can access the first user's nodes.

This seems like a pretty common situation, but I can't figure out how to do it. I'm open to any suggestions. Here are some things I've looked at so far:

  • I started out by using references to link each student to a teacher. However, I couldn't find a way to use that relationship for access control.

  • The subuser module looks appropriate, but I'm leery since the D7 version is still in alpha. Has anyone used it for this purpose?

  • Taxonomy access control looks like another possibility. The list of teachers is static, so it could be made into a vocabulary. But if Teacher is a per-student setting, is there a reasonable way to make that propagate down to the nodes created by that student?

  • Any other suggestions about how to do this?

3

I've had success with multiple node authors using

nodeaccess_userreference

Gives content access permissions to users for content that references the users with User reference or Entity reference.

nodeaccess_userreference settings

and also with

nodeaccess_nodereference

Gives content access permissions to users if they have access to content that is referenced with Node reference or Entity reference.

Checks view, update, and delete grant operations, and can pass those on to the referencing content, or trigger a different grant configuration according to settings.

nodeaccess_nodereference settings

In combination with field_permissions or hook_field_access, for restricting access to the reference field, that should enable the feature you're looking for there.

You may want to look at using Rules to set the reference field value on node save as well.

2
  • It sounds like nodeaccess_userreference is exactly what I want! I'll try it out in the morning and report back.
    – octern
    Jan 8 '13 at 7:34
  • Thanks! I wasn't familiar with Rules before, but that turns out to be the perfect way to get the user setting for teacher to propagate to each node the user creates. I now have a working solution... except that Node Access User Reference appears to try to set permissions for a newly created node twice, leading to a unique key violation in node_access and a rollback of the entire node creation. I've posted about that problem here.
    – octern
    Jan 9 '13 at 20:38
2

Similar ground is covered under this question on StackOverflow: https://stackoverflow.com/questions/2289004/how-do-i-give-a-specific-user-editing-rights-to-a-specific-node/13466946 You may get some ideas by looking at it.

As an alternative to Node Access (which is up to the task, but unsupported) you may want to look at the Flexi Access module. It gives you a straightforward way to set up access control lists (ACLs) for individal nodes.

What it doesn't (currently) give you is an automatic method of assigning ACLs. I.e. when a new node is created, someone with the right to administer nodes must manually create an ACL for the node.

Its development status is still alpha. However, there are no open bugs in the issue queue and I promise that any reported new bugs will be dealt with in an timely manner.

Disclosure: I'm the maintainer of Flexi access, but I hope this does not violate the site's policy on self-promotion.

2
  • Unfortunately, giving automatic editing rights on new nodes (based on the node's creator) is precisely what I need to do. However, many thanks for describing your project's functionality clearly enough that this was readily apparent.
    – octern
    Jan 8 '13 at 7:33
  • But thank you for pointing me to that other question! At first I ignored it because it sounded like it wasn't relevant to automatic permissions, but it actually had some great advice.
    – octern
    Jan 9 '13 at 20:11
1

Well, if nothing else will work, you can at least use Organic Groups and make a group around each Teacher, and put the students in those groups. You can then control the visibility of the posts made by students, because they will be in a specific group. Also, you must make all groups private, so people from one group cannot see posts in another group. Maybe the Teacher can also be the moderator or owner of her group.

0

modules needed: subuser module (needs relation) and Node Access Relation (node_access_relation). Set up subuser, add subusers, make a relation-type called 'share-content' (admin/structure/relation_types/add), make it from user to node, set access as needed in node access relation. review your permissions. if you need more granularity add field permissions module.

to have total control of access both ways parent to child, child to parent, a detail way to do it is with some woodoo: add a hidden field entityreference trick field on contentype called "original-author", with rules allways set the content author the parent user, set trick field as real node-author. this way your content is acesible to all subusers as detail as needed, and you can access real node-author if needed. share content is done by relation module, views arguments are with entityreference and maybe need a default value with php contextual filter.

EDIT:with https://www.drupal.org/project/abt, i also succed to handle user and subuser access permission, you have to have a saved term reference field (same field, same tid) common in user account and in node. You have to have a diferent term reference field for every user role and this field must be present in user account and in node structure. Once to get it, you can handle with rules (long and complicated rules) to set these values on node save. Permissions are handeled in NODE term reference field settings. Set node term reference view to: yes, but allow..., and update to: yes, but restrict.... Set permissions for only term refrence field on node in the fields that are pointing to the user that you wish user to have access to your node. What happens under the hood is that node and user are conected by the same tid and grants accsess. So, for one group you have to have a set of taxonomy terms (on same taxonomy), for a diferent group, you nedd to add another set of terms. With such structure, group one won't have access to content on group two, etc. because tid's are diferent.

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.