Problem/Motivation
In Drupal 7, fields were shared across all entity types (eg, field_foo
could be attached to a node, and to a user). Thus, this module by only storing the field name was in keeping with how core operated with regards to fields.
Now however, in Drupal 8, fields are stored per entity type, so the way this module is working means if field_foo
has field permissions for nodes, and then another field of the same name is added to the user entity, permissions are inherited from the node, and cannot be changed for the user (furthermore, changing the permissions on the user field actually changes them for the node too).
Proposed resolution
Store the entity machine name as part of the permission's machine name.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#10 | 2825905-10.patch | 14.26 KB | jhedstrom |
Comments
Comment #2
dmsmidtThis is indeed problematic.
I notice that if you have a certain field with instances on multiple bundles the settings are also shared.
So if we make these settings a per instance setting, both problems would be solved.
Comment #3
jhedstromI think this needs some re-consideration. Given that the current behavior is exactly how Drupal 7 worked (per-storage, not per-instance), this is potentially even a feature request.
If we were to change this to per-instance settings, for a single field, say used on 5 bundles, this change would suddenly result in 25 individual permissions, which makes management 5 times as much work as it is now (and 5 times as error prone in making a mistake in permissions). Multiply this for a site with 50 or 100 fields...
This might need to be targeted for a 2.x version of the module...
Comment #4
jhedstromI split the per-bundle bit off into a new feature request: #2881776: Implement field permissions per-bundle (field instance).
Comment #5
jhedstromHere's a really rough start.
Comment #6
jhedstromComment #8
jhedstromThis fixes some of the failures.
Comment #10
jhedstromThis fixes the tests.
We'll still need an upgrade path here (with tests I think).
Comment #11
dmsmidtThanks for working on this, I have a bunch of other issues to review and work on, but I hope I can check it later.
Comment #12
sgurlt CreditAttribution: sgurlt commentedLooks pretty good for now, we are using this in our current development project.
Thanks for the work !
Edit: Just ran into a bug.
I have two paragraph types that share a field. One field is restricted by permissions to be used, but just for one of the paragraphs. But it seems like the permissions are effecting both paragraphs types.
Comment #13
pifagorComment #14
achton@pifagor Did you see the bug report from @sgurit? I don't think we can RTBC this without adressing that report.
Comment #15
pifagorHello @achton. Yes, of course, you are right. I just did not come across this error.
Comment #16
littletiger CreditAttribution: littletiger commentedhi all, what's the current status on this? Need help testing and reviewing or is it waiting for another bug?
There's one mentioned but not linked
Comment #17
cslevy CreditAttribution: cslevy commentedHi,
Also some update script should be provided for the existing permissions. I applied the patch, and broke the permissions on all fields.
Comment #18
geek-merlinReading the patch in #2881776: Implement field permissions per-bundle (field instance), this seems to be included there. Postponing on that.
Comment #19
berenddeboer CreditAttribution: berenddeboer at Xplain Hosting commentedBig surprise to find this. At minimum a warning should be displayed, until this can be fixed. Else you change one field, and everywhere else you break things.
Comment #20
osopolarI also was very surprised to run into this issue. It's a very unexpected behavior. The field settings say (in tiny letter):
EDIT:
Anyway, the patch from #2881776: Implement field permissions per-bundle (field instance) fixes the issue for me.