Hello. I created multiple queues with a group for each. I enabled customers group and specified the customers to be in all groups for queues. If I create another queue with a group, then customers will not have access to this queue until I add each customer to the new group. I know I can add this new group to the autoconfiguration, but if there is much more groups? How to allow all customers automatically access to all groups and therefore to queues without reconfiguring accesses? Disabling customer's group support denies access to any queue for customers. -- Mimiko desu.
Why did you shoot yourself in the foot Ike that?
The only reasonable reason is if you have per agent Queues.
But, you can continue this journey of a thousand paper cuts by using a
Config.pm variable CustomerGroupAlwaysGroups (See Defaults.pm)
On May 10, 2014 2:48 AM, "Mimiko"
Hello.
I created multiple queues with a group for each. I enabled customers group and specified the customers to be in all groups for queues. If I create another queue with a group, then customers will not have access to this queue until I add each customer to the new group. I know I can add this new group to the autoconfiguration, but if there is much more groups? How to allow all customers automatically access to all groups and therefore to queues without reconfiguring accesses? Disabling customer's group support denies access to any queue for customers.
-- 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
On 10.05.2014 14:42, Gerald Young wrote:
The only reasonable reason is if you have per agent Queues.
Every there are different groups of agents which have different access to queues. Isn't it mentioned that in order to achieve this, each queue must belong to its own group?
But, you can continue this journey of a thousand paper cuts by using a Config.pm variable CustomerGroupAlwaysGroups (See Defaults.pm)
I do this. But if there is 100 queues? If I disable CustomerGroup then customers does not have access to any queue. -- Mimiko desu.
Every there are different groups of agents which have different access to queues. Isn't it mentioned that in order to achieve this, each queue must belong to its own group?
I don't know, that's why I asked the question. What are you trying to
accomplish?
Why have 100 queues? That's a mess to manage.
Queues are for [groups of] agent[s] that are able to handle a category of
tasks. If you have legitimately 100 [groups of] agents, 100 queues might
make sense. Why make a customer choose from 100 queues to submit a ticket?
Good names for Queues: Plumbing, Electrical, Software, Hardware, Support
Services are specific things customers have purchased or have been
allocated that need fixing.
Good names for Services: Toilet, Lights, Windows, HotSpot, Email
Don't forget that multiple queues can be members of the same group. If
there's no reason permission-wise to segregate Queue54 from Queue55, then
Queue54 and Queue55 can be both members of the same group. Especially, if
all the customers have access to all the queues, then all the queues that
the customers have access to should be a member of the same single queue of
which all the customers are a member.
all customers are member of "100queuesormore" group.
all 100 queues are a member of "100queuesormore" group.
Again, the *only* (as far as I've been able to tell) reason to make
individual queues with individual per-queue groups is single
agent-based-queues. And the only (in my opinion) good reason to even do
that is because you have customers assigned to specific agents, but not all
of them at once.
On Sat, May 10, 2014 at 11:40 AM, Mimiko
On 10.05.2014 14:42, Gerald Young wrote:
The only reasonable reason is if you have per agent Queues.
Every there are different groups of agents which have different access to queues. Isn't it mentioned that in order to achieve this, each queue must belong to its own group?
But, you can continue this journey of a thousand paper cuts by using a Config.pm variable CustomerGroupAlwaysGroups (See Defaults.pm)
I do this. But if there is 100 queues? If I disable CustomerGroup then customers does not have access to any queue.
-- 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
On 10.05.2014 20:17, Gerald Young wrote:
Good names for Queues: Plumbing, Electrical, Software, Hardware, Support Again, the *only* (as far as I've been able to tell) reason to make individual queues with individual per-queue groups is single agent-based-queues. And the only (in my opinion) good reason to even do that is because you have customers assigned to specific agents, but not all of them at once.
That is. To each queue have access only specific agents, combined by groups. Agent1 and Agent2 are members of Group1 which have access only to tickets in Plumbing queue. Agent3 and Agent4 are members of Group2 which have access only to tickets in Electrical queue. Agent5 and Agent6 are members of Group3 which have access to tickets of both queues, or all, and only to move and/or assign tickets to agents if they do not take them in time. Its obvious that agents related to Software development cannot and must no see tickets designated to HW support team and vice versa. So there will be as much queues with its individual groups needed to divide groups of agents by theirs designation.
Especially, if all the customers have access to all the queues, then all the queues that the customers have access to should be a member of the same single queue of which all the customers are a member.
Yes, this I understand correctly. But I want that, taking in account agents group membership and access, all customers are able to create tickets in all queues. Using service in other hand does not limit (or does?) access for agents to their designated role in company. -- Mimiko desu.
If you have any way to abstract your specific use case into something we can discuss, great. If not, we can continue to talk about things in terms that don't relate to you or or your original question.
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.
Every there are different groups of agents which have different access to queues. Isn't it mentioned that in order to achieve this, each queue must belong to its own group?
No. I've never seen any documentation that relates to that.
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.
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.
On Sat, May 10, 2014 at 1:37 PM, Mimiko
On 10.05.2014 20:17, Gerald Young wrote:
Good names for Queues: Plumbing, Electrical, Software, Hardware, Support Again, the *only* (as far as I've been able to tell) reason to make individual queues with individual per-queue groups is single agent-based-queues. And the only (in my opinion) good reason to even do that is because you have customers assigned to specific agents, but not all of them at once.
That is. To each queue have access only specific agents, combined by groups. Agent1 and Agent2 are members of Group1 which have access only to tickets in Plumbing queue. Agent3 and Agent4 are members of Group2 which have access only to tickets in Electrical queue. Agent5 and Agent6 are members of Group3 which have access to tickets of both queues, or all, and only to move and/or assign tickets to agents if they do not take them in time.
Its obvious that agents related to Software development cannot and must no see tickets designated to HW support team and vice versa. So there will be as much queues with its individual groups needed to divide groups of agents by theirs designation.
Especially, if all the customers have access to all the queues, then all the queues that the customers have access to should be a member of the same single queue of which all the customers are a member.
Yes, this I understand correctly. But I want that, taking in account agents group membership and access, all customers are able to create tickets in all queues.
Using service in other hand does not limit (or does?) access for agents to their designated role in company.
-- 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
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.
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: - make the customer a member of the group -- manually assign or CustomerGroupAlwaysGroups -- or - turn off CustomerGroupSupport 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
reportedhttp://bugs.otrs.org/buglist.cgi?query_format=specific&order=relevance+desc&...relating
to this.
On Sat, May 10, 2014 at 2:20 PM, Mimiko
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
On 10.05.2014 22:42, Gerald Young wrote:
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 http://bugs.otrs.org/buglist.cgi?query_format=specific&order=relevance+desc&... relating to this.
I'm on otrs 3.3.6 from git. Interesting, just tried to set customer group support to No and customers have access to queues, and also they see theirs old tickets. I am sure that a while ago it didn't work so. May be some other options also is involved. -- Mimiko desu.
participants (2)
-
Gerald Young -
Mimiko