Patrick,
I’ll just make a simple word of caution. You can override macro-user-callerid as you indicate, you will want to be very aware of both how Asterisk does overrides since it can result in very difficult to understand bugs if you end up having priorities in your context from both which would happen if our context had more priorties then yours, and that is possible per the next statement.
Other modules can and do hook into macro-user-callerid. It’s also possible that future updates could modify the base context. It doesn’t happen very often because we are very conservative with that context as it is very core to everything, but it does happen. By overriding it, you won’t get new updates. Also, if a new module starts to hook into it, what should be there will change. It could get new priorties added from splices, etc. As such, you need to be very aware of that.
One tick of the trade could be to override just priority 0, have it call a subroutine, do what it’s doing there, do your stuff, and then return since the rest will be supplied from the auto-generated context. Of course if priority 0 was spliced or changed, you’d be afffected. Also, there are a few things the current macro does that you want before you get ot your assignment. So … it makes it a bit tricky.
The language module is an example of a module that splices in a command. You could write a super simple module that does something similar. It wouldn’t need a GUI or anything, just the method that hooks in and then the splice command which would look something like this:
$ext->splice('macro-user-callerid', 's', 'report',new ext_execif('$["${AMPUSER}" = "91"]', 'Set', 'DYNAMIC_FEATURES=${DYNAMIC_FEATURES}#OpenDoor'));
note I appended it to the current DYNAMIC_FEATURES in the avove because I know there will always be a minimum of 1 dyanmic feature defined which is our one touch recording and there could be new ones we add in the future. The splicing at priority ‘report’ just tells it to splice it in just before the report label. You can rest assured that the report label will always be where it is in the logical flow of that macro as that is where other modules we maintain expect it to be. As mentioned, you can see the langauge module to see the basic method that is needed to insert this. You can make a really basic module that is nothing more then a method to do this. The only other thing you might want to do is to get a key to sign your own module (which you have to sign a basic waiver to get a key as we have to sign it), which would keep your system from complaining about your new module not being signed.