optional override of aa incoming settings

Logged In: YES 
user_id=1174590

This would be possible if the AA override was stored in the
asterisk DB as opposed to a global in the header.

We need a way to modify the DB to do this -- either by
accessing the berkeley db file (version 1 -- in PHP, this is
depreciated and requires additional libraries, and is known
not to work in all platforms), or by using the asterisk
manager api. I'm not sure how to use the API, I didn't get
anywhere with my (limited) testing.

I would say the API method is better, if anyone wants to
implement this. Basically we need a function setAAOverride()
and getAAOverride() or even a more general
getAsteriskDB($key) and setAsteriskDB($key, $value).

Logged In: YES 
user_id=1223657

It could also be an agi script, one similar to GotoIF
application...

exten => s,1,AGI(gotoifset|AAOverride|2|3)
exten => s,2,Goto(where you want) ; AA disabled in DB
exten => s,3,Goto(aa context)        ; AA enabled (or not
disabled)

Logged In: YES 
user_id=1223657

ok, forget the last message... need some sleep

Logged In: YES 
user_id=1174590

I have some php code working that can talk to the asterisk
manager GUI and get/set database variables. Expect this
implemented within the next week or so

I think this would now be classified as a 'user switch' destination. Users can dial a feature code and toggle a switch - or multiple paths? A switch would be the least confusing for a user, but there's nothing to stop multiple destinations. I like this one, now that we're at a stage where we can do snazzy things like this. I call 2.2!

Agreed,

Rob, let's not jump the gun on this. We should really architect this type of functionality and it is right up there with other things that I and others have suggested that should be able to do in a portal.

We want to get where all users can use a portal to change things like like call forward (similar to ARI), follow-me settings, personal ring options, etc. Once architected, these can be done in a portal accessed either by web, or if implemented by ivr.

The same portal can handle something like this. A user can be given access to administrative, system wide settings like the example mentioned in this request. Depending on their authority, they would be able to make such changes.

Once architected, you can also make point solutions that access the same mechanism.

The key here is - let's think through and have a design for the whole picture so we don't end up just implementing these things and then have a bunch of inconsistency.

Superseeded by #958

Milestone 2.2 deleted