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

[Eric "ManxPower" Wieling]

Why not allow group= or make group 0 mean "no group".

What I do is set channels that I don't want in a group to be group 0 and 
never use g0 anywhere

Nic Bellamy wrote:
> 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.
>