hide queue in web interface
hi to all.... i have this problem.... segregate customers to particolare queues... now i see that is impossible in the same istance.... but, it's possible, in the config.pm, the possibility to HIDE the queue in function of the login... for example... the user CUSTOMER1 logged in with active direcotry MYDOMAIN, have to see only in the web interface the queue1 and queue3....
You can't do it per ldap, but you can do it via ACL for something that ldap
knows.
For instance, let's say you have UserLogin mapped to userPrincipalName
instead of sAMAccountName (highly recommended if you are expecting
collisions between usernames accross the different backends).
userPrincipalName would be username@login-domain
Include userPrincipalName where you see: CustomerKey => 'sAMAccountName',
and in the map
'UserLogin', 'Username', 'userPrincipalName'
Then you can employ an ACL in Config.pm like this:
$Self->{TicketAcl}->{'Unique-Descriptive-Name-for-ldap1'} = {
Properties => {
CustomerUser => {
UserLogin => ['[RegExp]login-domain$'],
},
},
Possible => {
Ticket => {
Queue => ['Queue1', 'Queue2'],
},
},
};
http://doc.otrs.org/3.1/en/html/ch18s03.html
(This is not tested. It should work according to documentation, but may
have a syntax error.)
Use at your own risk. Changing the sAMAccountName to userPrincipalName
could make old tickets for a given username inaccessible unless you use
Generic Agent to mass update: find old tickets with username x set
username= x@domain. Of course, if you've already had username collisions,
this would be a problem.
Regards,
Gerald
On Mon, Jul 16, 2012 at 4:05 AM, Stefano Ricci wrote: hi to all.... i have this problem.... segregate customers to particolare
queues... now i see that is impossible in the same istance.... but, it's possible,
in the config.pm, the possibility to HIDE the queue in function of the
login... for example... the user CUSTOMER1 logged in with active direcotry
MYDOMAIN, have to see only in the web interface the queue1 and queue3.... ---------------------------------------------------------------------
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
thanks a lot for the help.... now i i cover this point of my list...
On 16 July 2012 13:13, Gerald Young
You can't do it per ldap, but you can do it via ACL for something that ldap knows.
For instance, let's say you have UserLogin mapped to userPrincipalName instead of sAMAccountName (highly recommended if you are expecting collisions between usernames accross the different backends). userPrincipalName would be username@login-domain
Include userPrincipalName where you see: CustomerKey => 'sAMAccountName', and in the map 'UserLogin', 'Username', 'userPrincipalName' Then you can employ an ACL in Config.pm like this:
$Self->{TicketAcl}->{'Unique-Descriptive-Name-for-ldap1'} = { Properties => { CustomerUser => { UserLogin => ['[RegExp]login-domain$'], }, }, Possible => { Ticket => { Queue => ['Queue1', 'Queue2'], }, }, }; http://doc.otrs.org/3.1/en/html/ch18s03.html
(This is not tested. It should work according to documentation, but may have a syntax error.)
Use at your own risk. Changing the sAMAccountName to userPrincipalName could make old tickets for a given username inaccessible unless you use Generic Agent to mass update: find old tickets with username x set username= x@domain. Of course, if you've already had username collisions, this would be a problem.
Regards, Gerald
On Mon, Jul 16, 2012 at 4:05 AM, Stefano Ricci < stefano.ricci@riccimatic.com> wrote:
hi to all.... i have this problem.... segregate customers to particolare queues...
now i see that is impossible in the same istance.... but, it's possible, in the config.pm, the possibility to HIDE the queue in function of the login... for example... the user CUSTOMER1 logged in with active direcotry MYDOMAIN, have to see only in the web interface the queue1 and queue3....
--------------------------------------------------------------------- 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
i find a problem...
now an agent can not move the ticket in a queue filtered by acl...
for example..
in the queue list i set: q1 and q3... the customer can see only these..
the agent that have the permission on q1,q2,q3, can not move the ticket
from q1/q3 to q2...
On 16 July 2012 13:13, Gerald Young
You can't do it per ldap, but you can do it via ACL for something that ldap knows.
For instance, let's say you have UserLogin mapped to userPrincipalName instead of sAMAccountName (highly recommended if you are expecting collisions between usernames accross the different backends). userPrincipalName would be username@login-domain
Include userPrincipalName where you see: CustomerKey => 'sAMAccountName', and in the map 'UserLogin', 'Username', 'userPrincipalName' Then you can employ an ACL in Config.pm like this:
$Self->{TicketAcl}->{'Unique-Descriptive-Name-for-ldap1'} = { Properties => { CustomerUser => { UserLogin => ['[RegExp]login-domain$'], }, }, Possible => { Ticket => { Queue => ['Queue1', 'Queue2'], }, }, }; http://doc.otrs.org/3.1/en/html/ch18s03.html
(This is not tested. It should work according to documentation, but may have a syntax error.)
Use at your own risk. Changing the sAMAccountName to userPrincipalName could make old tickets for a given username inaccessible unless you use Generic Agent to mass update: find old tickets with username x set username= x@domain. Of course, if you've already had username collisions, this would be a problem.
Regards, Gerald
On Mon, Jul 16, 2012 at 4:05 AM, Stefano Ricci < stefano.ricci@riccimatic.com> wrote:
hi to all.... i have this problem.... segregate customers to particolare queues...
now i see that is impossible in the same istance.... but, it's possible, in the config.pm, the possibility to HIDE the queue in function of the login... for example... the user CUSTOMER1 logged in with active direcotry MYDOMAIN, have to see only in the web interface the queue1 and queue3....
--------------------------------------------------------------------- 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
I don't know if this is good or bad. Obviously, it's not what you want, but
one line of thinking is that the ACL restricts the only queues that the
Customer can be moved to. Given that, you could give q2 as a Possible
option but restrict it from displaying by customer group nonmembership (for
instance, agent escalation).
On Wed, Jul 18, 2012 at 5:41 AM, Stefano Ricci wrote: i find a problem...
now an agent can not move the ticket in a queue filtered by acl... for example.. in the queue list i set: q1 and q3... the customer can see only these.. the agent that have the permission on q1,q2,q3, can not move the ticket
from q1/q3 to q2... On 16 July 2012 13:13, Gerald Young You can't do it per ldap, but you can do it via ACL for something that
ldap knows. For instance, let's say you have UserLogin mapped to userPrincipalName
instead of sAMAccountName (highly recommended if you are expecting
collisions between usernames accross the different backends).
userPrincipalName would be username@login-domain Include userPrincipalName where you see: CustomerKey =>
'sAMAccountName',
and in the map
'UserLogin', 'Username', 'userPrincipalName'
Then you can employ an ACL in Config.pm like this: $Self->{TicketAcl}->{'Unique-Descriptive-Name-for-ldap1'} = {
Properties => {
CustomerUser => {
UserLogin => ['[RegExp]login-domain$'],
},
},
Possible => {
Ticket => {
Queue => ['Queue1', 'Queue2'],
},
},
};
http://doc.otrs.org/3.1/en/html/ch18s03.html (This is not tested. It should work according to documentation, but may
have a syntax error.) Use at your own risk. Changing the sAMAccountName to userPrincipalName
could make old tickets for a given username inaccessible unless you use
Generic Agent to mass update: find old tickets with username x set
username= x@domain. Of course, if you've already had username
collisions, this would be a problem. Regards,
Gerald On Mon, Jul 16, 2012 at 4:05 AM, Stefano Ricci <
stefano.ricci@riccimatic.com> wrote: hi to all.... i have this problem.... segregate customers to particolare
queues... now i see that is impossible in the same istance.... but, it's possible,
in the config.pm, the possibility to HIDE the queue in function of the
login... for example... the user CUSTOMER1 logged in with active direcotry
MYDOMAIN, have to see only in the web interface the queue1 and queue3.... ---------------------------------------------------------------------
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
participants (2)
-
Gerald Young -
Stefano Ricci