Summary:	ASTERISK-15133: [patch] QUEUE_MEMBER(...,free) counts wrapping-up agents as available
Reporter:	Kirill Katsnelson (kkm)	Labels:
Date Opened:	2009-11-13 01:34:16.000-0600	Date Closed:	2010-01-05 09:27:41.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) appqueue-memberfun-readyoption.diff ( 1) appqueue-memberfun-readyoption-trunk.diff
Description:	the QUEUE_MEMBER dialplan function can return total members, logged-in members and "free" members count. A member is counted as "free" immediately after his call ends, even though its wrap-up time, if specified in queues.conf, has not yet expired, and the queue will not actually route a call to it. ****** ADDITIONAL INFORMATION ****** Sending in a patch that creates another specifier for the function, "ready", to count only agents that are immediately available to route calls to. The patch is against vanilla 1.6.1.6, but function code has not changed as of 1.6.2.0-rc5.
Comments:	By: Leif Madsen (lmadsen) 2009-11-13 07:18:46.000-0600 New features need to be submitted against trunk in SVN. Likely this patch will just apply to trunk (but I have not tested). New features can only go into the next release of Asterisk, and not currently branched versions. Thanks for the submission! By: Kirill Katsnelson (kkm) 2009-11-13 18:34:36.000-0600 Can I resubmit it in case it fails to apply to the trunk (assuming it might ever be applied)? I am not actively developing Asterisk, and only fixing annoyances that get in the way -- so I do not even have a trunk sandbox. If I have more substantial parts added, I guess I should. I have only a very vague idea of Asterisk development process, sorry. By: Leif Madsen (lmadsen) 2009-11-16 10:05:23.000-0600 I just tried to apply it to trunk, and it doesn't apply unfortunately. I may be able to find the time to try and update it, but there is one chunk of code that failed to apply, and I'm not sure if it was just because of an offset it couldn't find, or if there is a code here that needs to be updated -- I'm not a coder, so I'll need to see which of the two it is :) By: Leif Madsen (lmadsen) 2009-11-16 10:05:51.000-0600 Note that I think this is useful functionality, and I see no reason why it shouldn't go into trunk at some point. By: Kirill Katsnelson (kkm) 2009-11-16 17:35:55.000-0600 I'll send in a patch against the trunk in a day or two then. By: Leif Madsen (lmadsen) 2009-11-17 07:51:14.000-0600 Thanks! By: Kirill Katsnelson (kkm) 2009-11-27 16:08:58.000-0600 Please do not close the ticket if possible. I have been busy and unable to get to that yet, but I am hoping to send in a patch really really soon. I did not abandon it, that is! By: Kirill Katsnelson (kkm) 2009-11-29 08:49:32.000-0600 Just uploaded a patch against current trunk. Yes, there are significant differences in code: documentation has been moved to XML chunk in commentary, and a function call to destroy iterator is now required. It is good that it did not apply as is, as that would probably cause a leak of iterators. This probably means also that the patches that I submitted over last months are probably stale now -- and they are nowhere in sight from the front of the queue, or however they are sorted. They are "ready for testing" for months. That, in turn, likely indicates that this is not the right way to submit code changes, even if serious bug fixes, as it takes too long for them to be any useful. Should I rather directly communicate with module maintainers (again, I am only assuming that there are module maintainers)? I am not actively developing asterisk, just running servers, and fixing bugs and annoyances as they arise. I thought it would be a win-win if I send the patches in: less patch maintenance for me, less bugs for you; but -- in the end, that was only my unfounded assumption. Should I really even try to send in fixes? Is that really going to help anyone out there? By: Leif Madsen (lmadsen) 2009-12-01 13:17:16.000-0600 Well the thing is this isn't a "bug" so much as a feature, which you've very nicely provided us a patch for. However, this won't make it into an existing release, but rather would be put into Asterisk trunk, and then would be available in the next branching from trunk (slated to be Asterisk 1.8). By: Digium Subversion (svnbot) 2009-12-23 13:14:06.000-0600 Repository: asterisk Revision: 236308 U   trunk/apps/app_queue.c ------------------------------------------------------------------------ r236308 | dvossel | 2009-12-23 13:14:06 -0600 (Wed, 23 Dec 2009) | 17 lines QUEUE_MEMBER(..., ready) counts only ready agents, not free agents wrapping up The QUEUE_MEMBER dialplan function can return total members, logged-in members and "free" members count. A member is counted as "free" immediately after his call ends, even though its wrap-up time, if specified in queues.conf, has not yet expired, and the queue will not actually route a call to it. This Patch introduces a new "ready" option that only counts free agents no longer in the wrap up time period. (closes issue ASTERISK-15133) Reported by: kkm Patches:      appqueue-memberfun-readyoption-trunk.diff uploaded by kkm (license 888) Tested by: kkm ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=236308 By: Digium Subversion (svnbot) 2009-12-23 13:14:32.000-0600 Repository: asterisk Revision: 236309 _U  branches/1.6.2/ ------------------------------------------------------------------------ r236309 | dvossel | 2009-12-23 13:14:32 -0600 (Wed, 23 Dec 2009) | 23 lines Blocked revisions 236308 via svnmerge ........  r236308 | dvossel | 2009-12-23 13:14:05 -0600 (Wed, 23 Dec 2009) | 17 lines    QUEUE_MEMBER(..., ready) counts only ready agents, not free agents wrapping up    The QUEUE_MEMBER dialplan function can return total members,  logged-in members and "free" members count. A member is counted  as "free" immediately after his call ends, even though its wrap-up  time, if specified in queues.conf, has not yet expired, and the  queue will not actually route a call to it.    This Patch introduces a new "ready" option that only counts  free agents no longer in the wrap up time period.    (closes issue ASTERISK-15133)  Reported by: kkm  Patches:        appqueue-memberfun-readyoption-trunk.diff uploaded by kkm (license 888)  Tested by: kkm ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=236309 By: Digium Subversion (svnbot) 2009-12-23 13:19:40.000-0600 Repository: asterisk Revision: 236308 U   trunk/apps/app_queue.c ------------------------------------------------------------------------ r236308 | dvossel | 2009-12-23 13:14:05 -0600 (Wed, 23 Dec 2009) | 17 lines QUEUE_MEMBER(..., ready) counts only ready agents, not free agents wrapping up The QUEUE_MEMBER dialplan function can return total members, logged-in members and "free" members count. A member is counted as "free" immediately after his call ends, even though its wrap-up time, if specified in queues.conf, has not yet expired, and the queue will not actually route a call to it. This Patch introduces a new "ready" option that only counts free agents no longer in the wrap up time period. (closes issue ASTERISK-15133) Reported by: kkm Patches:      appqueue-memberfun-readyoption-trunk.diff uploaded by kkm (license 888) Tested by: kkm, dvossel ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=236308