Re: [otrs] Queue permission

[Gerald Young]

>
> Unfortunately, that doesn’t work very well if you are offering multiple
> services to each customer. If I read ITIL correctly, services vs customers
> is potentially a many-to-many relationship, eg services are predefined
> “things you offer” to zero or more consumers (note that in a
> highly-composed service-oriented architecture, the “customer” could be
> another service as well as a company), and there may be zero or more
> consumers that have access to a service. This gets particularly nasty if
> you involve a CMDB of managed objects that provide certain services to
> customers – you need to track the consumer to service mapping to calculate
> who is affected by a service failure, and multiple consumers get mapped to
> a single service.


The first part of this I don't follow because certainly you can create
*Services* CustomerAService  or CustomerA::Service1, CustomerA::Service2
Which you can assign to zero or more consumers. And zero or more customers
may have any, all, or none of the Services created.

The second part I don't follow precisely either, because there isn't any
more a default, "everyone in this queue" any more or less to "everyone with
this service" mapping, is there?

Further, if you want a service ACL, that seems just as reasonable as
creating a whole set of queues for a customer, assigning the appropriate
membership for agents, getting the agents to have that additional queue in
their "My Queues" ... versus, essentially, creating an ACL for services
template .pm file that you copy/modify/paste into Kernel/Config/Files and
establishing that the services Possible are [CompanyName]::Services1,
[CompanyName]::Services2 when matching CustomerID.

That ACL already wins all the time for the Customer, period. No additional
work necessary, independently verifiable. Now, if you have an Agent who
mucks around with that, that's a different issue, but now even if the wrong
checkbox is checked, the customer can't see it, because the ACL wins.

Now you can scan the services by search and see essentially the same
information.

Customers don't belong to queues. A queue belongs to a group. Customers
belong to group(s). Services belong to customers.

This isn't even *my* preference, thought, or anything, it's simply how OTRS
is. There's nothing to a Queue that tells you a queue's membership. I could
definitively tell you which users are assigned a service, and with a simple
(really simple) ACL I can tell you which services any customer can see,
even if an agent clicks the wrong one. For a Queue, I have to determine the
membership of the group to which the queue was assigned, and a big list of
queues and associated tickets for the queues that survive even if the
customer doesn't.

By the way, I'm not arguing for the sake of argument. People ask a bunch of
questions how to get queues to act like (customer-assigned) services and
then they'll ask for types to act like queues (how do I assign permissions
to types? How do I stop autoresponse for a given type? How do I assign
agents to a given type?). If it works that way for some people, great, but
it's really easy to get it done the OTRS way and still do what you want
ITIL wise.

Thank you again for your response.

On Wed, Jul 18, 2012 at 3:07 PM, David Boyes  wrote:

> 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. 
>
> ** **
>
> Unfortunately, that doesn’t work very well if you are offering multiple
> services to each customer. If I read ITIL correctly, services vs customers
> is potentially a many-to-many relationship, eg services are predefined
> “things you offer” to zero or more consumers (note that in a
> highly-composed service-oriented architecture, the “customer” could be
> another service as well as a company), and there may be zero or more
> consumers that have access to a service. This gets particularly nasty if
> you involve a CMDB of managed objects that provide certain services to
> customers – you need to track the consumer to service mapping to calculate
> who is affected by a service failure, and multiple consumers get mapped to
> a single service. 
>
> ** **
>
> 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).
>
> ** **
>
> Yup. And that is exactly what bites you in

Re: [otrs] Queue permission

[David Boyes]

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.

Unfortunately, that doesn't work very well if you are offering multiple 
services to each customer. If I read ITIL correctly, services vs customers is 
potentially a many-to-many relationship, eg services are predefined "things you 
offer" to zero or more consumers (note that in a highly-composed 
service-oriented architecture, the "customer" could be another service as well 
as a company), and there may be zero or more consumers that have access to a 
service. This gets particularly nasty if you involve a CMDB of managed objects 
that provide certain services to customers - you need to track the consumer to 
service mapping to calculate who is affected by a service failure, and multiple 
consumers get mapped to a single service.

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

Yup. And that is exactly what bites you in the ass without ACLs that permit 
independent auditing. Having customer A see only one queue (or a small set of 
queues) and having agents scan the customer-dedicated queues for specific 
services (easy to do with a predefined query) they're trained for (or you can 
also pull those skills from a CMDB entry for a "Person"). It'd be a very nice 
option to have OTRS support such a multidimensional security model out of the 
box, but that's a lot of work for them for a fairly small community of users.
-
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

Re: [otrs] Queue permission

[Stefano Ricci]

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::Ticket::ViewNew
>>
>>
>> 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
>>> 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.
>>
>> -
>> 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
>
-
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

Re: [otrs] Queue permission

[Carlos Ribas]

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::Ticket::ViewNew
>
>
> 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
>> 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.
>
> -
> 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

Re: [otrs] Queue permission

[Gerald Young]

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-boun...@otrs.org [mailto:otrs-boun...@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 m

Re: [otrs] Queue permission

[David Boyes]

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-boun...@otrs.org [mailto:otrs-boun...@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

Re: [otrs] Queue permission

[Gerald Young]

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

Re: [otrs] Queue permission

[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::Ticket::ViewNew


Mit freundlichen Grüßen

Stephan Lang

Am 11.07.2012 um 21:42 schrieb "Carlos Ribas" 
mailto:car...@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:u...@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.
-
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

Re: [otrs] Queue permission

[Carlos Ribas]

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
> alv...@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
>
-
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

Re: [otrs] Queue permission

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

Re: [otrs] Queue permission

[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
alv...@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

Re: [otrs] Queue permission

[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
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

[otrs] Queue permission

[Carlos Ribas]

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