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, over 6 years ago
Updated 28 April 2023, over 1 year 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 work

Version

2.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 over 1 year ago →
    🇺🇸United States joshuasosa

    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 over 1 year 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 over 1 year ago
  • Comment over 1 year 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 over 1 year 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 over 1 year ago
    Patch Failed to Apply
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024