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.I'm writing a module that assigns permissions to nodes based on the relationship between the node viewer and the node author. If...
- the node author and viewer are friends, the node is accessible to the viewer
- the node author and viewer are "acquaintances," the node is accessible to the viewer only if the node author allows acquaintances to view the node in question
- if there is no relationship between the users, the node is not accessible to the viewer
I am using User Relationships.
I think ACL is the way to go, based on the recommendations of the node access handbook page and the inability of User Relationship's default node access module to operate with Views. However, I've thought of two potential structures for creating my content access lists.
- Make ACLs for every user representing the nodes shared with users of a given relationship. For example, the user areynolds would have an ACL containing all the nodes shared with friends, and the uids of all his friends
- Make ACLs for every relationship. If areynolds has a friend bobthebuilder, they have an ACL containing all the nodes they choose to share with one another.
Option (2) seems more flexible, but many more ACLs would be created. Should I be concerned about performance implications? I'm concerned in general that I'm misusing ACL and that I should just create a virgin node access module or attempt refactoring the User Relationship Node Access module to be Views compatible.
Comments
Comment #1
salvis#1 makes sense, because its easy to tell whether any given node is accessible to the current user.
#2 would probably not work well, because you'd need to enumerate the relationships of the current user, thus having an extra join.
As you found, you'd get lots of acl_ids, with only one uid per acl_id. That doesn't scale well.
You can roll your own, of course, but you'd probably end up reimplementing #1.
Comment #3
areynolds CreditAttribution: areynolds commentedProject specs and priorities changed (hence the delay), but thanks for the feedback! I'll post again if I choose to go this route for permissions.