Apologies if this has been raised before (searched and couldn't find a mention). This also applies to Node Access User Reference as well (but d.o. has no way of attaching one issue to multiple projects).

I'm in two minds about this. Take for example the classic organic-groups-y case; user reference field in a 'group' node gives group members view/update access to that node, node references in other content types indicate that a node "belongs" to that group and therefore users in that group have access to that node that others don't. It's easy to imagine a situation where for one content type a group member (i.e. anybody with update access on the group node) should have view and update access to a node belonging to that group, and that in another content type they should only have view access. Both of the following arguments seem reasonable:

  • In both cases, the relationship between the node and the referenced node is the same, it's just that we want different permissions granted in different contexts, therefore access control should be per-bundle.
  • The access control settings on a node reference field is a part of the definition of what that relationship between the nodes means, therefore for different sets of permissions you should use different fields.

I don't have any compelling ivory-tower arguments for what's Right, but I must say that for my current purposes, per-bundle settings would be more convenient. I'd be interested to hear what other people, particularly the maintainers, think.

Comments

danielb’s picture

Not sure what you're on about, the settings are not global.

danielb’s picture

Are you saying this because the settings form for this module appears in the wrong place? :P

Matthew Davidson’s picture

Yep. ☺

danielb’s picture

Status: Active » Fixed

I've moved the settings up to the other fieldset in nodeaccess_nodereference 7.x-1.x and nodeaccess_userreference 7.x-3.x

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.