Taxonomy access policy for terms with depth only works when parent terms are included

Hi nilubol, thanks for reaching out!

Are you using this access rule for the Taxonomy term access policy? "Current user: Has reference to this taxonomy term (with depth)" that should allow you to restrict taxonomy terms in entity reference fields by hierarchy. Note that you'll need to use the autocomplete widget. It won't work with the select list field widget.

Users who are assigned to the children terms and not the parent terms are not able to access the children terms on the taxonomy overview page

Can you provide some more details about this use case? Do you want users to be able to see all Taxonomy terms while only granting them the permission to edit the child terms they are assigned to?

nilubol, was the access rule: "Current user: Has reference to this taxonomy term (with depth)" able to resolve your issue? Were you running into any other issues?

Thanks for the quick reply! I am using that access rule and it works, but I didn't realize that we had to use the autocomplete widget to be able to access those terms. I was primarily testing with the checkboxes/radio field widget. Makes sense now.

Our use case would be for a university structure that has departments and sub-departments. We have users who will be managing taxonomy at the sub-department level but not necessarily at the department level, so with this workflow they wouldn't be able to manage terms if they can't access the parent. I think that might be a fairly common use case and not a huge deal if parent terms are shown, but with a 403 or something on edit (which is what happens currently).

I would also expect that most users who are managing taxonomy with hierarchy are using the checkboxes/radios or other field widget. Can we support either a flattened structure or showing disabled parent terms with these widgets? If not, the next action here might be to update the documentation to make it clear that using terms with depth is only supported by the select widget.

Thanks again for a great module with great documentation!

Our use case would be for a university structure that has departments and sub-departments. We have users who will be managing taxonomy at the sub-department level but not necessarily at the department level, so with this workflow they wouldn't be able to manage terms if they can't access the parent. I think that might be a fairly common use case and not a huge deal if parent terms are shown, but with a 403 or something on edit (which is what happens currently).

This sounds like a good use case to perhaps introduce a new "use" operation. This operation would only be for entity reference fields, restricting what can be selected in those fields. The "view" operation meanwhile would allow your term managers to see the parent terms while still being unable to edit or assign it themselves. This could also be used for nodes or media. For example, you could see Images from another department but you wouldn't be able to use it yourself in your content.

I would also expect that most users who are managing taxonomy with hierarchy are using the checkboxes/radios or other field widget. Can we support either a flattened structure or showing disabled parent terms with these widgets? If not, the next action here might be to update the documentation to make it clear that using terms with depth is only supported by the autocomplete widget.

I would probably need to create a new field widget to achieve this. I've been avoiding creating custom field widgets up to this point because I don't want to make Access Policy too opinionated. (Though I would consider it if there is enough demand). In the meantime, if I introduced a new "use" operation do you think you'd have enough to be able to write your own field widget?

That could work but out of curiosity – how would a "use" operation differ from an "edit" operation?

If I don't apply the access policy to queries, then the taxonomy overview page does allow users to see all terms while only being able to manage terms that they are assigned to. The tradeoff is that since this also applies to entity reference fields, there isn't any such distinction at this level and I can assign any term regardless (which is a valid use case for many). I guess that could be addressed by our own field widget.

So I have three potential solutions:

• Custom field widget to address the above limitations
• Or split query settings to manage taxonomy overview page and entity reference fields separately
• Or continue down the path of creating a new "use" operation

Curious to hear your thoughts!

@nilubol

I spent some more time investigating approaches for this, and in most cases there were trade-offs that weren't ideal.

• Splitting query settings for each access policy - I gave this a try and was able to get something working without too much refactoring. However the experience wasn't ideal because now you only had policies that applied to entity reference fields where it might also need to apply to views in other contexts.
• Using the "use" operation - This is similar to splitting query settings, the difference being it varies per user. For example, some users will have entity reference fields restricted while others won't. This is probably the most useful use case but unfortunately I ran into a snag with Drupal core. It really expects you to be using the "view" operation in entity reference fields. Because of that I was getting all sorts of validation errors. Take a look at ValidReferenceConstraintValidator::142

This brings me to one more option, one that is starting to grow on me.

Provide two query options.

• Automatic - This applies to all queries automatically, it's the most aggressive yet the easiest to setup (the current approach)
• Manual - All views, entity reference fields, and queries need to have access_policy query alter manually applied to them.

Manual essentially means no queries will be restricted by default.

• You'll need to add a new "Access" filter to each view that you want to be constrained by access policy.
• For entity reference fields, you'll need to select an "Access controlled" option from the Reference method setting of each entity reference field.
• For all other queries, you can write some code to add a new access_policy tag to each query to tell it to allow access policy to alter that query.

By doing it this way you'll have much more fine-grained control of which queries are controlled by access policy. It'll also help with performance.

@partdigital I really like that solution. Let me know if you need me to help with testing or anything else!

I've opened a discussion thread around groups, I've received a few related requests so I thought it might be useful to consolidate ideas into something cohesive.

https://www.drupal.org/project/access_policy/issues/3419012 🌱 Discussion: Access policy group enhancements Active