Access Permission for Relation Pages

Hrrm.. I had a feeling that we hadn't done permissions properly at all, but now I look, and most of it's there. I wonder if there is anything else we may be missing. We should be getting rid of the "access content" perm on line 142 as well, I think, and I think this will require changes to the relation_dropzone.test (although I haven't tried - see line 62)

Not sure if this is even really necessary - I think relations clearly are content, what else could they be classed as?

Issue #1: Are relations content or glue?

In one of my use cases, outlined in #1178734: Attaching fields to Relation types, relations will be the primary method of connecting, entering, querying, modifying, and deleting data, both for the relation entity itself, as well as the endpoints. My example does indeed have attached fields (qty and units for both subject and object), which gives the relation itself more weight from a content perspective. I will also be using fieldable taxonomy terms, which appear to use the entity/bundle/field triad in a similar way as use by relations. A vocabulary serves as a bundle onto which fields can be attached that are usable by any term in that vocabulary. The same goes for relation types in that the relation type is the bundle identifier.

Before attachable fields on any entity arrived on the scene, I could see how taxonomy terms and relations might seem more like content "glue" than content itself, but I think that may change as developers figure out how to leverage the Field and Entity APIs and move content once forced to fit inside nodes and custom tables toward fieldable entities.

In my use case, the relationship itself is of primary importance. If a user wants to create a relationship between one or more endpoints that do not yet exist, they could do so starting from a relation-based UI, even if it just provides a button or link to the content type form corresponding to the endpoint entity type, since the relation_type is aware of the endpoint entity types it supports. Obviously, a user can also enter entities in their native CRUD forms and then relate them at a later time. The current UI serves my current purposes of playing with sample data.

Issue #2: Relation Permissions

For my use case, I would like to have a set of unique permissions for each relation_type, given that the relation type's reason for being is highly correlated to specific job roles. Otherwise, I'll have to implement it in my application layer, which I'd like to avoid as long as existing APIs and UIs provide what I need.

Hrm if we compare to node.module, perhaps we should have per-relation_type permissions (edit any, delete any, edit own, delete own), but that seems to me to be extreme overkill, since sites are likely to have many more relation types than content types..

@dpi: agreed, in many use cases relations won't act as content separate from the nodes they relate, and I guess it possibly makes sense to be able to hide the relation/%rid page, but couldn't you just not link to it? I mean, is there a good reason to hide it all together?

@dpi: I want to make sure I understand what you're saying. Are you talking about clogging up the main permissions page? I don't know if it's changed with D7, but I recall that it was a ridiculously long list that made people cheer when it was sorted alphabetically so that the permissions of various modules would be located together. I'm at my day job, so I can't fire it up right now and see for myself. Is there an option on this page to group permissions by access type, role, or module (perhaps in horizontal tabs)? If there is no such option for organizing permissions, then your suggestion of locating these settings on the relation type page may be more appropriate.

Obviously, the ability to create, edit, or delete a relation_type is separate from the permissions to create or delete the individual relations themselves.

I am not convinced; however, that the number of relation types will exceed the number of content types. It will be highly application driven.

In our implementation, we would have a "user nutritional requirements" relation type that relates the user with "nutrient" content type. The relation has fields for minimum and maximum values of that nutrient. Node-like permissions seem very natural in this case.

I would love to see the view relation perm first outlined on this post be put into effect. I tried to do with rules, but it seems that the relation pages don't trigger rules events when viewed.

er... I thought I already marked this as fixed. I committed that patch weeks ago. See commit 5cb8f17