Custom Destination - Changes not updated to dial plan

Well I think it kind of works but is also kind of a bit confusing. I will add a call to force the reload bar when editing it. However, if you change the actual destination on an entry that is actually being used, it will not change the destination in the modules that are using it. They will suddenly become unknown destinations. Its a result of the way destinations are stored in each module today.

One thought though - I could make the "Custom Destination" field read only any time it is being used by other objects, so that you can't accidentally change it. You could still delete it. The description and notes fields would still be editable.

Let me know if that seems like a good solution/compromise, in which case I'll not do the reload bar after editing since there is no reason to do a reload as nothing about the description or note field effects the generated dialplan.

The way I expected it to work was pretty much like all the other modules.

That is to say that I could change the top line, and it would automatically change everything.

for instance, if I had put in "custom-a2billing,{exten},1" and then realise that it did not work properly, and went back in and typed "custom-a2billing,${exten},1" to make it work, I would have expected this to have updated everywhere.

If it appears to work, and appears to be editable, then that may be confusing, as you think you have fixed it, but in reality you have not. Perhaps a better solution, if everything cannot be updated is one of the following: -

1. Make the top field read only once it has been created, so you have to delete it to change it

2. When the field is changed - create another custom destination, and leave the first instance in place, then I know to go and change the other parts of the system.

3. Make it update all the way through.

4. Lastly, put some help in to say that updates will not propogate through, delete and re-create.

Replying to jroper:

The way I expected it to work was pretty much like all the other modules. That is to say that I could change the top line, and it would automatically change everything. for instance, if I had put in "custom-a2billing,{exten},1" and then realise that it did not work properly, and went back in and typed "custom-a2billing,${exten},1" to make it work, I would have expected this to have updated everywhere. If it appears to work, and appears to be editable, then that may be confusing, as you think you have fixed it, but in reality you have not. Perhaps a better solution, if everything cannot be updated is one of the following: - 1. Make the top field read only once it has been created, so you have to delete it to change it 2. When the field is changed - create another custom destination, and leave the first instance in place, then I know to go and change the other parts of the system. 3. Make it update all the way through. 4. Lastly, put some help in to say that updates will not propogate through, delete and re-create.

Joe, making a change here and having it update in all the modules would be a difficult task. It would require creating a new callback that all the modules providing destinations would have to implement to respond to the edit and make the change where they store the destination. Again this is a result of the legacy of what we are currently dealing with on how destinations are distributed.

I will opt for the mode that makes the destination information read-only as soon as it is being used by any module, and then add some appropriate help information. The use and frequency of custom destinations does not justify the time it would take to address the change as described above. It could be entered as a feature request for a future implementation but for now ... I think this will be a good alternative as it at least blocks errors from happening.

I think that your solution is the pragmatic one, and it gets my vote.

Joe

r5719