Contrib.social

role/gid mapping refresh when gid missing (related to configuration synchronisation of content_access.settings and grey listing of roles with config_split)

Open on Drupal.org →
Created on 12 April 2018, almost 7 years ago
Updated 13 March 2023, about 2 years ago

Hello,
i just ran through an issue on a specific Drupal 8.5.x site.

i have content_access and config_split modules installed and set up on three different environments (i.e. dev, stage, prod).
Role entities are config entites "greylisted" using config split (each environment keeps a local copy of roles created there, especially on the prod).
The configuration of content_access is stored in the main configuration directory (not managed with config split).

When code is deployed to prod environment, "content_access.settings" configuration is imported from the config directory to the prod database (in particular, the mapping inside the config called "content_access_roles_gids" is overwritten in db by the data provided in the conf file). The problem occurs when roles have been created only on the prod environment, here is the way to reproduce :
> Some roles are created inside the UI, "content_access_roles_gids" inside ""content_access.settings" config is updated when the role entities are created (relying on hook_entity_insert implementation in content_access module)
> after role creation, some access settings (for nodes and/or content_types) are updated in the UI : the newly added roles have custom access permissions checked.
> a deployment of config is made to the prod environment, the keys of array "content_access_roles_gids" (in content_access.settings) for the prod-only roles are lost when "content_access.settings" are re-imported during deployment workflow.

when gid are missing for existing roles and some content access settings relate to those roles,
"content_access" provokes exceptions (during node save..Etc) because roles lack of gid inside the "content_access.settings" config in database.

This problem could be tackled with a custom deployment logic... yes but the content_access module may also tackle such cases of gid missing and "content_access_roles_gids" mis-synchronisation.

Proposed solution:
when the gid is requested for a particular role, if gid is missing, "content_access_roles_gids" is re-updated with missing roles.

see the patch. The patch is clearly not perfect but i think it is a good starting point for discussion.
The patch is in three parts, the third part may be the more important, while the two others could be removed.

thanks in advance for the feedback
best

Mikael

✨ Feature request
Status

Needs review

Version

1.0

Component

Code

Created by

🇫🇷France just_like_good_vibes PARIS

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 2 years ago →
    🇺🇸United States j_s

    Hello, I also ran into this issue with 8.x-1.0-alpha4. I have a configuration sync that brings in default roles to content_access.settings.yml and unfortunately clears custom roles on the site from that list.

    This patch helped, though it didn't apply cleanly and there was some issue with the grants section not working properly and causing access denied for all roles. I was able to use the part where it rescans roles and added it to my configuration syncing code, so hopefully it won't continue being an issue for me even without this patch. But I can at least confirm that it's an ongoing issue for some configuration syncing setups.

  • @just_like_good_vibes opened merge request.
  • Comment almost 2 years ago →
    🇫🇷France just_like_good_vibes PARIS

    Hello,
    i tried to update the old patch to be in sync with the current version of the module in git (8.x-1.x).
    I created a fork repository and i opened a merge request.
    the patch can be retrievd there : https://git.drupalcode.org/project/content_access/-/merge_requests/7.patch
    i am now working on the migration to drupal10 of the website that originally raised this issue and required this patch to work.
    I will therefore be able to test this patch in the coming weeks/months on that particular website.

  • Status changed to Needs work almost 2 years ago
  • Comment almost 2 years ago →
    🇳🇴Norway gisle Norway

    All feature requests go into the most recent branch.
    Will need reroll for version 2.0.x-dev.

  • Open in Jenkins → Open on Drupal.org →
    Core: 10.0.7 + Environment: PHP 8.1 & MySQL 5.7
    last update almost 2 years ago
    Patch Failed to Apply
  • Open in Jenkins → Open on Drupal.org →
    Core: 10.0.7 + Environment: PHP 8.1 & MySQL 5.7
    last update almost 2 years ago
    Patch Failed to Apply
  • Comment 2 days ago →
    medeirosde

    I am also running into this issue and am trying to use #8 to fix the warning dumps happening. We have many roles defined by a team of content managers and users are seeing these warnings all the time. I upgraded to 8.x-1.0-alpha4 that was supposed to have a fix and one warning stopped and another one started in the content_access_optimize_grants call because the fix was to return a null if not found. I think this patch works better because it tries to fix the missing ids and clean out old grants with no id, since I can't imagine those are useful. I am on Drupal 9.4 and slowly upgrading to hopefully 10.X in the end. Going to run this one for a while and see how it goes seems to be working so far in testing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024