Vocabulary name not shown in View for Anonymous Users

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 🤞

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, with any question, by able to view the names of the vocabs that are used to categorise that content. Seem like a Page 1 thing 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...

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

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 #41, 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!

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