>can I use ACLs to restrict groups of agents to certain services?
By design of ACL, you can do such a thing. However, the practical use of this question is another matter. As previously stated, services are attached to customers. 

In one frame of reference, you can prevent an agent from choosing a particular service to apply to a ticket. (ok.. but that's probably already part of the ACL assigned to the queue of the ticket, not the agent or the agent's group.) 

In another, you *might* be able to turn off interface options for an agent if the ticket has a certain service. (See the docs).

However, in reality, agents of the group(s) (and therefore, queues) related to, for instance, Software, will probably never see tickets of Service "toilet" because smart application of ACL will ensure that the customer cannot choose that combination on ticket submit, nor could random agent in Software see the ability to assign that Service ... Again, not because of the agent particularly, but because the ACL of the Queue the Agent belongs to already prevents this from happening.

Reworking this to your question *within* the Queue, for instance: Yes. You can do this. For instance, an agent can be a member of "Plumbing" but only provide answers on "toilets". The real question at this point is whether it makes sense to handle this via ACL or create an agent group and [sub]queue (Plumbing::toilets?) specifically for toilets. If you create a group for an agent, and you want customers to submit to Queues belonging to the group, you will need to either: 
The relevant code for the second option is in Kernel/System/CustomerGroup.pm
    # check if customer group feature is active, if not, return all groups
    if ( !$Self->{ConfigObject}->Get('CustomerGroupSupport') ) {

        # get permissions
        %Data = $Self->{GroupObject}->GroupList( Valid => 1 );
        for ( sort keys %Data ) {
            push @Name, $Data{$_};
            push @ID,   $_;
        }
    }

Which, I know, you can argue that it doesn't work that way, because:
>Disabling customer's group support denies access to any queue for customers.

At this point, it's important to know what version of OTRS you're using, because what you reported doesn't seem to comply with the code. (System Log error messages would be helpful, too.)
There are also no bugs reported relating to this.


On Sat, May 10, 2014 at 2:20 PM, Mimiko <vbvbrj@gmail.com> wrote:
On 10.05.2014 20:55, Gerald Young wrote:
 >I created multiple queues with a group for each
why? And, why did you create so many queues? Note that 100 queues means
a customer has 100 choices as the first box he's choosing. This kills
user experience. It's not a nice thing to do to your customer.

I didn't create 100 queues, I just mentioned about that. Of course there will be much less queues in order to have a queue for every groups of agents.


So there will be as much queues with its individual groups needed to
divide groups of agents by theirs designation.
I ... don't know how to translate this into English.

Well, I did an explanation with following (sorry):


 > Its obvious that agents related to Software development cannot and
must no see tickets designated to HW support team and vice versa.
sure. Queues and groups are more related to agents than customers anyway.

Using service in other hand does not limit (or does?) access for agents
to their designated role in company.
Does not. Services are attached to customers. WIth ACL, what a customer
chooses as Queue can affect the choices of service the customer has (of
the services that belongs to the customer.) Likewise, with ACL, if a
customer starts with service, the Queue(s) that are available to the
customer can be restricted.

Hm, can I use ACLs to restrict groups of agents to certain services?


--
Mimiko desu.
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs