I discussed this a little during a core conversation in London, and it's critical to this concept.

Do we handle access rules per entity or per entity revision. Node access currently does it by entity, which is easier to manage (and easier in the UI). But a more robust system might want to store access rules for every entity revision.

I'm torn on this issue, but it's a foundational piece of the architecture that has to be decided.

Comments

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

We probably have to go with a revision-capable-but-optional entity access API. You can restrict by revision IDs but by default the access is global across all revisions of an entity.

dawehner’s picture

dawehner
Primary language German
commented

Couldn't the module actually implementing the entity access hooks takes care of the revisions by good chosen realms/gids?

BenK’s picture

BenK commented

Subscribing

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

@dereine

Maybe, but in core you are forced to make that decision, since {node_access} stores nid and not vid. For a real-world example of the problem, consider Taxonomy Access Control now that terms are revisioned. Revision one might be assigned to "foo" and revision two (the live revision) published to "bar". Which rule applies to editing the "foo" revision?

There are pretty serious workflow and UX concerns when dealing with revision-based access controls, because different users will have access to different versions of the entity.

My thought here is that we should store access grants by version (vid) instead of entity_id, which opens the potential for a version-specific access rule (which most modules might ignore).

I see this as part of Crell's "one is a special case of many" argument. Since entities support revisions as a core function, we should architect access rules from that same point.

I say that even though I think it makes things much harder.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

And storing a different realm for each revision is a non-starter.

xjm’s picture

xjm
she/her
Primary language English
commented

Tracking.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Note that Dave Reid released the Field Property module to help with this very issue.

http://drupal.org/project/field_property

joevansteen’s picture

joevansteen commented

I'm a newbie here, but I've been searching through access control stuff for a while now as I try to build my site. I was attracted here because I'm looking for something that goes beyond node access and gives me entity access control along the lines of the node access schemes. Entity access (based on the naming) seems to be what I want.

While I understand that there is a technical issue relative to nid and vid I don't understand the practical use-case associated with the discussion that seems to continue to look for the ability to implement a revision level access management policy.

I think there is a difference that needs to be taken into account in terms of fields and properties of entities. Some are the properties of the entity in terms of the role it plays in the real world (business data). Others are properties that have to do with the management of that information (meta-data). Subtle, but real distinctions. Access realms, to me, are a form of meta-data that happens to be housed (in the case of Drupal) on the same record as the business data. Revision history is primarily useful related to the business data. It is useful to see, but not necessarily to operate on, in the case of meta-data.

If the access management domain realm for an entity has moved from domain realm 'foo' to domain realm 'bar' why wouldn't, in any real world scenario, the history (the prior revisions) of the entity be accessible to the new domain realm 'bar?' If the history doesn't move, maybe the entity wasn't really transferred; the old entity was removed and a new entity with a new history was created. Or, maybe the history is 'truncated.' But, in either event, the identity of the entity was transferred to the entity that now resides in the 'bar' domain realm.

- What utility is provided by giving access (even view access) to members of the 'foo' domain realm? Can a member of 'foo' use an old version of the entity to create a new version and move domain realm control of a new 'current' state back to the 'foo' domain realm? If they can, how did they get to a position to be able to do this? If they can't, what is the point of having 'access?'

- A related but more complicated proposition: Should members of 'bar' be restricted from being able to revert the business content of the entity to a prior state that existed when the entity was in the 'foo' domain realm? If so, what happens to the access management domain realm when that move is taken? Does the domain realm control revert to 'foo' also? How can 'bar' revert the business content but not the access domain realm?

Essentially Dave Reid's Field Property module partially addresses the second problem, but in the process it also destroys the access domain realm history. It would be nice if all the history could be retained but the access domain realm 'fix-up' only applied when needed on the newest version. In essence, it would be nice if Dave's module were an intelligent part of an access domain realm management sub-system that gave full historical domain access permissions based on the current access domain realm statements specification of the current revision.

Just an opinion, as far as I've been able to think some of this through.

I apologize if I'm not understanding or taking into account some aspects of Drupal operations which I'm not yet familiar with. As I stated above, I'm just getting into this system, and I've got a lot of into yet to go. ;-)

Edit: Text has been edited to replace 'domain' with 'realm' as per my understanding of the technical vocabulary used in this material. My original use of the word 'domain' was meant to imply a 'business domain' that was the ownership or control space over the node content. For example, a 'section' of a newspaper or a business department (e.g., engineering vs sales or accounting). My impression from the follow-on comments and other online docs is that 'realm' is the more appropriate term.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I think that's a pretty clear statement -- but the use of "domain" instead of "realm" above can cause confusion, since "Domain Access" is one of the access control modules.

In my estimation, I think the real case is that if one transfers access ownership from foo to bar, that access extends to the entire history of the data because, in a very practical sense, to not do so is both incredibly difficult to support in code and even more difficult to explain to the end user through the user interface.

The trap that we are currently in is that Drupal 7 introduces field-level data storage that is automatically revisionable for some data points (notably taxonomy terms) that are frequently leveraged as access control realms. And if you look at how node access is currently implemented, per-revision access controls simply are not supported.

To that end, we need to make a deliberate, thoughtful and final decision about how to manage access control records.

The last case you mention is, I believe, what field storage gives us now, without Field Property module, in that the most current revision controls the access logic. The problem that I have with that is that you can have an unpublished revision that changes the access state of the content but gives the previous editors no indication of why it has been removed from their access realm.

So I think we ought to drill into your comments some more and try to list some expected behaviors in a concise, logical manner.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

the first feeling about revision access control is "what, i can accass one revision but not another?"

but on second thought, think of "sighted revisions" like wikipedia.

let's wonder if we for all time want the last revision be the "official"?

and let's imagine git-like revision branching - anne edits, bob edits, both create a new revision, which then might be merged.

maybe some more insight in revision use cases and workflows gives a clearer understanding of revision access.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Git-like revision branching, while awesome, is probably an absolute code nightmare to support. Can you imaging trying to merge field revisions?

dawehner’s picture

dawehner
Primary language German
commented

Just to inform you, the current version doesn't have revision support, but it's planned to be added.

In general the current state is quite fine, at least it's working as expected, so a review for this module would be cool.