Closed (fixed)
Project:
Domain
Version:
3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
28 Oct 2025 at 12:10 UTC
Updated:
25 Dec 2025 at 16:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
mably commentedMR's current code gives a global update or delete grant to the user a soon as it has a permission to update or delete a particular content type, as our
node_accesshook will default to node grants if no specific permission is found (AccessResult::neutral()). That's probably not something we want.This will require a significant change to the
domain_access_node_accesshook to handle that properly.That's a change we could probably introduce in 3.x but it should be properly described, implemented and validated.
Comment #4
codebymikey commentedAttached a static copy of the latest MR.
Comment #5
lincoln-batsirayi commented@mably yeah i see what you mean, i guess the first part is we need to only allow the permission for the single specific content type and not all of them. Do you have a rough idea on the sorta change that will need to be made to the domain_access_node_access hook? Maybe if i had a better idea of the plan it might be something i can get started on.
Comment #6
mably commentedA solution could be to use per bundle grant realms.
A new node
node_accessrecord will be have to be created for each content.It could be interesting to have something before the first 3.x beta release eventually if we need to introduce some BC breaking changes.
Comment #8
mably commentedA solution based on bundle-specific grant realms has been implemented for Domain 3.x in MR 268.
@lincoln-batsirayi Could you give it a try and tell me if it solves the problem?
FWIW @agentrickard does not seem to be favorable to adding new
node_accessrecords:Don't know what to think about it.
I guess those extra joins would only be added to the queries when the user has some per-bundle permissions.
We might also need to add realms for each language for translated contents as some translations might only be available on specific domains...
But still not sure it's worth it.
Any feedback will be appreciated.
Comment #9
mably commented@lincoln-batsirayi could you provide a fully reproducible scenario for the issue?
I'm not sure to be able to reproduce the problem on my side.
Comment #10
mably commentedComment #11
lincoln-batsirayi commented@mably thanks a lot for looking into this, so I’ve tested various scenarios between your implementations for the 2.x and 3.x branch and this is what i found.
Tests conducted
2.x MR (261)
3.x MR (268)
So across both MR's, the edit any content on assigned domains permission is functioning as expected. But the individual particular permissions on a per content type basis aren’t functioning as expected in both MR's.
In terms of the reproducible scenario, i was able to also test this on a sandbox site that I’ve got which has minimal modules so less chance of conflicts and i got the same results as my main site.
Steps to reproduce:
Imagine this would be the same for the delete permissions so i didn’t test those specifically because the code is the same. Let me know if you have any other questions
Comment #12
mably commentedThis appears to be a rather complex problem to solve — if it’s even possible without causing performance degradation.
Let's see if someone comes up with a clever solution.
@lincoln-batsirayi you might want to check the
domain_access_node_access()hook and theDomainAccessManagercheckEntityAccess()method.And check what is present in the
node_accesstable of your Drupal installation. Access authorization will default to the usernode_accessrights when the content is not assigned to any domains.And if the content has no assigned domains, a record will still be added to the
node_accesstable using the current domain (check thedomain_access_node_access_recordshook). That explains your point 3.You can also check that related issue: #3047514: Logic flaw in grants?.
Remember to rebuild the node permissions when switching between MRs.
Unless new, valuable information is provided, this issue will be closed in 3 months.
Comment #13
mably commentedComment #14
lincoln-batsirayi commented@mably i believe I've managed to resolve the issue of the {content type}: Edit/delete any content on assigned domains permission on a single content type giving users the same permissions to ALL content types. I've added an explicit check which forbids access if the current user doesn’t have the specific update or delete permission for that content type. I’ve done several tests on my sites and this is working as expected.
I’ve only made this change on the 2.x MR for the moment.
Comment #15
lincoln-batsirayi commented@mably ignore my previous comment here, the permission issue i was seeing on my own set up was related to another permission on the content moderation module which I’ve removed and has seemingly resolved things.
So what this current patch is doing, is working for me. I'm gonna do some additional tests on a sandbox site now that i have more knowledge of the issue and then I’ll report back here :)
Comment #16
lincoln-batsirayi commentedOkay @mably I’ve done a lot of testing today and i can confirm that the MR for 3.x is working on both my main site and the sandbox site so that's working as expected due to the grants being added based on the content types `$grants['domain_id:' . $type_id][] = $active_domain_id;` so good job on getting that sorted.
Obviously because this doesn’t exist on the 2.x you can guess that my tests haven’t proved fruitful there, but i think should be okay if the main fix will be available in 3.x? I'm guessing we can’t backport that change that's in the 3.x MR into 2.x because of the addition of the new type based grant which would make it a major version change? If we can backport the type based grant change then that's good news!
Comment #17
mably commentedThanks @lincoln-batsirayi for your feedback.
Let's see if we can enable this in
3.xwhile keeping it optional.Comment #18
mably commentedComment #19
mably commentedThe new per-bundle granting feature can be enabled through a new Domain Access setting:
This new feature is disabled by default.
Could you give it a try @lincoln-batsirayi?
Comment #20
mably commented@lincoln-batsirayi could you please review latest MR?
I'm waiting for your RTBC to merge this.
Thanks.
Comment #24
lincoln-batsirayi commentedI’ve reviewed and tested this and can confirm it's working as expected. The edit and delete permissions on the content overview page and generally on content entities are functioning as requested on this issue.
Comment #26
mably commented