Problem/Motivation
This is part of the #2028027: [META] Missing access control for base fields meta issue. Please read the meta issue for the reasoning.
This issue is for implementing default access for all base fields of a taxonomy term. We need to go through them and look for existing access restrictions and make sure they are covered as part of the default Access of their field's item classes.
Example: We've got a permission for editing user names, that needs to be covered.
What to do: For each field that has a default access being not TRUE, we
- have to add a custom FieldItem class extending the field type's one
- implement defaultAccess() for it
- write a unit test case to prove it works as it should
Proposed resolution
Taxonomy terms have no field level access logic other than the changed field, which is not editable by users.
We already added entity type specific logic for the changed field to nodes and comments and have test coverage there. This logic applies to all entity types. instead of duplicating that and the test logic, we move the access checks to the changed field type so that it automatically applies to all entity types.
We IMHO do not need additional test coverage for taxonomy terms then, because we already verify that they are using a changed field and have that logic there covered by nodes and comments.
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#5 | changed-default-access-2099259-5-interdiff.txt | 710 bytes | Berdir |
#5 | changed-default-access-2099259-5.patch | 2.68 KB | Berdir |
#3 | changed-default-access-2099259-1.patch | 2.7 KB | Berdir |
Comments
Comment #1
smiletrl CreditAttribution: smiletrl commentedMaybe commit this issue #2015687: Convert field type to FieldType plugin for taxonomy module firstly?
Comment #2
xjmComment #3
BerdirI think the only relevant field here is changed, which I've now implemented by default. We could consider to rely on the read only flag here in an even more generic way? but that might not work as expected?
Comment #5
BerdirUps.
Comment #6
BerdirComment #7
fagoIt seems reasonable to deny edit access to read-only fields, as validating that those are not changed. Opened #2350429: Clarify the meaning of read-only fields and properties for discussing that. Solving it, would solve this issue as well though - thus I'm not sure it makes sense to do this as an intermediate step then?
Comment #8
BerdirIt would, but I'm not sure how fast we can do that. And solving this issue would allow us to close two criticals. This and the meta issue.
Comment #9
dawehnerThere was one issue from tstoeckler that $entity->changed() cannot be set from migrate (afaik this did not went it yet). It is a bit odd to check for edit, given that there might be way more possible operations which also change the entity somehow?
Comment #10
Berdir@dawehner: Code always has the option to ignore access rules. It is an opt-in check that is used for things like widgets/formatters, rest, rules UI, .. all of those should never be able to edit/change the changed date.
Comment #12
dawehnerI think this code is fine, but here is a small question on top.
Is there a reason why you don't have a NotEditableFieldItemList, can we set a dedicated list class per base field definition?
this is on a user level ... so yeah we can still the API evel.
Comment #13
alexpottThe issue summary and the patch don't seem to match.
Comment #14
BerdirUpdated the issue summary.
It's just missing the proposed solution/explanation of what the patch does IMHO.
Comment #15
alexpottThis issue addresses a critical bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 6ee87bc and pushed to 8.0.x. Thanks!