Summary:	ASTERISK-20639: Dynamic hints are not properly initialized when the extension contains an underscore.
Reporter:	Steven Wheeler (swheeler)	Labels:
Date Opened:	2012-10-31 12:46:58	Date Closed:	2012-11-12 14:21:21.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/PBX
Versions:	1.8.14.1	Frequency of Occurrence	Constant
Related Issues:	is related to ASTERISK-07563 [patch] Allow a simple lookup for hint extensions
Environment:		Attachments:	( 0) asterisk-20639-dynamic-hint-underscore.diff ( 1) bugreport.txt
Description:	We use dynamic hints with a func_odbc call to load the hints from a database.  However, when the extension contains an underscore the func_odbc call is not evaluated. Our hint context: {code} [blf] exten => _[+A-Za-z0-9*#].,hint,${READ_BLF_PHONE_LIST(${EXTEN})} {code} When we look up the hint for extension johnDoe we get something like: Hint: SIP/phoneA&SIP/phoneB But when we look up the hint for extension john_doe we get: Hint: ${READ_BLF_PHONE_LIST(${EXTEN})} As you can see the variables are not even being evaluated.  If there is any more information you need to debug this please let me know.
Comments:	By: Rusty Newton (rnewton) 2012-11-06 17:34:05.516-0600 I didn't even realize you could use '_' in an extension name...   Your dialplan pattern doesn't appear to account for the '_' character. Let us know how fixing that affects it. Does it behave the same if you make an explicit extension rather than a pattern match for a hint with an underscore in the name (even if you still pull it from the database)? Can you provide a VERBOSE and DEBUG log set to at least 5 captured during the time the hint is being pulled? Can you also provide the READ_BLF_PHONE_LIST() function code so we can better understand what is going on inside there? By: Steven Wheeler (swheeler) 2012-11-07 09:45:22.429-0600 Adding an underscore to the pattern makes no difference.  The pattern only seems to be applied to the first character and the dot matches anything.  Making it an explicitly defined extension in the blf context does not fix the problem either. I will attach the full log for you to check out.  Here are the contents of the func_ODBC call: [BLF_PHONE_LIST] prefix=READ dsn=read readsql=SELECT phone_list FROM Blf_Phonelists WHERE CONCAT(company_id,'-',username)='${SQL_ESC(${ARG1})}' By: Steven Wheeler (swheeler) 2012-11-07 09:47:28.878-0600 The hint lookup is done at line 3589 or timestamp '2012-11-07 09:34:01'.  Let me know if you need any more information. By: Michael L. Young (elguero) 2012-11-07 11:03:27.223-0600 Rusty, I see in the code where it checks if the extension contains an underscore and if it does it will not evaluate the variables and global variables. My question is whether or not that check should be removed or not, or, if it should be only checking that the extension doesn't start with the underscore. By: Michael L. Young (elguero) 2012-11-07 20:03:00.796-0600 Give this patch a try.   Basically, it changes from checking if the extension contains an underscore to checking if the extension starts with an underscore.  If it starts with an underscore, we do not create the hint. By: Steven Wheeler (swheeler) 2012-11-08 09:05:34.727-0600 That patch fixes the issue for me.  What are the odds of getting it in the 1.8 branch?  Also, I would like to note that this isn't a minor bug as it frequently causes queue members to become unavailable and stop receiving calls which really upsets our end users. By: Michael L. Young (elguero) 2012-11-08 17:38:28.389-0600 Steven, I will submit the patch for review and then once it is given the okay, I will get it into the 1.8 branch. The reason why I downgraded the severity to Minor is because there is a workaround; don't name extensions with an underscore in them.  For that reason, I downgraded it. By: Steven Wheeler (swheeler) 2012-11-12 15:49:39.697-0600 Thanks for the quick fix on this.