Queue permission

older
drop down menu is not available...

Carlos Ribas

11 Jul 2012 11 Jul '12

7:03 p.m.

Hello All, I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me. I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one. Best regards, --------------------------------- Carlos Eduardo Ribas

Attachments:

attachment.html (text/html — 698 bytes)

Show replies by date

Ugo Bellavance

11 Jul 11 Jul

7:28 p.m.

On 2012-07-11 15:03, Carlos Ribas wrote:

...

Hello All,

I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me.

I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one.

I don't think OTRS is made to make queues available to clients. The clients can see their ticket via a web interface, but not all the queue.

Carlos Ribas

7:40 p.m.

But a customer can open a ticket and when he does it, he can choose a queue (if there are a lot of them). 2012/7/11 Ugo Bellavance

...

On 2012-07-11 15:03, Carlos Ribas wrote:

...
Hello All,

I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me.

I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one.

I don't think OTRS is made to make queues available to clients. The clients can see their ticket via a web interface, but not all the queue.

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

Stephan Lang

7:52 p.m.

Hi you can limit the queues visible when creating a ticket in web interface Config-Setting: $Self->{'CustomerPanelOwnSelection'} = { 'Junk' => 'First Queue', 'Misc' => 'Second Queue' }; http://doc.otrs.org/3.1/en/html/Ticket.html#Ticket:Frontend::Customer::Ticke... Mit freundlichen Grüßen Stephan Lang Am 11.07.2012 um 21:42 schrieb "Carlos Ribas" mailto:carlos@ansp.br>: But a customer can open a ticket and when he does it, he can choose a queue (if there are a lot of them). 2012/7/11 Ugo Bellavance mailto:ugob@lubik.ca> On 2012-07-11 15:03, Carlos Ribas wrote: Hello All, I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me. I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one. I don't think OTRS is made to make queues available to clients. The clients can see their ticket via a web interface, but not all the queue. --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 ------------------------------------------------------------------------ Bock 1 GmbH & Co. KG An der Heide 17 92353 Postbauer-Heng Sitz: Postbauer-Heng Amtsgericht Nürnberg, HRA 11 240 pers. haft. Geschäftsführer: Hermann Bock Bock 1 Verwaltungs GmbH Sitz: Postbauer-Heng Amtsgericht Nürnberg, HRB 93 10 Geschäftsführer: Harald Meyer, Andreas Großhauser Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.

Gerald Young

8:05 p.m.

I know that people keep asking this type of question ... why do you want a customer based queue? Last conversation I had was inconclusive. Basically, the person wanted it because they wanted it. What's the point in segregating queues from (between) customers? (yes, you *can* do it, but *why* do you *want* to do it?) Now, I can understand why you might want to put a ticket in a queue that's handled by agents that customers can't access (tier2, for instance) but as much headache as I see managing what queues are available for *this* group of customers versus *that* group of customers, especially in terms of large numbers of customers, why bother? "I don't want this customer to see that customer's queues!" is ... well, why do you say that? The customers can't see each others' tickets anyway. (I'm not saying it's wrong, I'm just trying to figure out the reason.)

David Boyes

9:33 p.m.

Yes, you can't see other customer's tickets in the default setup, but there's more to it than that. Here's why customer-based queue lists are important to us: The reasoning from the powers that be here is that customers should see only the services they are entitled to, and nothing more --in many cases we're contractually obligated to not identify customers to each other, not to use or expose the customer's name in any way, and to deny all knowledge of customer B if customer A asks - consider the case where A and B are direct competitors. If you're serving both A and B, you need to be able to prove to both A and B that information can't (and won't) leak between the two, especially if the queues handle potentially confidential or sensitive information that could represent an advantage to one or the other. We have customers where that could potentially mean billions one way or the other. If you have customer based queues (or better yet, queue sets), the ACLs can be much simpler (customers are restricted to their own queue or a clearly auditable set of queues) and get the experience of being our "only" customer from their perspective. You could probably do this with service-based queues and some fancy ACL handwaving, but the extra step of adding a specific set of queues to a specific customer id adds an additional dimension to the security model that makes it a lot easier to *prove* that information can't leak. And yes, it is a total PITA. But, you can look the security guys in the eye and say "A cannot access data from B" and be able to concretely prove it with data to back it up. The customer-based queue approach is also conceptually a bit easier to templatize - get a new customer, create the following queues, set the ACLs so, and the agents know what process doc to refer to based on customer name and/or queue name. It you're doing strict ITSM, the service-based approach is probably technically more correct, but it's hard for business heads and clerks to think that way. customerA-service1, customerA-service2 are easy for them to grok immediately, and having your agents concentrate on the "-service1, -service2" parts is a fairly easy adaptation. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Gerald Young Sent: Wednesday, July 11, 2012 4:05 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] Queue permission I know that people keep asking this type of question ... why do you want a customer based queue? Last conversation I had was inconclusive. Basically, the person wanted it because they wanted it. What's the point in segregating queues from (between) customers? (yes, you *can* do it, but *why* do you *want* to do it?) Now, I can understand why you might want to put a ticket in a queue that's handled by agents that customers can't access (tier2, for instance) but as much headache as I see managing what queues are available for *this* group of customers versus *that* group of customers, especially in terms of large numbers of customers, why bother? "I don't want this customer to see that customer's queues!" is ... well, why do you say that? The customers can't see each others' tickets anyway. (I'm not saying it's wrong, I'm just trying to figure out the reason.)

Gerald Young

10:25 p.m.

I thank you for the insight, and in my limited view, I'm thinking of "Services" to handle the segregation as -- I'd hope -- only the assigned services would be available to the customer, meanwhile the queue would be the type of thing your agents would generically provide. The Service is unique to a customer, and does everything else mentioned here, without need for ACL. At least, that's what I understand. Every plan is different, to be sure, but thinking in terms of what you present here, it seems reasonable that the only change you'd need to do to add a new customer would be to add a specific service and attach it to the customer. Now those pesky checkboxes are the thing to bite you in the rear... (No, I'm not making fun, I'm serious. It's not extremely obvious that you haven't assigned a service to the competitor). Anyway, I appreciate the feedback. It will help me to consider different views. Regards. On Wed, Jul 11, 2012 at 5:33 PM, David Boyes wrote:

...

Yes, you can’t see other customer’s tickets in the default setup, but there’s more to it than that. Here’s why customer-based queue lists are important to us:****

** **

The reasoning from the powers that be here is that customers should see only the services they are entitled to, and nothing more --in many cases we’re contractually obligated to not identify customers to each other, not to use or expose the customer’s name in any way, and to deny all knowledge of customer B if customer A asks – consider the case where A and B are direct competitors. If you’re serving both A and B, you need to be able to prove to both A and B that information can’t (and won’t) leak between the two, especially if the queues handle potentially confidential or sensitive information that could represent an advantage to one or the other. We have customers where that could potentially mean billions one way or the other. ****

** **

If you have customer based queues (or better yet, queue sets), the ACLs can be much simpler (customers are restricted to their own queue or a clearly auditable set of queues) and get the experience of being our “only” customer from their perspective. ****

** **

You could probably do this with service-based queues and some fancy ACL handwaving, but the extra step of adding a specific set of queues to a specific customer id adds an additional dimension to the security model that makes it a lot easier to **prove** that information can’t leak. And yes, it is a total PITA. But, you can look the security guys in the eye and say “A cannot access data from B” and be able to concretely prove it with data to back it up. ****

** **

The customer-based queue approach is also conceptually a bit easier to templatize – get a new customer, create the following queues, set the ACLs so, and the agents know what process doc to refer to based on customer name and/or queue name. It you’re doing strict ITSM, the service-based approach is probably technically more correct, but it’s hard for business heads and clerks to think that way. customerA-service1, customerA-service2 are easy for them to grok immediately, and having your agents concentrate on the “-service1, -service2” parts is a fairly easy adaptation. ****

** **

** **

** **

*From:* otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] *On Behalf Of *Gerald Young *Sent:* Wednesday, July 11, 2012 4:05 PM *To:* User questions and discussions about OTRS. *Subject:* Re: [otrs] Queue permission****

** **

I know that people keep asking this type of question ... why do you want a customer based queue? Last conversation I had was inconclusive. Basically, the person wanted it because they wanted it. ****

** **

What's the point in segregating queues from (between) customers? (yes, you *can* do it, but *why* do you *want* to do it?) ****

Now, I can understand why you might want to put a ticket in a queue that's handled by agents that customers can't access (tier2, for instance) but as much headache as I see managing what queues are available for *this* group of customers versus *that* group of customers, especially in terms of large numbers of customers, why bother? ****

** **

"I don't want this customer to see that customer's queues!" is ... well, why do you say that? The customers can't see each others' tickets anyway.* ***

** **

(I'm not saying it's wrong, I'm just trying to figure out the reason.)****

--------------------------------------------------------------------- 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

Carlos Ribas

12 Jul 12 Jul

12:08 p.m.

Hello Stephan, This trick is what I was looking for! Thank you. Best regards, --------------------------------- Carlos Eduardo Ribas 2012/7/11 Stephan Lang

...

Hi

you can limit the queues visible when creating a ticket in web interface

Config-Setting:

$Self->{'CustomerPanelOwnSelection'} = {

'Junk' => 'First Queue',

'Misc' => 'Second Queue'

};

http://doc.otrs.org/3.1/en/html/Ticket.html#Ticket:Frontend::Customer::Ticke...

Mit freundlichen Grüßen

Stephan Lang

Am 11.07.2012 um 21:42 schrieb "Carlos Ribas" :

But a customer can open a ticket and when he does it, he can choose a queue (if there are a lot of them).

2012/7/11 Ugo Bellavance

...
On 2012-07-11 15:03, Carlos Ribas wrote:

...
Hello All,

I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me.

I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one.

I don't think OTRS is made to make queues available to clients. The clients can see their ticket via a web interface, but not all the queue.

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

--------------------------------------------------------------------- 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

------------------------------------------------------------------------ Bock 1 GmbH & Co. KG An der Heide 17 92353 Postbauer-Heng

Sitz: Postbauer-Heng Amtsgericht Nürnberg, HRA 11 240 pers. haft. Geschäftsführer: Hermann Bock Bock 1 Verwaltungs GmbH Sitz: Postbauer-Heng Amtsgericht Nürnberg, HRB 93 10 Geschäftsführer: Harald Meyer, Andreas Großhauser

Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.

--------------------------------------------------------------------- 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

Stefano Ricci

13 Jul 13 Jul

12:34 p.m.

it's possible do the same thing in the kernel/config.pm? On 12 July 2012 14:08, Carlos Ribas wrote:

...

Hello Stephan,

This trick is what I was looking for! Thank you.

Best regards,

--------------------------------- Carlos Eduardo Ribas

2012/7/11 Stephan Lang

...
Hi

you can limit the queues visible when creating a ticket in web interface

Config-Setting:

$Self->{'CustomerPanelOwnSelection'} = {

'Junk' => 'First Queue',

'Misc' => 'Second Queue'

};

http://doc.otrs.org/3.1/en/html/Ticket.html#Ticket:Frontend::Customer::Ticke...

Mit freundlichen Grüßen

Stephan Lang

Am 11.07.2012 um 21:42 schrieb "Carlos Ribas" :

But a customer can open a ticket and when he does it, he can choose a queue (if there are a lot of them).

2012/7/11 Ugo Bellavance

...
On 2012-07-11 15:03, Carlos Ribas wrote:

...
Hello All,

I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me.

I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one.

I don't think OTRS is made to make queues available to clients. The clients can see their ticket via a web interface, but not all the queue.

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

--------------------------------------------------------------------- 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

------------------------------------------------------------------------ Bock 1 GmbH & Co. KG An der Heide 17 92353 Postbauer-Heng

Sitz: Postbauer-Heng Amtsgericht Nürnberg, HRA 11 240 pers. haft. Geschäftsführer: Hermann Bock Bock 1 Verwaltungs GmbH Sitz: Postbauer-Heng Amtsgericht Nürnberg, HRB 93 10 Geschäftsführer: Harald Meyer, Andreas Großhauser

Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly forbidden.

--------------------------------------------------------------------- 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

--------------------------------------------------------------------- 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

Alvaro Cordero

11 Jul 11 Jul

7:35 p.m.

Actually you can make groups avaiable to customer, not queues, for that (groups) you can use either customergroupAllwaysGroup or Customer<->Group feature, but eitherway once you enable a group for a customer they can see everything (All queues). Another posibility is to create your own ACLs in Config.pm Regards On Wed, Jul 11, 2012 at 1:03 PM, Carlos Ribas wrote:

...

Hello All,

I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me.

I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one.

Best regards,

--------------------------------- Carlos Eduardo Ribas

--------------------------------------------------------------------- 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

-- ___________________________ Alvaro Cordero Retana Consultor de Tecnologias Gridshield Monitoreo de Redes e Infraestructura. 2258-5757 ext 123 alvaro@gridshield.net www.gridshield.net

Carlos Ribas

7:47 p.m.

Alvaro, Ok. So, to my purpose, I have to have two groups or create my own rule. Thanks, --------------------------------- Carlos Eduardo Ribas 2012/7/11 Alvaro Cordero

...

Actually you can make groups avaiable to customer, not queues, for that (groups) you can use either customergroupAllwaysGroup or Customer<->Group feature, but eitherway once you enable a group for a customer they can see everything (All queues).

Another posibility is to create your own ACLs in Config.pm

Regards

On Wed, Jul 11, 2012 at 1:03 PM, Carlos Ribas wrote:

...
Hello All,

I´m new with OTRS. I installed the latest version and now I'm trying to understand how it works. I´m reading the manual page, but one point is not clear to me.

I can set groups, roles and queues. My doubt is if it is possible to have, for example, two queues in the same group, but one queue visible only to customer and both visible to agent. I saw that I can have this configuration using two groups, but I would like to know if it is possible to use only one.

Best regards,

--------------------------------- Carlos Eduardo Ribas

--------------------------------------------------------------------- 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

-- ___________________________ Alvaro Cordero Retana Consultor de Tecnologias Gridshield Monitoreo de Redes e Infraestructura. 2258-5757 ext 123 alvaro@gridshield.net www.gridshield.net --------------------------------------------------------------------- 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

4753

Age (days ago)

4755

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Alvaro Cordero
Carlos Ribas
David Boyes
Gerald Young
Stefano Ricci
Stephan Lang
Ugo Bellavance