Summary:ASTERISK-17986: Config inheritance doesn't work with ConfBridge() menu definitions
Reporter:Russell Bryant (russell)Labels:
Date Opened:2011-06-08 20:09:27Date Closed:2011-06-14 10:30:27
Versions:10 Frequency of
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 '*'.

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

*  = playback_and_continue(conf-adminmenu)
*2 = admin_toggle_conference_lock
2  = admin_toggle_conference_lock
*3 = admin_kick_last
3  = admin_kick_last
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:


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/