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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

smiletrl’s picture

xjm’s picture

Title: Implement default access for all taxonomy term fields » Missing default access for all taxonomy term fields
Category: Task » Bug report
Issue summary: View changes
Priority: Normal » Critical
Berdir’s picture

Status: Active » Needs review
FileSize
2.7 KB

I 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?

Status: Needs review » Needs work

The last submitted patch, 3: changed-default-access-2099259-1.patch, failed testing.

Berdir’s picture

Status: Needs work » Needs review
FileSize
2.68 KB
710 bytes

Ups.

Berdir’s picture

Component: entity system » taxonomy.module
fago’s picture

We could consider to rely on the read only flag here in an even more generic way?

It 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?

Berdir’s picture

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?

It 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.

dawehner’s picture

+++ b/core/lib/Drupal/Core/Field/ChangedFieldItemList.php
@@ -0,0 +1,25 @@
+/**
+ * @file
+ * Contains \Drupal\Core\Field\ChangedFieldItemList.
+ */
+
+namespace Drupal\Core\Field;
+
+use Drupal\Core\Access\AccessResult;
+use Drupal\Core\Session\AccountInterface;
+
+/**
+ * Defines a item list class for changed fields.
+ */
+class ChangedFieldItemList extends FieldItemList {
+
+  /**
+   * {@inheritdoc}
+   */
+  public function defaultAccess($operation = 'view', AccountInterface $account = NULL) {
+    // It is not possible to edit the changed field.
+    return AccessResult::allowedIf($operation !== 'edit');
+  }
+}

There 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?

Berdir’s picture

@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.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

I think this code is fine, but here is a small question on top.

  1. +++ b/core/lib/Drupal/Core/Field/ChangedFieldItemList.php
    @@ -0,0 +1,25 @@
    +class ChangedFieldItemList extends FieldItemList {
    

    Is there a reason why you don't have a NotEditableFieldItemList, can we set a dedicated list class per base field definition?

  2. +++ b/core/lib/Drupal/Core/Field/ChangedFieldItemList.php
    @@ -0,0 +1,25 @@
    +  public function defaultAccess($operation = 'view', AccountInterface $account = NULL) {
    +    // It is not possible to edit the changed field.
    +    return AccessResult::allowedIf($operation !== 'edit');
    

    this is on a user level ... so yeah we can still the API evel.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs issue summary update

The issue summary and the patch don't seem to match.

Berdir’s picture

Issue summary: View changes
Status: Needs work » Reviewed & tested by the community
Issue tags: -Needs issue summary update

Updated the issue summary.

It's just missing the proposed solution/explanation of what the patch does IMHO.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

This 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!

  • alexpott committed 6ee87bc on 8.0.x
    Issue #2099259 by Berdir: Missing default access for all taxonomy term...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.