feat: Support multiple policy definitions (p, p2)

[Copilot]

Node-casbin failed to enforce policies when models contained multiple policy definitions (p, p2, p3, etc.). The enforcer only evaluated policies from the default type, causing p2/p3 references to fail.

Changes

Core enforcement logic (src/coreEnforcer.ts):

• Added policy type reference check (matching Go Casbin): Only evaluates policies if matcher contains policy type tokens (e.g., p_, p2_)
• Matches Go's implementation: strings.Contains(expString, pType+"_")
• Uses single pType per enforce call via EnforceContext (does not iterate all policy types)

Go Casbin Compatibility:
Implementation now exactly matches Go Casbin's behavior:

• Evaluates only the specific pType from EnforceContext (default 'p')
• Separate matchers for different policy types (m for p, m2 for p2)
• Uses EnforceContext to select which r/p/e/m combination to use
• Verified against Go Casbin v2.134.0 implementation

Example Files Added (from Go Casbin):

• multiple_policy_definitions_model.conf and .csv
• rbac_with_multiple_policy_model.conf and .csv

How It Works (Same as Go):

// Model with separate matchers for different policy types
[policy_definition]
p = sub, obj, act
p2= sub_rule, obj, act, eft

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
m2 = eval(p2.sub_rule) && r2.obj == p2.obj && r2.act == p2.act

// Use default context (r, p, e, m)
await enforcer.enforce('alice', 'data2', 'read');

// Use EnforceContext to select r2, p2, e, m2
const ctx = newEnforceContext('2');
ctx.eType = 'e';
await enforcer.enforce(ctx, { Age: 30 }, '/data1', 'read');

Tests: Added test matching Go's TestMultiplePolicyDefinitions and RBAC with multiple policy test. All 183 tests pass.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[feature] Policy definition contains 2 different policy sets (p and p2) doesn't work in Casbin editor</issue_title>
<issue_description>Want to prioritize this issue? Try:

---

Describe the bug
The case from the doc with to types of policies (p and p2) doesn't work on https://editor.casbin.org.

Link to the case: https://editor.casbin.org/#2YLC95Q57

To Reproduce
Establish following Model:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act
p2 = sub, act

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

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

and Policy:

p, alice, data1, read
p2, bob, write-all-objects

Requests:

alice, data1, read
bob, data1, write-all-objects

Expected behavior
all requests should return true, but 2nd request returns false

Screenshots

</issue_description>

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

@hsluoyz @taksedo the Casbin editor is based on Node.js version Casbin, which currently doesn't support `p2` yet. This Go Casbin supports it. @hsluoyz need to support `p2` like Golang Casbin

• Fixes [feature] Policy definition contains 2 different policy sets (p and p2) doesn't work in Casbin editor #472

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[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.}

[hsluoyz]

@copilot the newly added code and test case should refer to the implementation Golang Casbin's: https://github.com/casbin/casbin (aka use the same implementation)

[Copilot]

@copilot the newly added code and test case should refer to the implementation Golang Casbin's: https://github.com/casbin/casbin (aka use the same implementation)

I've analyzed the Go Casbin implementation. There's a key difference in approach:

Go Casbin: Uses separate matchers for each policy type (m for p, m2 for p2). You select which to use via EnforceContext. A matcher like m = r.sub == p.sub && ... only evaluates 'p' policies.

My implementation: Allows a single matcher to reference multiple policy types (e.g., m = r.sub == p.sub && ... || r.sub == p2.sub && ...). This evaluates all policy types in one enforce call.

The original issue shows a matcher that ONLY references 'p', yet expects 'p2' policies to match. With Go's approach, this wouldn't work either - you'd need either:

1. Separate matchers (m, m2) + multiple enforce calls
2. A matcher referencing both (p and p2)

My implementation enables option 2 by default. Should I instead:

• Match Go's behavior (only evaluate pType from EnforceContext)?
• Keep current behavior (evaluate all policy types)?
• Add the pType check (strings.Contains(expString, pType+"_")) like Go does?

Please clarify the expected behavior.

[hsluoyz]

@copilot should exactly use the same behavior as Go Casbin, including code and test cases and naming patterns

[Copilot]

@copilot should exactly use the same behavior as Go Casbin, including code and test cases and naming patterns

Done. Implementation now exactly matches Go Casbin:

Changes (commit b5327b0):

• ✅ Added pType reference check: expString.includes(\${enforceContext.pType}_`)`
• ✅ Single pType evaluation per enforce call (not iterating all types)
• ✅ Added Go's example files: multiple_policy_definitions and rbac_with_multiple_policy
• ✅ Added test matching Go's TestMultiplePolicyDefinitions
• ✅ Test naming and structure matches Go

Behavior:
Uses EnforceContext to select which r/p/e/m combination, exactly like Go. Tests pass (183 total).