lupus_decoupled_menu install hook breaks on site install.

Created on 23 November 2023, 12 months ago
Updated 28 November 2023, 12 months ago

Problem/Motivation

On a site install using existing config I get this error message:

[error] Error: Call to a member function grantPermission() on null in lupus_decoupled_menu_install() (line 32 of /var/www/html/docroot/modules/contrib/lupus_decoupled/modules/lupus_decoupled_menu/lupus_decoupled_menu.install) #0 [internal function]: lupus_decoupled_menu_install(true)

Steps to reproduce

Run drush si --existing-config with a config that enabled lupus_decoupled_menu

Proposed resolution

Check if role exists in install hook

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

🇦🇹Austria arthur_lorenz Vienna

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

Merge Requests

Comments & Activities

  • Issue created by @arthur_lorenz
  • Merge request !67Check if roles exist in install hook. → (Merged) created by arthur_lorenz
  • Status changed to Needs review 12 months ago
  • 🇳🇱Netherlands roderik Amsterdam,NL / Budapest,HU

    I don't know if I should set Needs Work, Needs more info or just test it myself (not sure about my allocated time anymore).

    I guess I'll rely on an actual module maintainer to do whatever.

  • 🇦🇹Austria arthur_lorenz Vienna

    but I'm kind-of weirded out by the notion that anonymous/authenticated roles would not exist

    In the end both roles are just some config. If the config was not yet applied, the roles won't exist. But I should add the user module as dependency.

    and a little afraid that now they won't get the "restful get rest_menu_item" permission assigned as they should.

    don't be :) Usually this should only occur during site install with existing config. Then the permission should be applied in the config files and imported later on. Otherwise the roles should already exist. If not there might be a reason for it and it should not fail.

    But I'm wondering if it makes more sense to check the `$is_syncing` and skip the step if it's true to not mess with any config.

  • Status changed to RTBC 12 months ago
  • 🇳🇱Netherlands roderik Amsterdam,NL / Budapest,HU

    Right. Thank you for clarifying :-) I should have kept $is_syncing in mind.

    The explanation + the scope of the change (only when $is_syncing, which previously had an error) enables to RTBC after just reviewing code.

  • First commit to issue fork.
  • Status changed to Fixed 12 months ago
  • 🇦🇹Austria fago Vienna

    Merged, thank you!

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

Production build 0.71.5 2024