9efd554693
## Description When Assignment V2 is enabled, the V2 capacity policies (AgentCapacityPolicy / InboxCapacityLimit) are not respected during team-based assignment paths. The system falls back to the legacy V1 max_assignment_limit, and since V1 is deprecated and typically unconfigured in V2 setups, agents receive unlimited assignments regardless of their V2 capacity. Root cause: Inbox class directly defined member_ids_with_assignment_capacity, which shadowed the Enterprise::InboxAgentAvailability module override in Ruby's method resolution order (MRO). This made the V2 capacity check unreachable (dead code) for any code path using member_ids_with_assignment_capacity. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? ⏺ Before the fix 1. Enable assignment_v2 + advanced_assignment on account 2. Create AgentCapacityPolicy with InboxCapacityLimit = 1 for an inbox 3. Assign the policy to an agent (e.g., John) 4. Create 1 open conversation assigned to John (now at capacity) 5. Create a new unassigned conversation in the same inbox 6. Assign a team (containing John) to that conversation 7. Result: John gets assigned despite being at capacity ⏺ After the fix Same steps 1–6. 7. Result: John is NOT assigned — conversation stays unassigned (no agents with capacity available) ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules |
||
|---|---|---|
| .. | ||
| app | ||
| config | ||
| lib | ||
| LICENSE | ||
| tasks_railtie.rb | ||