🇬🇧United Kingdom @jeni_dc

Sorry to keep adding to a closed issue, but for the folks who commented earlier and anyone else who ends up here, removing the default "Entity URL Generator" from the domain specific sitemap types generated by domain simple sitemap got me the correct results. Make sure "Domain entity URL generator" is the only entity URL generator available in the domain specific sitemap types otherwise all entities from the default domain get added to all of the sitemaps for the other domains.

In my case I was only adding nodes as well as taxonomy terms assigned to a domain through the domain entity module → to the sitemaps.

This is with Simple XML Sitemap 4.1.8 and Domain Simple Sitemap 3.0.0-beta1.

I just tested this with a fresh install of Group 3.2.2 with Group Term 4.1.0 on both core 10.1.8 and 10.2.2 and the add term form looked as it should. Screenshot attached.

Thanks for your work on this, Andy! All the tests look good, but I'm not sure we should include the changes to the .install file as a part of this. In particular, this commit:

https://git.drupalcode.org/project/tasty_backend/-/merge_requests/2/diff...

Is there a specific reason these changes were included along with the tests? I'm aware of possible issues in the module in deployment versus initial install, but I think there's going to be other things that need addressing properly related to that and I don't want these changes lost in this issue for adding the tests.

In particular, this added section:

// Add role assign roles to user manager.
    $roles = \Drupal::entityTypeManager()->getStorage('user_role')->loadMultiple();
    foreach ($roles as $role) {
      $role_id = $role->id();
      if ($role_id == 'content_admin' || $role_id == 'user_admin') {
        user_role_grant_permissions('user_admin', [
          'assign ' . $role_id . ' role'
        ]);
      }
    }

It re-adds the 'assign content_admin role' permission to the user admin role that's already included in the user.role.user_admin.yml config file.

I had addressed an issue related to assigning the User Admin role the 'assign user_admin role' permission (not documented in this issue queue yet) in this commit, which removes that permission from the user.role.user_admin.yml file and re-adds it during a hook_ENTITY_TYPE_insert.

https://git.drupalcode.org/project/tasty_backend/-/commit/f254753f15b03f...

That issue is documented in the Role Delegation issue queue at 🐛 Adding non-existent permissions to a role is not allowed Active

So I think your addition to the hook_install here might duplicate what's already in place from my previous commit to make sure that permission gets added to the user admin role when the role is created. That needs to happen not only during module install but also deployment since IIRC having that permission in the role config during a deploy will trigger the same error. So we'll need a separate issue to manage that. If there's something specific related to the tests and that please let me know.

Can we call it Drupal XP?

https://www.drupal.org/project/drupal_xp →

The XP could stand for Xtra Protection.

Drupal 10 compatibility is available in the lastest dev.

jeni_dc → changed the visibility of the branch 3405581-allow-collecting-stats to active.

jeni_dc → changed the visibility of the branch 3405581-allow-collecting-stats to hidden.

jeni_dc → created an issue.

D'oh, I realised as soon as I posted that we can't just return the options from the parent like that, the rest of the fields won't be taken into account as soon as one comes up that the current user can't edit. Here's a new patch that overrides $options only if the user cannot edit the field.

Here's a quick patch that checks if the current user has access to edit term reference fields. If they do not it just returns the options from the original TermSelection class.

With this in place and the setup described in #3 when the non-admin user edits their account the values persist.

Thanks, I've been able to reproduce this on a fresh D10 (10.1.6) install with standard profile. Here's the steps I took to reproduce it:

1. Install Drupal.
2. Add non-admin user.
3. Add vocabulary.
4. Add three terms to the vocab.
5. Add term reference field to user accounts. This field only allows references to the vocab set up in step 3. The field allows unlimited values and uses check boxes/radio buttons on the form.
6. Disallow access to the field for non-admins in a hook_entity_field_access(). Code to follow.
7. Add and enable Taxonomy Access Fix 4.0.1.
8. As an admin user, set two values on the field for the non-admin user that was added.
9. Load the user edit form as the non-admin user. I was already on that page logged in as that user so I refreshed the page. The term reference field is not available to edit for the non-admin user.
10. Save the user edit form as the non-admin user.
11. Refresh the user edit form as the admin user and see the values set in the field are now gone.

If I then give the authenticated user role the TAF permission to select terms in that vocabulary, with access still denied to that field, and then edit the account as the non-admin user, the values in the field persist.

Here's the code used to deny access to the field. I did this in a taf_test module that only contains the hook_entity_field_access and one custom permission since that's how my sites are set up where I've seen this happen. Here's the contents of taf_test.module:

use Drupal\Core\Access\AccessResult;
use Drupal\Core\Field\FieldDefinitionInterface;
use Drupal\Core\Field\FieldItemListInterface;
use Drupal\Core\Session\AccountInterface;

/**
 * Implements hook_entity_field_access().
 */
function taf_test_entity_field_access($operation, FieldDefinitionInterface $field_definition, AccountInterface $account, FieldItemListInterface $items = NULL) {
  if ($field_definition->getTargetEntityTypeId() == 'user' && $operation == 'edit' && $field_definition->getName() == 'field_term_ref' && !$account->hasPermission('edit taf_test fields')) {
    return AccessResult::forbidden();
  }
  return AccessResult::neutral();
}

On the sites where this is happening there are four term reference fields on the user. Three allow multiple values, one does not. The multiple value fields all use check boxes, the other one uses a select element. All of them don't have any field values after the user edits their own account. At first I thought that the one field that only allowed one value in a select element didn't lose it's value, but I then realised that was just my browser since when I held shift and hit refresh that field didn't have the term selected any more.

jeni_dc → created an issue.

Adding patch.

jeni_dc → created an issue.

Patch from #12 applied cleanly for me on 2.0.0-beta1 and the error is now gone. The block shows as expected.

D'oh! This is already fixed in 🐛 Remove deprecated core key that breaks site Fixed

Marking as duplicate.

Looks like the .info.yml file still contains core: 8.x

Patch attached to remove it.

D'oh! I always screw up a merge request somehow. I've closed 11 which didn't contain the changes, 12 does. This adds the field formatter, schema, theme hook, and template for Planet eStream embeds.

One thing I was unsure of was any way to offer instructions on which URL from Planet eStream to use for the Remote Media URL field. They offer a few with their embed codes, the easiest one is the OneNote link. See the attached screenshot. Add instructions to the README? (Worth noting I have nothing to do with the video in the screenshot, it was just a public video I happened to find that offered embed options)

jeni_dc → created an issue.

Sorry for the late reply I only had a chance to update Gin on that site. Yes the changes are still working as expected, but that site is still on Group 2 for the time being so I can't really say for now with Group 3.

I tested this on latest dev and 8.x-3.0-rc2, both worked as expected.