fix: Nest Loki_Base::config ACL resource under Magento_Backend::admin - #3
Merged
jissereitsma merged 2 commits intoOct 2, 2026
Conversation
added 2 commits
September 28, 2026 16:56
Loki_Base::config was declared at the top level of the ACL tree, next to Magento_Backend::all and Magento_Backend::admin. Magento core locates the admin subtree by position: Magento\Integration\Model\Config\Consolidated\Converter reads $allResources[1]['children'], assuming the top level is exactly [Magento_Backend::all (10), Magento_Backend::admin (20)]. With sortOrder 10, Loki_Base::config lands among them and pushes admin off index 1, so the converter hashes the wrong subtree and integration.xml resources stop resolving for every integration in the store. A top-level resource is also invisible in the role editor, which only shows the admin subtree, so restricted admin roles could never be granted access to the Loki Base config section. The resource now sits under Magento_Config::config, where core declares its own config-section resources. The id is unchanged, so system.xml and saved role rules keep working.
Nesting it four levels deep under Magento_Config::config was more than the fix needs. What matters is that it is no longer a top-level sibling of Magento_Backend::admin; one level under admin is enough to keep admin at index 1 and to make the resource grantable in the role editor.
tschallacka
changed the title
Contributor
|
Thanks for spotting this. Completely makes sense! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLDR
Loki_Base::configis declared as a top-level ACL resource, next toMagento_Backend::admininstead of inside it. That breaks Magento's integration ACL resolution and hides the permission from restricted admin roles. I moved it one level down, directly underMagento_Backend::admin.Magento core finds the admin tree by array position, not by id.
Magento\Integration\Model\Config\Consolidated\Converter::convert()reads$allResources[1]['children']and expects the top level to be exactly[Magento_Backend::all (sortOrder 10), Magento_Backend::admin (sortOrder 20)]. WithsortOrder="10",Loki_Base::configlands among them and pushesMagento_Backend::adminto index 2. The converter then hashes the wrong subtree, and the ACL resources in any module'sintegration.xmlstop resolving. We hit this in a shop running Loki and had to decorateMagento\Framework\Acl\AclResource\ProviderInterfaceto moveadminback to index 1.This is not specific to Adobe Commerce/Magento Open Source: Mage-OS has the same lookup on
main,release/4.xand2.4-develop, and the sameall/admintop level. It only surfaces in a store where some module ships anintegration.xmlwith ACL resources, which is likely why it has gone unnoticed.The role editor also only shows the
Magento_Backend::adminsubtree. A top-level resource never appears as a checkbox, so only "All" roles could open the Loki Base config section.Raising the
sortOrderabove 20 would avoid the index problem, but only by luck, and the resource would still be missing from the role tree, so I nested it instead. Sitting inside the admin subtree, it becomes grantable to restricted roles. The resource id is unchanged, sosystem.xmland existing role rules keep working.etc/acl.xmlvalidates againstMagento/Framework/Acl/etc/acl.xsd. I haven't run it in a store with Loki installed yet.The other Loki modules may declare their resources the same way. I only checked Loki_Base.