Summary:	ASTERISK-20862: Asterisk min and max member penalties not honored when set with 0
Reporter:	Schmooze Com (schmoozecom)	Labels:
Date Opened:	2013-01-03 14:01:52.000-0600	Date Closed:	2013-11-11 09:39:01.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	SVN	Frequency of Occurrence
Related Issues:	is related to ASTERISK-21879 app_queue's autofill=yes effectively fails to deliver all calls when those calls are preceded by a call with a min/max penalty that can't be delivered is related to ASTERISK-19368 Queue penalty only work when QUEUE_MIN_PENALTY == QUEUE_MAX_PENALTY
Environment:	All versions of Asterisk this happens on	Attachments:	( 0) queue_penalty_fix.diff
Description:	If I set a queue to have a max member penalty of 0 and a min member penalty of 0 and log in 2 members one with a penalty of 0 and one with a penalty of 1 Asterisk will still offer a call to the member with a penalty of 1 if the member with a penalty of 0 is busy.  Basically ignoring the min and max settings. Now if I do the same test with member penalties of 1 and 2 and set the min and max member penalty to be 1 it behaves correct and never offers the member with a penalty of 2 a call even if member with a penalty of 1 is busy.
Comments:	By: Paul Belanger (pabelanger) 2013-01-18 11:14:38.545-0600 This is like a documentation fix, asterisk defaults things to 0, which is likely why it is not working as you are expecting.  Basing everything from 1, should have things start working as expected. By: Schmooze Com (schmoozecom) 2013-01-18 11:18:34.183-0600 Paul Thanks for the response but I would politely disagree on that statement as a valid Penalty is 0 so the min and max should still honor that.  It really breaks functionally by not doing so. By: Paul Belanger (pabelanger) 2013-01-18 11:59:05.955-0600 What functionality is this break?  Did this work before and not now? Basically, from what I see unexpected things are happening because 0 is being the default for so many internal things. If you really want the expected functionality, use 10, 100 and 1000 as your base, then add / subtract from there. By: Schmooze Com (schmoozecom) 2013-01-18 12:06:51.428-0600 It breaks the functionality of what the min and max settings are for.  It ignores what you set and acts like their are no min and max settings.  Its not as simple as just using higher penalties as the default login of a member is 0 so most members logged in will be 0. By: Paul Belanger (pabelanger) 2013-01-18 12:11:52.303-0600 So, how do you think QUEUE_MIN_PENALTY / QUEUE_MAX_PENALTY should work when setting it to zero in your example? By: Schmooze Com (schmoozecom) 2013-01-18 12:20:46.864-0600 Paul In our setup with some new changes in FreePBX 2.11 we have the ability to set escalation rules. So for example I setup my queue with a min and max penalty of 0 so it only tries my tier 1 agents.  Then after 2 mins I tell it to increase the max from 0 to 1, so now it will include members with a penalty of 0 and 1 and so forth. The issue comes in if I set the min and max to 0 which is what most people will start with it ignores the max and will try members with a higher penalty right away of all the members with a 0 are not around even though my rule for including members with a penalty of 1 should not kick if for 2 minutes. By: Philippe Lindheimer (p_lindheimer) 2013-01-18 12:21:46.796-0600 That seems to be a straight forward answer. If you set QUEUE_MIN_PENALTY and QUEUE_MAX_PENALTY to 0, then the only member that should ever be tried are those with penalty 0. The fact that 0 happens to be the default is not really relevant, it's just the default. It's the same as if you set MIN/MAX to 1, only penalty 1 agents will be tried. It would seem that you are implying that there are QUEUE_MIN_PENALTY and QUEUE_MAX_PENALY defaults internal to app_queue and are being treated as 0 and thus the current operations. If that is the case, that seems to be the 'flaw' since ... if those are not set then the defaults should either be "not set" however you represent that, or the defaults should be a MIN of 0 (since I don't believe negative numbers mean anything or?) and MAX should be what ever the maximum penalty possible could be. By: Paul Belanger (pabelanger) 2013-01-18 12:30:49.561-0600 You made the exact point I am trying to explain during my testing.  Everything defaults to 0 (off) for queue penalties, which appears to disable penalties state. Like you, I believed setting it to 0 would make penalties work.  The reality is, bump your starting point to 1, and updating all your logic to add 1 as the base penalty, things work as you will expect. So to recap, having the penalty set to 0 simply disables the penalty functionality.  And anything other then 0, enables it. If you want to change the functionality, feel free to submit a patch but my opinion is we need to update documentation to reflect this. By: Schmooze Com (schmoozecom) 2013-01-18 12:33:04.245-0600 Paul As I stated in the ticket when I opened it. If I bump everything by 1 it works.  My issue is it should work with 0 and 0. This would be a bug in my eyes not simply a documentation issue. By: Matt Jordan (mjordan) 2013-01-18 13:18:58.077-0600 I agree it's a bug. The work around is to start at 1 - that doesn't change the fact that 0 should work. (Because let's face it - 1 based indexing is wrong, has always been wrong, and will always be wrong). I'm fine with this issue being open. By: Kinsey Moore (kmoore) 2013-11-04 15:47:14.098-0600 I have attached a potential fix for the situation you have encountered. It corrected the problem that I reproduced in my lab-up, using INT_MAX as the "disabled" value. Negative values are still off-limits with this patch. I'd appreciate it if you could find the time to test it and it should be up on reviewboard shortly.