(closes issue #12238)
authorSteve Murphy <murf@digium.com>
Mon, 17 Mar 2008 17:47:36 +0000 (17:47 +0000)
committerSteve Murphy <murf@digium.com>
Mon, 17 Mar 2008 17:47:36 +0000 (17:47 +0000)
commit0af58d3f5cba858b3549d847fd84cffa62b9a6ec
tree7feaef1754a8d06740e7a037115cb909168e1a7d
parent5729b0ec40f37cf98d9fb06bb5d6c683f4fa6bef
(closes issue #12238)
Reported by: mvanbaak
Tested by: murf, mvanbaak

Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context
that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the
old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the
includes, ignorepats, and switches. I added code to do this immediately after the context is created.

This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also
in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and
therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates
into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely
order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we
merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any
elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully,
this is pretty rare thing.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
include/asterisk/pbx.h
main/pbx.c