This is the minimal effort version of an entity access system. It is designed very very closely after the current node access system. I presume EFQ v2 gets committed first as it cleans up node_query_node_access_alter and adds significant capabilities to EFQ itself.
So, the node_access table migrates into a field handled by an entity_access module. It will a) alter EFQ v2 queries adding very similar conditions as to what node_access added before the EXISTS conversion b) will alter non-EFQ v2 SQL queries by doing the exact same subqueries as node_query_node_access_alter does right now just it will use a field_data_entity_access table instead of node_access.
Requires no Entity API change aside from adding back a query alter to EFQ v2 which is easy to do. A small change API change to the node grants hook to take an entity instead of a node.
Comments
Comment #1
agentrickard@chx and I discussed this in IRC as a path-forward to three goals:
1) Allowing
MongoDBall entities to use common access controls.2) Standardizing the EFQ API by removing the special case of access control in its own table.
3) Opening the door for pluggable access control storage and handling, because we can abstract this logic to a method.
Comment #2
agentrickardIn this model, entity_access will control the field storage and use the access API to ask other modules "What should I store for you", similar to how {node_access} works now.
Comment #3
chx CreditAttribution: chx commentedThere is more than just mongodb: if this is a field it just so happens it works for every entity type.
Comment #4
agentrickardAgreed. Editing original.
Comment #5
xjmUh.
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedI would go one step forward and kill b) completely. If it's not an EFQ, it doesn't have access control. Period.
Comment #7
bojanz CreditAttribution: bojanz commentedSo, this idea buys us simplicity, support for any entity type, language and revision support by default, which is great.
However, what happens when we add a "access per user" module, and the number of grants explodes?
We obviously don't want to load them all, together with an entity.
In fact, we might not want to load grants at all into the entity.
This field type would also have no widget and no formatter, which is also something that's a bit odd for a field.
Comment #8
xjmAs far as I can tell, the only reason to do this is to leverage the field system's storage and EFQ. Even having slept on it, I still can't make sense of a conceptual reason for node access to be a field. It should be determinable based on the values of fields.
I also can't see how this could possibly scale for what access control does in D7 and below. If we want to continue to support grant realms, this so-called "field" would explode. You'd have little mini tables sitting on every node.
Edit: Also, each value is not actually a single value, but a combination of a grant realm and three different grants for three different operations.
Comment #9
xjmSo we just discussed this a bit at BADCamp. Remaining questions:
hook_entity_acces_info()
? Do we then have to forcibly update all bundles to include this field and follow with theentity_access_rebuild()
batch operation to populate all those fields on all the existing entities?Comment #10
fagoWith #1696660: Add an entity access API for single entity access we'd have a start of entity access controllers, right now without any query-ing support. I could see us allowing them to take care of query access as well for pluggablity.
I'm not sure about basing entity-access about a field. More likely a field in the terms of the new entity field API, but not a configurable (field API) field - as we want the storage part and not the rest?
Then, while having the storage and querying support is great, but as #7 points out we don't want to load the grants upon entity-load, do we?
Comment #11
chx CreditAttribution: chx commentedOK, this is unsolvable. Let's move the node access code into a plugin without a change and that's it.
Comment #12
chx CreditAttribution: chx commentedNo need for a full blown plugin really.
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedAn alternative is to make node_access listing API into a module and then contrib modules can just depend on that.
Comment #14
chx CreditAttribution: chx commented#1921426: [Followup] Move node access storage to DIC