app_queue: Account for priority when forcing longest waiting caller. #1640
Conversation
|
|
|
Workflow PRCheck completed successfully |
|
cherry-pick-to: 23 |
Pull Request Checklist Complete
jcolp
left a comment
There was a problem hiding this comment.
This is a substantial enough change that an UpgradeNote should be added to the commit message to notify people of it.
Check priority first when determining which caller is waiting the longest, so that callers with higher priority will always ring first even if they have less wait time. Resolves: asterisk#1637 UpgradeNote: The force_longest_waiting_caller option now takes call priority into account. Calls are offered by priority first, then by wait time.
504af35 to
8292a06
Compare
|
Workflow PRCheck completed successfully |
jcolp
left a comment
There was a problem hiding this comment.
The sample configuration also needs to be updated. Right now the behavior is explicitly stated that it is longest waiting caller, it makes no mention of priority being considered.
I think that also raises a question I would like feedback from others on. This changes the existing option behavior and goes counter to what it has been. From a least surprise perspective I wonder if this new behavior should be opt-in only so existing users are not taken off guard when things change.
Pull Request Checklist Complete
Check priority first when determining which caller is waiting the longest, so that callers with higher priority will always ring first even if they have less wait time.
Resolves: #1637
UpgradeNote: The force_longest_waiting_caller option now takes call priority into account. Calls are offered by priority first, then by wait time.