Summary:	ASTERISK-17986: Config inheritance doesn't work with ConfBridge() menu definitions
Reporter:	Russell Bryant (russell)	Labels:
Date Opened:	2011-06-08 20:09:27	Date Closed:	2011-06-14 10:30:27
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_confbridge
Versions:	10	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	The code that handles parsing menus doesn't check to see if a particular key sequence was already defined.  It should, and if so, overwrite the previous entry.  The current behavior makes it so you can't set up a set of menus like the following.  In this case, the wrong prompt will get played for an admin when they press '*'. {code} [base_user_menu] type = menu *  = playback_and_continue(conf-usermenu) *1 = toggle_mute 1  = toggle_mute *4 = decrease_listening_volume 4  = decrease_listening_volume *6 = increase_listening_volume 6  = increase_listening_volume *7 = decrease_talking_volume 7  = decrease_talking_volume *8 = no_op 8  = no_op *9 = increase_talking_volume 9  = increase_talking_volume [admin_menu](base_user_menu) *  = playback_and_continue(conf-adminmenu) *2 = admin_toggle_conference_lock 2  = admin_toggle_conference_lock *3 = admin_kick_last 3  = admin_kick_last {code}
Comments:	By: David Woolley (davidw) 2011-06-09 08:47:38.333-0500 This looks like it is something to do with a GUI, not Asterisk itself, however Asterisk itself doesn't guarantee inheritance like behaviour, and as the result of a previous issue, some examples were actually changed to remove any implication that it did. There are two strategies used by Asterisk for picking parameters, and they vary from place to place.  The first is scan the internal list of settings, and look each keyword up in a switch in the code.  This provides, last definition wins, inheritance like behaviour. The other strategy is to run through the list of possible options and look them up in the internal list created from the configuration file.  This results in first definition wins behviour. By: David Woolley (davidw) 2011-06-09 08:55:22.296-0500 The issues I was referring to above is #16855 By: Russell Bryant (russell) 2011-06-09 17:24:54.047-0500 In most cases I would consider "first definition wins" to be a bug.  There must be a very specific reason why that can't be supported for an option and if so, clearly documented.  Otherwise, it should be safe to assume that last definition will be what is set (for reasons like this issue). By: David Woolley (davidw) 2011-06-13 07:30:02.108-0500 app_queue does this, without any obvious explanation text for: [general] persistentmembers autofill monitor-type updatecdr shared-lastcall [<queue>] strategy - this is explained in the source code BUT NOT in queues.conf.sample Also tlighman rejected #15410 ( https://issues.asterisk.org/jira/browse/15410 ) on the grounds that: "you seem to be under the mistaken assumption that because we provide templates, we also provide a method of overriding those templates. This is not the case. Each template is treated as if it were substituted initially within the specified context, and hence, overriding may or may not occur. Especially with the "has*" type options, we provide no such assurance." By: Kinsey Moore (kmoore) 2011-06-13 14:56:11.266-0500 Review for adopting menu inheritance here: https://reviewboard.asterisk.org/r/1267/