Taxonomy vocabulary data not available as views fields

One major difference between Drupal 7 and 8 here is that vocabularies are no longer stored in the database.
Given that vocabulary / node types ... etc. all don't have labels. Theoretically though you could write a generic bundle field handler, which can fetch the label, as needed.

I try to take a step on this one.

Let's try this out

After adding the patch in #7, I was able to add a field for the vocabulary name in a view based on the table "taxonomy_term_field_data." However, the description appears as "Filter the results of 'Taxonomy: Term' to a particular vocabulary." which is incorrect. Also, the "category" might be more appropriately be "Taxonomy Vocabulary" rather than "Taxonomy Term."

Oh that patch is interesting. I mean the patch solves some of the problems, other fields obviously would not be supported, but its certainly an improvement.

However, the description appears as "Filter the results of 'Taxonomy: Term' to a particular vocabulary." which is incorrect.

Do you mind explaining why this would be wrong? This is kinda what I think this particular filter would exactly do.

Also, the "category" might be more appropriately be "Taxonomy Vocabulary" rather than "Taxonomy Term."

Not sure about that to be honest. This kinda still is about the taxonomy term and having a category for just one field is kinda horrible.

It seems to be a problem with default permission checks. The entity reference formatter is called and requires a permission handler for vocabularies.

New patch with a vocabulary access control handler to grant view permissions for vocabularies on 'access content'.

Corrected patch format and added a test case patch.

+ * Contains \Drupal\node\VocabularyAccessControlHandler.
...
+ * Defines the access control handler for the node type entity type.

Hehe :-), should be taxonomy and vocabulary, respectively.

Fixed the copy & paste fragment. (Fix and test case included)

Added use statement in test case.

Yay, thanks a lot! :-)

Bot can set this back to needs work, if it wants otherwise, this is good to go.

@dawehner
I admit that I am wading into something that I am mostly unfamiliar with but my comments were based on the the following screen shots from Views 3 in Drupal 7..

The description for the added field here differs from the description when the field is added as a filter.

It appears to me that the patch only addresses making the vocabulary name available in the "fields" section as it is already available in the "filters" section.

Additionally, while I agree that having a different category for one field is weird, I wasn't sure if there were plans to add the additional vocabulary properties that are available "out-of-the-box" in Views 3 for D7 in what I believe to be the same scenario. If that were the case, I would think that a separate category would be appropriate.

Of course, the new way that vocabularies are being dealt with in Drupal 8 may just mean that I'm confused... And if I am, no worries. I'll try not to clog up this queue with my misunderstanding. :)

The patch as it is looks totally alright for me.

Related issue with patch for contextual filters: #2048733: Taxonomy vocabulary contextual filters are missing.

Re @stBorchert #22: I wasn't aware of the other issue. I spoke to @Daniel_Rempe in person about this and he will post an updated patch which just "enables" the field, not the contextual filter or the sort. That means we should open another issue about the sort (including test coverage). Marking "needs work" until such an updated patch is posted.

Changed the field description to 'The vocabulary name' and removed the parts concerning sorts and filters.

Thanks, let's get it in!

Committed/pushed to 8.1.x, thanks!

I didn't commit this to 8.0.x because it has the string addition etc.

+++ b/core/modules/taxonomy/src/TermViewsData.php
@@ -71,7 +71,7 @@ public function getViewsData() {
+    $data['taxonomy_term_field_data']['vid']['field']['help'] = t('The vocabulary name.');

Let's remove this string and fix the bug in 8.0.x.

This need rolling back:

+++ b/core/modules/taxonomy/src/Entity/Vocabulary.php
@@ -20,6 +20,7 @@
+ *     "access" = "Drupal\taxonomy\VocabularyAccessControlHandler",

This isn't enough since the default permission is 'view content'. So going to roll back.

I got a merge conflict with git revert, so here's a rollback patch. Bumping to critical so it doesn't get forgotten.

Can't reproduce the 8.1.x fail and 8.2.x passes. So back to CNR and sent for another retest.

Figured out why so many re-tests failed. If an issue is at 8.0.x, then you move it to 8.1.x when submitting a patch, retest tests against 8.0.x

Since I only did a re-roll because git revert didn't work, and all tests green now, moving to RTBC.

Committed the revert a2d1d2e and pushed to 8.1.x and 8.2.x. Thanks!

Could someone elaborate on the rollback? I'm afraid I don't really understand what #30 is trying to say.

/**
 * Defines the access control handler for the taxonomy vocabulary entity type.
 *
 * @see \Drupal\taxonomy\Entity\Vocabulary
 */
class VocabularyAccessControlHandler extends EntityAccessControlHandler {

  /**
   * {@inheritdoc}
   */
  protected function checkAccess(EntityInterface $entity, $operation, AccountInterface $account) {
    switch ($operation) {
      case 'view':
        return AccessResult::allowedIfHasPermission($account, 'access content');
        break;

      default:
        return parent::checkAccess($entity, $operation, $account);
        break;
    }
  }

}

This meant that anonymous users could view admin/structure/taxonomy/$vocabulary since that relies only on the view permission.

Ahh OK, thanks. I understand. That's certainly not ideal.

Fixing metadata since this is an 8.3.x issue at this point.

I think the issue is that the vocabulary overview page (route entity.taxonomy_vocabulary.overview_form) is not really an overview page but a page where you can rearrange the terms in a vocabulary. If we change the _entity_access permission to update instead of view, that should solve anonymous access to that page. Also fixed a copy/paste leftover in the test.

Not quite sure yet about the change, but we definitely need test coverage for the access check of that page then.

Actually, #2599128: Allow user with edit terms permission to access vocabulary overview does basically that and implements the view operation. I think we should wait on that issue and extend the test coverage there a bit more on anonymous access, get that in and then this will be fine as it was before (after merging the access control handler, that is)

#1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission) now solves the overview problem, so once that is in, this issue can focus on the vocabulary name problem. #2808217: To be able to view Vocabulary config entities via REST, one should not have to grant the 'administer taxonomy' permission is also a related issue which wants to do basically the same.

A possible fix for this would also be to use the new view label operation, which is now respected by the entity label formatter thanks to #2692091: Use the new 'view label' entity access check in the entity reference label formatter.

Reroll was needed and serious refactoring after all the other issues have landed (so no interdiff). Also converted the test to a kernel test.

Thanks for the patch in #60, worked like a charm for my needs. +1 for RTBC.

The patch works for me. By adding a relationship for the taxonomy term, it becomes possible to add the vocabulary as a field.

Removed the deprecated call

Removig the deprecated call is reasonable. Setting back to RTBC.

Committed 4dc2f4a and pushed to 8.6.x. Thanks!

I have two questions:

1. We are updating views data here which is cached so why don't we have an update hook to clear the cache?
2. It is a bug so why are we not backporting it to 8.5?

We do need an update hook see views_update_8004, views_update_8005 and views_update_8100

Here you go

To be honest, I don't really understand the policy to do this, as afaik the recommendation is that you should always clear caches when updating. Then again, drush updb is "intelligent" enough to not clear caches if there are no updates.

But it is consistent with what we did elsewhere AFAIK.

@hctom I wonder who worte that change record 🤔. HOOK_update_N and HOOK_post_update_NAME both are called update hooks and yes, I have implememted HOOK_post_update_NAME in the patch :). Please have a look at the patch once again.

Committed 679fe1f and pushed to 8.6.x. Thanks!

As per https://www.drupal.org/core/backport-policy, @catch can you please state your reason to not backport this to 8.5.x? I don't think this is disruptive at all.