Metatag settings should not display in user's profile edit page

Created on 7 March 2024, 10 months ago

Problem/Motivation

When a user edits his profile page, he has access to metatags fields even if the permission to 'administer meta tags' is set to admin only. I tagged the issue as major because normally a registered users should not edit metatags ; this is an admin's task.

Steps to reproduce

  1. Log in as a registered user (not admin)
  2. Edit your profile
  3. You'll see the metatags field displayed.

Proposed resolution

Removing 'field_metatag' from the form display is not a solution as this also removes the field to admins.
As a temporary solution I added these lines in hook_entity_field_access:

  if ($operation == 'edit' && $field_definition->getName() == 'field_metatag') {
    if (!$account->hasPermission('administer meta tags')) {
      return AccessResult::forbidden();
    }
  }

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Active

Version

2.0

Component

User interface

Created by

πŸ‡«πŸ‡·France erwangel

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @erwangel
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    This is where you use Field Permissions β†’ to control which users have access to modify the fields. If your site doesn't need to override meta tags on a per user basis you could also just remove the Metatag field from the User entity type (i.e. Configuration -> People -> Accounts Settings -> Fields).

  • Status changed to Closed: works as designed 10 months ago
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • πŸ‡«πŸ‡·France erwangel

    Damien, I understand that I have to manage permissions but as I wrote "the permission to 'administer meta tags' is set to admin only". Isn't that enough ? With this setting, I don't understand why any other registered user has access to field_metatag too. Secondly, if I remove the field from the user entity, admins will not have access any more. Tercio, what is the benefit of users managing metatags by themselves? Metatags are used mainly for SEO purpose, and seo is not a user's concern.

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    The "admin meta tags" permission is for managing the module's configuration, it isn't for managing access to the field.

    Normally the Metatag field is only added to entity bundles where the person who's able to create or edit that entity would be able to edit the field, otherwise sites use tokens to pull other fields into the meta data output. Most sites don't want the meta tags to be overridden for each individual user, so normally the Metatag field isn't added to user entities.

    The majority of sites don't need permissions at the field level, and those that do have an existing solution available, i.e. Field Permissions, hook_form_alter() or hook_field_widget_single_element_form_alter(). Using the "administer meta tags" permission to control who can access the field that's on entity forms would also allow such people to access the module's main settings, which isn't what most sites want. Furthermore, adding more permissions to Metatag to control access to the field just overcomplicates things when there are existing options.

    The module was built this way on purpose to avoid overcomplicating things and to leverage existing functionality when people want to customize it more than most need.

    Thankfully there are options available to you to accomplish your goal, and I'm glad to see you've been able to work out a solution.

    Thank you for opening this issue and discussing it, I hope you can appreciate the decisions behind how the module works.

  • πŸ‡«πŸ‡·France erwangel

    I was confused by the "admin meta tags" permission scope. Your answer makes it much clearer now. Thank you for taking the time for this.

  • Status changed to Needs review 10 months ago
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 10.2.1 + Environment: PHP 8.1 & MySQL 8
    last update 10 months ago
    128 pass
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    I think we should use this as an excuse to improve the wording on the permission, because apparently it did imply it controlled access to the per-entity field.

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    Is the new wording better? Can you think of further improvements?

  • πŸ‡«πŸ‡·France erwangel

    Hmm... A bit long the new description. Metatags are not only in content types; we found them in taxonomies, in users, in views, etc... Why not set a second permission ? Two permissions are not too much and could avoid long explanations to say what a permission does and what it does not. Example : the current permission "Who controls the per bundle Metatags settings. And a new one for "Who controls the Metatags content".

    Metatags demands quite technical skills or at least knowing to what they serve. Or in a site with large audience, the presence of this field can be confusing to users. For example, in my site I have content types that are reserved to accredited authors. Okay they can be informed and trained on the usage of metatags, but other content types are open to all registered users while some other content types (like forums) are open to even anonymous users. We usually fill default metatags, eventually with tokens. We can not trust all these users that they will fill correctly the metatag fields.

    Imagine you have a recipe type where users can post their preferred recipes (I hope you like cooking), SEO is important for this kind of content. You activate default metatags + Schema.org: Recipe. Users will then be faced with several dozens of metatags to fill. And if they search some help clicking the "available tokens" link they will really be... lost in translation.

    I think that access of metatags to users should be only an option and by default users should not have access. Metatags is too powerful to leave in the hands of just anyone. I think metatags should behave by default like the other "system" fields (authored, promoted, sticky, alias, ...). I'm not sure but I think this was the case in Drupal 7, anyway I don't remember having to deal this kind of problem in D7.

  • πŸ‡«πŸ‡·France erwangel

    Changed title to better reflect the issue

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • Status changed to Needs work 6 months ago
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    The description could use a little work.

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA
  • Status changed to Needs review about 2 months ago
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    This is what I'm going with.

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    Committed.

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

Production build 0.71.5 2024