Fix getImplicitPermissionsForUser for wildcard domain policies in role hierarchies

[Copilot]

getImplicitPermissionsForUser() fails to retrieve permissions when roles inherit from abstract roles with wildcard domain policies (*). This prevents role hierarchy patterns where permissions are defined once with domain * and inherited by domain-specific roles.

Changes

getImplicitRolesForUser

• Queries both specific domain and wildcard domain * when retrieving roles
• Supports matcher patterns: g(r.sub, p.sub, r.dom) || g(r.sub, p.sub, '*')

getImplicitPermissionsForUser

• Uses model.getFieldIndex() to locate domain field instead of assuming sequential position
• Filters policies to match both exact domain and wildcard domain *
• Maintains backward compatibility for policies without domain fields

Example

// Policies with wildcard domain
p, admin_role, data, read, *
p, admin_role, data, write, *

// Role hierarchy with domains
g, tenant_admin, admin_role, tenant1
g, alice, tenant_admin, tenant1

// Now works correctly
await e.getImplicitPermissionsForUser('alice', 'tenant1')
// Returns: [['admin_role', 'data', 'read', '*'], ['admin_role', 'data', 'write', '*']]

Test coverage added for role hierarchy with wildcard domains. All existing tests pass.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>How to do Role hierarchy with domain using casbin</issue_title>
<issue_description>Hi for my usage,I need to setup casbin with role hierarchy to avoid duplication beetwen domain.

Example of policies

### Define global user role permissions
p, abstract_roles1, devis, read, *
p, abstract_roles1, devis, create, *

p, abstract_roles2, devis, read, *
p, abstract_roles2, organization, read, *
p, abstract_roles2, organization, write, *


### Define role inheritance
g, roles1, abstract_roles1, tenant1
g, roles1, abstract_roles1, tenant2
g, roles1, abstract_roles1, tenant3

g, roles2, abstract_roles2, tenant1
g, roles2, abstract_roles2, tenant2
g, roles2, abstract_roles2, tenant3

g, super_user, abstract_roles2, *

### Assign users to roles
g, michael, roles1, tenant1
g, antoine, roles1, tenant2
g, kevin, roles1, tenant3

g, thomas, roles2, tenant1
g, thomas, roles2, tenant2
g, lucie, roles2, tenant3

g, theo, super_user, *

Example of configuration

[request_definition]
r = sub, obj, act, dom

[policy_definition]
p = sub, obj, act, dom, eft

[role_definition]
g = _, _, _

[policy_effect]
e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

[matchers]
m = (g(r.sub, p.sub, r.dom) || g(r.sub, p.sub, '*')) && (p.dom == '*' || r.dom == p.dom) && r.obj == p.obj && r.act == p.act

Is this method the best approach, or are there alternative methods available? How can I retrieve all permissions for a user using this library?

Currently, this.enforcer.getImplicitPermissionsForUser() is not functioning as intended.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes How to do Role hierarchy with domain using casbin #481

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[mserico]

@copilot don't modify yarn.lock

[mserico]

@copilot don't modify yarn.lock