> > Damian, I finally found some time to look up the work you had done.
> > Although I haven't tested the functionality yet, I have a couple of
> > comments on the GUI itself:
> >
> > 1- Users do not have a 'Location' setting.
> > 2- The choices that appear in the 'Location' pull-down list of
> > gateways are the configured groups, not locations. I
> thought we had
> > agreed that although they are implemented similarly, groups and
> > locations would be distinct concepts at the user level.
>
> That's intentional (I tried to be very explicit about it in
> my commit comments). My goal was to make sure that we get
> fallbackrules generations correct. I kept the issue open though.
>
> We'll might reintroduce the location concept, but for now the
> UI does provide enough for all the user stories, right?
Probably but some stories lead to confusing configuration. Consider an
Ottawa location where you have a set of designer phones and a set of
guest phones. For such a deployment, one may create two groups:
"designers" and "guests", the first one having many permissions and the
second one have a narrow set of permissions however, the administrator
would like to have phones from either group use the same local gateway.
In order to facilitate such a configuration using the current
"group~=location" paradigm, the admin would have to create a
permission-less group called "Ottawa" as well as the already mentioned
"designers" and "guests" groups. It would have to assign every designer
to groups "Ottawa" and "Designers" in that order and every guest to
groups "Ottawa" and "Guests" in that order. From a management
point-of-view, this is not as straight-forward as it could be and is
error-prone as things will not behave as expected if you put the groups
in the wrong order.
This configuration is much simplified if groups and users can be
assigned locations. All that would be required here would be to set the
locations of "Designers" and "Guests" groups to "Ottawa".
>
> > 3- The 'Location' pull-down list of gateways does not allow
> multiple
> > selections. We need to be able to specify that a gateway serves
> > several locations.
>
> Again intentional: in this case I am not really even sure
> that the concept of multiple 'locations' of a single gateway
> is really needed - and it does complicate configuring and
> understanding of the concept.
> Any good reasons why admin might need
It is conceivable that a given gateway be relied upon to serve more than
one location.
>
>
> > 4- Dialplan rules are missing a checkbox to indicate
> whether the rule
> > is subject to location-based routing or not.
>
> Yes. That's coming.
>
> > 5- For usability, the Gateway list appearing in the
> dialplan rule page
> > should have two extra columns; one enumerating the
> location(s) of the
> > gateway and one to indicate whether or not the gateway is shared.
> >
>
> We are slowly running out of real estate here. But probably
> it does make sense to add at least location.
The goal of the extra columns is to give an administrator to possibility
of figuring out which gateways will get used for each location without
having to probe into each gateway configuration page. Without the
'shared' information, that exercise cannot be done. If we go with a
single column, perhaps we could use a special character ('*' for
example) to denote that it is shared. So for example, it a gateway
serves Ottawa and Montreal and is shared, the column could show:
"Ottawa, Montreal, *".
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
