Vocabulary name not shown in View for Anonymous Users

I sounds like Views is respecting Taxonomy vocabulary access checks, so this sounds like a lack of granularity in Taxonomy permissions is the underlying issue here (which we can't fix in Views). But didn't dig into this, so there might be a different reason this is hidden (but the toggling of the permission does point strongly to this being the issue).

I think this is quite a serious and overllooked issue.

Firstly, surely many sites would like to be able to present a 'catalogue' made up of terms from several vocabularies and then be able to use views to present all such terms in nice neat groups.

Secondly, if the anonymous user can view terms (which they can out of the box) then why on earth not allow them to also see the vocabulary name.

As wsantell righty says, "applying the "Access the taxonomy vocabulary overview page" permission for Anonymous users" workaround is a bad idea because that enables anonymous users to reorganise your terms!

Can anyone offer ideas here?

Thank you

I'm sailing on the same boat here!!

As I pointed out in #2 this seems like a problem in taxonomy, so moving it to that queue for now. If it turns out to be something specific to Views we can always move it back.

Not sure this can be classified as major, but since there is no workaround, I'll leave it there for now.

Same issue here.

Using this module: https://www.drupal.org/project/taxonomy_access_fix and update permissions of terms can fix this

@sjnsmnkl Can you elaborate how taxonomy_access_fix helps with this issue? I installed 3.x-dev and don't find a "View vocabulary X name permission", also enabling "View terms in X" does not make me show the vocabulary name for anonymous users.

It seems that you mentioned a hack, that does not work anymore in 3.x-dev: #3161541-2: Add permissions to view vocabulary names

@anruether Install the module and go to /admin/people/permissions, search for "Taxonomy Access Fix", and check boxes for "View terms in XXX", which can fix this. My version is 8.x-2.8 tho

How about this patch ?

I can confirm the patch in #12 works. It's a pretty straightforward approach, in my mind. It definitely needs test coverage though.

Patch given in #12 works for me. Adds the missing permissions. Thanks Greg__.

Here's a test-only fail patch to expose the bug. I'm trying to just run the new test to save time and money. Let's see if I'm doing it right.

I wrote the test as if 'access content' should be enough of a permission to see a vocab name. This is consistent with (node) Content Types. So I personally don't think we should add a new permission.

Great! Only the updated test ran and it failed as expected for a user with `access content` permissions. Here's a fix that relies on `access content` instead of adding new permissions to view vocabs. This is consistent with how Content Types work.

Note that the interdiff is mostly related to now letting all tests run.

There has already been considerable discussion about how to handle the permissions for something like this as part of #2808217: To be able to view Vocabulary config entities via REST, one should not have to grant the 'administer taxonomy' permission. It's a long thread and I haven't quite figured out why they didn't use access content to solve that problem.

The approach there was to rely on the then-new access taxonomy overview permission.

I think people on the issue here seem to agree that it's pretty weird to give anonymous users that permission.

Just like in #12 this broke a bunch of tests related to REST and HAL. I'm not interested in fixing those until there's some agreement on what permission to rely on. Setting back to NR to get some eyes on this.

It seems that they resolved the point in the issue you linked in #18. https://www.drupal.org/project/drupal/issues/2808217

As with #18 and others, seems like giving access to taxonomy overview for this purpose makes absolutely no sense to me. The anonymous user can then go to admin/structure/taxonomy and reorder the vocabulary weights?! How is that sensible? I get that REST access needed to be accommodated but giving this permission to anonymous was not a good solution imho.

Using "access content" makes perfect sense to me as all that needs to be accomplished is access to the name of the vocabulary and this should be something publicly accessible for any and all users who can access content. I can't think of a use case where the name of the vocabulary would be something that should be excluded from access for users who can access the content as a whole...

Even though it isn't passing tests, applies cleanly to 9.3.6 and works as expected. Thanks!

#17 worked for me, I'm using it to render the Vocabulary in search results (as a label atop the taxonomy term name). The Vocabulary name was not showing up for anonymous users, but now it is. There are no errors in the logs either.

Oooo I just ran into this problem, thrilled to see there's a patch.

Anyone have an inclination about support (or lack thereof) for the concept from core maintainers?

Patch works for me on 9.3.x, and applies cleanly + functions properly on 9.5.x.

Changing status to "needs review", and adding "needs subsystem maintainer review" tag, may @ someone on Slack later -- also will try rerunning tests!

I was unsure whether 'access content' is the right one but it certainly looks like it: TermAccessControlHandler also uses that one for view.

Surprised to see this on NodeTypeAccessControlHandler as well.

IMHO it should be limited to the view label access operation for both, not everything should IMHO be publicly exposed.

Taggin for Bug Smash

Thank you to @Berdir for the guidance on Slack #contribute!

- Tests are queued to run against 9.5.x.
- But, leaving "Needs work" status, because the tests need to be updated to reflect the permission change.

Rerolling #17 for 10.1.x.

FWIW, the patch in #34 does apply fine to 10.1!

I attempted to adjust the tests so it runs against 10.1.x, too; I hope I did it right, if not, ...oops and I hope it doesn't cause a hassle, I gave it a shot 🤞

EDIT: Mmmm now I can't seem to "retest" against 11.x... I'll give it another try after the 10.1.x tests are done.
EDIT 2: Not important, but I swear I didn't notice til right now that I had an earlier comment (#31) with questions/wonderings about running tests against different branches 😆 the circle of life........

Updated the expected permissions in the test failing in #34. I'll leave it to someone else to review whether that change should be made or not.

One more test base class.

Interdiff for #37.

Reviewing this part of the needs review queue. And the issue summary seemed incomplete. Got it started if relevant sections to this issue could be filled in please.

I am really struggling to understand quite why this is still a thing.

I first discovered this on my sites about 4 years ago and I have looked back today to find that I did indeed contribute here.

Right now, my non-admin users (e.g. Anonymous and Authenticated) still cannot view Vocabulary names and it's madness!

I wholeheartedly agree that if they can View published content then they really ought, without any question, by able to view the names of the vocabs that are used to categorise that content.
Seems like a Page 1 expectation to me or have I really missed something here?

The only way for me to enable my users to see vocabulary names is by giving them Administer vocabularies and terms permission and I sure as hell am not going to do that.

Adding in the Taxonomy Access Fix module and ticking every occurrence of...

TAXONOMY VOCABULARY NAME: View vocabulary name
Has no effect at all, none of my users cannot view the NAME of any vocabulary.

Even with...
View any vocabulary name TICKED for both Anonymous and Authenticated they still cannot view any vocabulary names.

I have tried the patch in #37 (3114365-37.patch) and ticked off...

'Access the taxonomy vocabulary overview page
Get an overview of all taxonomy vocabularies.'

for both Anonymous and Authenticated roles, cleared all caches but they still cannot see the vocabulary names.

Possible workaround for some

By completely rebuilding some of my Content views and Search API Index views where I expose vocabulary names as fields, I was eventually able to get my user the what I wanted, i.e. a simple page of Term sorted alphabetically and grouped under Vocabulary name but one shouldn't need an MSc in Drupal site building to get such a simple thing done ;-)

After all the various threads here are at a point where we can just go with 'View Published content' or or we must, simply 'View Taxonomy vocabulary names'.?

Hi @SirClickalot! Per the comment in #40, this issue is in need of an issue summary update. I'd agree with that assessment given that the proposed resolution is stated as TBD. This issue won't likely get over the finish line until someone tidies up the summary, which will allow core committers to easily assess the fix after this gets to RTBC.

Based on @Berdir's feedback in #29,
I've added a PR that adds permissions for `view label` operation.

I think we need some inputs from sub system maintainer about which is the correct approach.
I feel that `view label` access is more safe and restricted.

Updated the issue summary and mentioned that we need consensus about the solution.
Hiding other patches since #37 seems another valid implementation and passing test cases as well.

Thanks everyone for your thoughtful comments and work on this issue! It's good to see all the different comments showing that this definitely needs a fix.

I agree with @larowlan that this should actually have its own permission. "Access content" is almost as overmuch in its way as "administer taxonomy terms". A dedicated permission would improve the functionality and also be a sort of security hardening. :D

NW to implement that. Thanks!

Tests are green, back to needs review

Hiding patches

Left a comment on the MR, I think we can simplify this to a single permission

Fixed the feedback.

Very close, couple of minor things

Fixed the PR feedback.

Appears feedback from @larowlan has been addressed

Cleaned up the issue summary some to include the new proposed solution.

Also drafted a simple change record https://www.drupal.org/node/3436818 to announce the new permission.

Assigning issue credit.

I do wonder if a new permission is the best thing here. But going with the decision by @xjm and @larowlan. I also wonder how you are going to find this permission if you are trying to fix this problem.

Committed and pushed 8d5b54efa8 to 11.x and 495174e527 to 10.3.x. Thanks!