| Summary: | ASTERISK-18928: Implicit Assumption About Dynamic Features | ||||
| Reporter: | JoshE (n8ideas) | Labels: | |||
| Date Opened: | 2011-11-27 20:30:19.000-0600 | Date Closed: | 2011-12-20 09:04:34.000-0600 | ||
| Priority: | Minor | Regression? | |||
| Status: | Closed/Complete | Components: | Features | ||
| Versions: | 1.8.7.1 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | There appears to have been made an undocumented implicit assumption about the use of dynamic features / application maps. In order for the feature to actually be executed, it is assumed that the "#" or "*" key precedes it. However, it is legal to create the following application map: suppressone => 1,peer,Playback,en/silence/1 suppresstwo => 2,peer,Playback,en/silence/1 suppressthree => *33,peer,Playback,tt-monkeys testfeature => #9,peer,Playback,tt-monkeys Reload features and you'll see the output from 'features show': Dynamic Feature Default Current --------------- ------- ------- testfeature no def #9 suppressthree no def *33 suppresstwo no def 2 suppressone no def 1 However, in this setup, the only features that will actually be executed are the feature #9 and *33. The other features will all be ignored. There is nothing in the documentation which would suggest that it isn't OK to have a dynamic feature that doesn't begin with # or *. At a minimum, the documentation should probably be clarified... but I would actually have a use for the ability to use dynamic features that don't begin with the # or * keys. | ||||
| Comments: | By: Leif Madsen (lmadsen) 2011-11-29 14:14:07.784-0600 Briefly looking through the code I don't see anything implicitly making the use of a preceding * or # necessary. I don't believe this just to be a documentation issue. I'm not sure the intention is to require those characters. By: Leif Madsen (lmadsen) 2011-12-01 15:45:02.398-0600 I'm unable to reproduce this. It works fine on my system. Here is what I defined in features.conf: {code} allyourbase => 5,peer/both,Playback,all-your-base {code} And my dialplan, I just added: {code} Set(__DYNAMIC_FEATURES=allyourbase) {code} ...prior to the Dial(). When I received a call, I pressed 5, and it worked fine. By: JoshE (n8ideas) 2011-12-01 15:48:42.951-0600 Let me take another look and see if I can try your exact scenario. I was using the group association method in the applicationmap, as opposed to directly attaching the feature. I'll try it the way you have it and report back ASAP. By: Leif Madsen (lmadsen) 2011-12-20 09:04:25.900-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines | ||||