[asterisk-dev] Clearing pick-up groups on Zap/ channels

[Nic Bellamy]

Olle E Johansson wrote:

>
> 5 nov 2006 kl. 16.43 skrev Gil Kloepfer:
>
>> I've discovered that in configuration files such as the one for
>> chan_zap (where all the options "cascade down" rather than being
>> specific for each category, there is no way to indicate that
>> channels have no pick-up group after the first group has been
>> set.  For example (simplified), in zapata.conf:
>>
>>   [channels]
>>   ; These two phones are in call group/pick-up group #1
>>   callerid="Green Phone"<(256) 428-6121>
>>   callgroup=1
>>   pickupgroup=1
>>   channel => 1
>>   callerid="Black Phone"<(256) 428-6122>
>>   channel => 2
>>
>>   ; These three channels should not be in ANY pick-up groups, but  there
>>   ; is no way to clear the previous settings
>>   callerid="CallerID Phone" <(256) 428-6123>
>>   channel => 3
>>   callerid="CallerID Phone" <(256) 704-4666>
>>   channel => 4
>>   callerid="CallerID Phone" <(630) 372-1564>
>>   channel => 5
>>
>> In the case of channels 3, 4, and 5, there is no valid way to  "clear 
>> out"
>> the "current" callgroup / pickupgroup without encountering an error
>> (you could say pickupgroup=none, but that actually throws an error
>> from ast_get_group(), although it happens to work).
>>
>> I'd like to propose making a change to ast_get_group() to allow
>> the option "none" that returns a ast_group_t containing no groups set,
>> basically zero.  So you could say 'callgroup=none' for example.
>>
>> Note that callgroup=0 would not do what I am suggesting because 0 is
>> a valid group number.  The group/callgroup/pickupgroup is actually a
>> bit mask (bits numbered 0 to 63).
>>
>> If this seems reasonable, please indicate so and I will submit a patch
>> for both 1.2 and -trunk (they are essentially the same patch).
>
> Sounds very reasonable. Whether we can see this as a bug or a new
> feature is up to Russell to decide. If it's a bug fix, which I think,  
> we need
> patches for the 1.2 and 1.4 branches plus trunk. Please open an issue
> in the bug tracker, upload patches and we'll discuss there.

I've been trying to think of an easy, minimal-change way out of the 
zapata.conf inheritence problem (since it's not just pickupgroups that 
have this behaviour, it's just worse with that since you can't reset it 
at present).

What about something simple like a "resetdefaults" item that will 
restore all zapata.conf settings to hardcoded defaults, and clear out 
the pickupgroup/callgroup stuff?

Ie.

    pickupgroup=1
    callgroup=1
    channel => 1-3

    resetdefaults=yes ; likely need the =yes since it's key=value based

    otherconfig=123
    channel => 4

This wouldn't break any existing configs out there, since it'd only 
happen if you explicitly used resetdefaults.

Thoughts? Or shall I just whip up a patch? :-)

Regards,
    Nic.

-- 
Nic Bellamy,
Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/