Allow each tag to have its own permission (merge Metatag Access)

It would be a honor :) Let me know when it's released so i can remove this helper module from my current project.

Can i write the tests? I have not yet written any tests for drupal modules, could be good exercise for me.

Hi,

sorry for my long absence. We had a big relaunch in our company and there wasn't much free time for coding... :/

Anyway! I want to write this test asap. How to get startet?
Is this a good resource https://docs.acquia.com/article/lesson-102-unit-testing
Any additions?

Regards
Michael

After a bit of research i'd write the test based on the WebTestBase Class.

I'd implement the following test scenarios:

• Grant all or some permissions and check the node add form.
  => Expecting MetaTag Options available.
• Revoke all permissions and check the node add form.
  => Expecting no MetaTag Options available.

In my setUp method i would:

• Create a user
• Create a node type

So far my plan, any additions?

Best regards
Michael

Thanks for your feedback i will start working on this after work. I will share my results asap.

I found a few bugs in the code in the patch, so I fixed those. Attached is the new patch

• The machine names of the permissions were based on the names of the tags, but the permissions were used with the key in list of definitions. I changed the internal names of the permissions to the keys of the definition.
• In the form, all elements were handled, instead of only the elements that represent a group. Now, the form elements with intro and tokens are ignored by the form_alter funciton.

Current patch works great for me!

Has there been any movement to finish testing and roll this feature into the module? We're migrating to D8, and I would really like to limit the metatag fileds available to non-admins. Thanks!

Patch in #16 works great and does what I expected coming from Drupal 7. Without the ability to filter the available meta tags for clients I feel it's just too much noise to be usable. This sub module does what I need.

Not to mention that the original "administer meta tags" permission doesn't even distinguish between access to the meta tags settings form or just the ability to change meta tags on nodes.

Not sure where this is in regards to getting tests run against it but patch definitely still works.

Would be good to get this committed after testing as it's a commonly needed feature for the module.

Not sure if DamienMcKenna will be able to assist with that?

Need to actually take a look at this but just got to say

+++ b/metatag_fine_grained_perms/tests/src/Functional/SiteStillWorks.php
@@ -0,0 +1,54 @@
+class SiteStillWorks extends BrowserTestBase {

<3

Another solution for filtering the list of visible meta tags: #3108108: Allow which metatags are visible on the field widget to be editable

Because #25 introduces a new submodule I like this more than #3108108 which currenctly changes definition of existing services that is going to break deploys on dowstream projects. Although, I must admin the test in #25 is useless :)

Hello! I have just stumbled upon this issue. I am looking for a solution for this use case: as a content editor, I want to see only meta tag fields which I have rights to edit them. By any chance, does this new module responds to this use case?

Thank you very much! I am feeling lucky today. :) Good job, everyone! 👏

A bit late to the party, this is interesting, but the amount of of permissions this is going to add is going to be a deal-breaker for a lot of sites, including ours. Especially if you add modules like schema_metatag to the mix.

Couldn't this be opt-in like field_permissions has been for a while, where you can enable permissions per group or even tag and possibly also have it share the same permissions. It's quite a bit more complicated, but I think the majority of sites aren't going to need 100 permissions that they can each uniquely assign, they're going to have 1-3 sets/levels of metatags that they want to make accessible for their different user roles.

It also only partially addresses the performance aspect of this, as the hidden form elements still need to be processed by the form builder.

Some approaches I've seen introduce the concept of filtering definitions, then not having permission from them could already skip them from being instantiated and preparing the form. Of course yet another complication is that there might be values that need to be persisted even if the current user doesn't have access.

What we did in our project is to have a list of "restricted metatags" and all those are then behind a single permission check.

I'm fully aware that I'm late with that comment, now that it has been committed like this.

@Berdir In a nutshell, did you assign tags to a (dynamic/static?) permission (working on field level permissions?), and then, assign this permission to a role?

I have a little site with relatively few enabled options, so it did not occurred to me that this could become a hassle to administer... Good catch!

We have one setting that's a list of restricted/hidden metatags and then a form alter that hides them, similar to what this module added.

Looks like this:

```
'foo_module.settings:restricted_metatags':
- basic.abstract
- advanced.geo_placename
- advanced.geo_position
- advanced.geo_region
- advanced.icbm
- advanced.robots.index
- advanced.robots.follow
- advanced.robots.noarchive
... (pretty long list)
```

Not sure what the best middleground between the this (which might not be flexible enough for some sites) and the permission-per-element would be. One thing to note is that our form alter can even go deeper than the plugin level, in the example above you can see that we're hiding all but two options of the robots checkboxes.