Fixed: Insufficient access to Taxonomy Block on Dashboard

[stpaultim]

Description of the bug

With the addition of #382, we need to refine access to the "Taxonomy" block on the dashboard for roles to create or delete terms.

Currently, only those with permission to administer vocabularies or edit terms have access to this block, when this block is actually useful for anyone with permission to do anything with taxonomies. This was not the case prior to #382.

ALSO - user with "Administer Terms and Vocabularies" permission had a link to "configure" but it took them to the "list terms" page instead of the "configure" page.

Steps To Reproduce

To reproduce the behavior:

1. Login to a new site as site editor (with default permission "Tags: Create terms")
2. Visit the dashboard and see that the taxonomy block is not visible.
3. Add "Tags: Edit terms" permission and view dashboard again and you will see that the block is available.

Actual behavior

Even with edit and delete terms, these are the only options you get with the block.

Expected behavior

Since the only two links that are provided by this block directly are "List Terms" and "Add New Terms", this block is useful to editors with any taxonomy permission. The ability to see available taxonomies and list the terms is valuable.

@olafgrabienski and @herbdool

[stpaultim]

To test - create a TEST EDITOR account (Maybe use same password as admin). Give various taxonomy permissions to editor and see if the Dashboard block behaves as expected.

The following permissions should give access to the following on the dashboard

Administer vocabularies and terms

• Ability to access the Taxonomy block
• "List Terms" Link
• "Add New Term" Link
• "Configure" Link

Tags: Create terms

• Ability to access the Taxonomy block
• "List Terms" Link
• "Add New Term" Link

Tags: Edit terms

• Ability to access the Taxonomy block
• "List Terms" Link

Tags: Delete terms

• Ability to access the Taxonomy block
• "List Terms" Link

No Permissions

• NOT able to access the block at all

[stpaultim]

I've updated the code in the PR based on some feedback from @klonos, but it still works the same.

[klonos]

Since this relies on a set of changes that went in only in 1.x, I've set the milestone to 1.20.

[stpaultim]

@klonos - I've made requested changes to PR. Take a look again if you get the chance. Thanks.

[olafgrabienski]

I've tested the PR sandbox site and got results as expected - described in #5198 (comment). I've also created a new vocabulary and played around with different permission combinations. Everything worked as expected!

[klonos]

Sorry @stpaultim and @olafgrabienski there are a few issues with the approach in this PR, so I'm gonna move this back to "needs work". Too many things to list now, so I'll file an alternative PR shortly...

[stpaultim]

@klonos - I look forward to seeing your alternative. ;-)

[klonos]

OK, here's the PR: backdrop/backdrop#3737

• Before, we were blindly loading all vocabularies with taxonomy_get_vocabularies(), and then iterating through all of them, in order to determine if they are in the list of vocabularies that have been configured to be shown in the block settings. Now, we compile the list of vocabularies that the block has been configured to show, and we then use taxonomy_vocabulary_load_multiple() to load only those vocabularies.
• Before, we were checking access and creating the operations links for the block from scratch. Now, we reuse the _vocabulary_get_operations() helper function that was introduced in [D8][UX] Add Better Taxonomy permissions #382. Less code duplication + if we change anything re permissions/access in the future, those changes will be reflected in the operations links in the Dashboard block as well (so less likely to have the problem this issue was originally created for).
• Tiny fix: changed the links from '#type' => 'dropbutton' to '#type' => 'operations' instead.
• Instead of having custom logic add the There are no vocabularies to display. message, we now use the '#empty' variable that is passed to theme_table().
• Tiny improvement: moved the $header array after the if ($no_access) { return array(); }, so that that bit of code is not executed if we bail earlier.

[jenlampton]

I gave the PR test, and it works great!

Here's the dashboard from the editor's perspective:

And here's the dashboard from the admins perspective:

And when I added a new vocab with more limited permissions for editor, that vocab appears on the dashboard with a more limited set of operations 🎊

[stpaultim]

there are a few issues with the approach in this PR, so I'm gonna move this back to "needs work". Too many things to list now, so I'll file an alternative PR shortly

@klonos - Looks like there were issues with the code before the PR. ;-) Thanks for stepping in and cleaning this one up.

[klonos]

Yes @stpaultim, preexisting issues + we have not thought of the taxonomy Dashboard block when implementing #382 ...the main thing was (re)using _vocabulary_get_operations() for the operations links, but you know me ...if I start afixin' things, I gots to fix 'em all 😅

[stpaultim]

I closed my PR in favor of the one by @klonos and reviewed by @jenlampton.

[klonos]

Rebased after the recent core commits that fix the random failures, and tests are green! 🎉

Thanks @indigoxela and @quicksketch 🙏🏼

[laryn]

Looks great! Thanks @stpaultim for filing and for the initial PR, and @klonos for doing some of the clean up work in your alternative PR. Thanks to @olafgrabienski and @jenlampton for testing and code review. I've merged the backdrop/backdrop#3737 PR in backdrop/backdrop#3737 for 1.x so it will be included in 1.20.