There's generally no real need to segregate customers into queues, unless
you are preventing a customer from talking to a specific agent, or
customers need to talk to a specific zone/location.
It doesn't matter to OTRS the source of the customer (active directory,
database, external database) .. once authenticated, the customer is a
customer. Customers can't see tickets that don't belong to them.
If you are hosting OTRS so company A with active directory Customers can
only talk to company A with active directory Agents, you may just want to
create a spin-off OTRS just for Company A.
If you are hosting OTRS so Company A, B, and C talk to *your* agents, your
queues should reflect the types of services you provide. The customer just
wants to select the type of thing he wants to have done: Your queues would
be like hardware, software, plumbing, maintenance. And no, Company B won't
know, care, or be aware that he's submitting to the same "hardware" queue
as Company A. Company B will never see tickets from Company A unless
Company A and Company B have Agents in your single OTRS implementation.
You want to know how to segregate them? Best way: create separate OTRS
instances.
It doesn't matter how many backends you use for customers. Customers only
see their own tickets (My tickets) and tickets with the same customer_id
(Company tickets).
On Tue, Jul 10, 2012 at 2:52 PM, Stefano Ricci <stefano.ri...@riccimatic.com
> wrote:
> is the main problem is to segregate customer users in different queue, in
> funcion of particular filter...
>
> for example, i have these active directories:
>
> - ad01
> - ad02
> - ad03
>
> i have these queue:
>
> - q1
> - q2
> - q3
> - q4
> - q5
> - q6
>
>
> ad01 can read and write only ad01 and ad02
> ad02 can read and write only ad03 and ad04
> ad03 can read and write only ad05 and ad06
>
> the reason is simple... the active directory is related to a company....
> and you can't make this data public for an other...
>
> for agents i solve with the mapping "ad groups / otrs roles" (agents login
> from same active directory, but work form more company, and must to have
> permission to read and write only a part of queues)..
>
> but the problem remain on customer....
>
> i think is impossible that anyone don't do the same work...
>
> if isn't impossible in native mode, there are any plugin?
>
>
> On 10 July 2012 20:05, Gerald Young <cryth...@gmail.com> wrote:
>
>> "You have to manually add the customer". This is true, but if you're
>> authenticating with ldap, you should (could) use ldap as a backend for
>> customer source as well, so you don't have this problem.
>>
>> " afte you have to set the persmission of this customer on the differen
>> groups... " Yes, but what is the purpose of your group settings? Why
>> bother? Just set all the customers to "users".
>>
>> Why are you segregating queues from your customers? If you are creating
>> queues *specifically* for the customer, you are causing a big headache for
>> yourself.
>>
>> "now if the customer login to the web interface or send email, can
>> only read/open tickets on queue2...
>> and if is included in a customer company can se the ticket of all
>> company..." yes, where customer_id are the same.
>>
>> "for example with agents is possible to map group in active directory
>> with roles in OTRS, and manage the permission in the admin console...
>> it's possible to do the same for customers?"
>>
>> No.
>>
>> "Edit Customer Default Groups" (CustomerGroupsAlwaysGroups).
>>
>> "i can login the customer, but it can not write any ticket.... i think
>> that the default group for customer is user... but i disable all permission
>> on this group... because i want to have more group in function of
>> persimssion..."
>>
>> Your choices: remove the queues from the users group or remove the
>> customers from the users group. You choose to remove the customers, but
>> don't set a default group they can create tickets in. Queues should be
>> things you provide, not who you provide service to.
>>
>> "the second ask is related to incoming email filter.... if an email are
>> not in customer list, otrs ignore this... whit active directori, is the
>> same?"
>> There should be no difference in how OTRS handles an email ticket. It
>> goes through all back ends that are enabled and checks those backends for
>> customers.
>>
>> "the third ask is related to the use of more Active directory's.... and a
>> way do realize that....
>> for example if i have 3 customer company, i have to login user from
>> different domain..
>>
>> a good idea is to support the login int this format "domain\user"...
>> because is possible that different company have equals user name...
>>
>> now for single company i use how ID the user name (in active
>> directory sAMAccountName)... there is a variable of active directory that
>> store in the same string the full name "domain\user"?
>> "
>> No, but instead of matching sAMAccountName, you may choose to use "mail" (
>> usern...@domain.com) or "userPrincipalName" (username@DOMAIN)
>>
>>
>> On Tue, Jul 10, 2012 at 9:29 AM, Stefano Ricci <
>> stefano.ri...@riccimatic.com> wrote:
>>
>>> i talk for Customer... when you use only OTRS database, and remove the
>>> register form, you have to add manualy the Customer (and if is the case,
>>> use the Customer Company ID to aggregate the ticket of same company)...
>>>
>>> afte you have to set the persmission of this customer on the differen
>>> groups...
>>>
>>> in my case i assign to a queue a group.... always the reference is 1 to
>>> 1.... now i assign the permission of sustomer for the group..
>>>
>>> example:
>>>
>>> - queue1 -> group1
>>> - queue2 -> group2
>>> - queue3 .> group3
>>>
>>>
>>> now i associate the customer to a group and set the permission..
>>>
>>> - group1 -> not associated
>>> - group2 -> read and wite
>>> - group3 -> not associated...
>>>
>>>
>>> now if the customer login to the web interface or send email, can
>>> only read/open tickets on queue2...
>>> and if is included in a customer company can se the ticket of all
>>> company...
>>>
>>> when i use Active directory to login i want to replicate the same
>>> idea.....
>>>
>>> for example with agents is possible to map group in active directory
>>> with roles in OTRS, and manage the permission in the admin console...
>>> it's possible to do the same for customers?
>>>
>>> now in the *CONFIG.PM* i have that:
>>>
>>> # Enable LDAP lookups for Customer logins.
>>> $Self->{'Customer::AuthModule'} =
>>> 'Kernel::System::CustomerAuth::LDAP';
>>> $Self->{'Customer::AuthModule::LDAP::Host'} = 'dcad101';
>>> $Self->{'Customer::AuthModule::LDAP::BaseDN'} = 'dc=adone,dc=lan';
>>> $Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserDN'} =
>>> 'cn=otrs,cn=Users,dc=adone,dc=lan';
>>> $Self->{'Customer::AuthModule::LDAP::SearchUserPw'} = 'a12345++';
>>> $Self->{'Customer::AuthModule::LDAP::AlwaysFilter'} = '';
>>> $Self->{'Customer::AuthModule::LDAP::GroupDN'} =
>>> 'cn=OTRSCustomers,cn=Users,dc=adone,dc=lan';
>>> $Self->{'Customer::AuthModule::LDAP::AccessAttr'} = 'member';
>>> $Self->{'Customer::AuthModule::LDAP::UserAttr'} = 'DN';
>>>
>>> # Enable LDAP lookups for Customer account information.
>>> $Self->{CustomerUser} = {
>>> Module => 'Kernel::System::CustomerUser::LDAP',
>>> Params => {
>>> Host => 'dcad101',
>>> BaseDN => 'dc=adone,dc=lan',
>>> SSCOPE => 'sub',
>>> UserDN => 'cn=otrs,cn=Users,dc=adone,dc=lan',
>>> UserPw => 'a12345++',
>>> AlwaysFilter => '',
>>> GroupDN => 'cn=OTRSCustomers,cn=Users,dc=adone,dc=lan',
>>> AccessAttr => 'memberUid',
>>> UserAttr => 'UID',
>>> },
>>> CustomerKey => 'sAMAccountName',
>>> #CustomerID => '[customer_id]',
>>> CustomerID => 'sAMAccountName',
>>> CustomerUserListFields => ['sAMAccountName', 'sn', 'givenname',
>>> 'company', 'mail'],
>>> CustomerUserSearchFields => ['sAMAccountName', 'sn', 'givenname',
>>> 'company', 'mail'],
>>> CustomerUserPostMasterSearchFields => ['mail'],
>>> CustomerUserNameFields => ['givenname', 'sn'],
>>> CustomerUserValidFilter => '(company=*)',
>>> Map => [
>>> [ 'UserFirstname', 'Firstname', 'givenname', 1, 1, 'var' ],
>>> [ 'UserLastname', 'Lastname', 'sn', 1, 1, 'var' ],
>>> [ 'UserLogin', 'Login', 'sAMAccountName', 1, 1, 'var' ],
>>> [ 'UserEmail', 'Email', 'mail', 1, 1, 'var' ],
>>> [ 'UserCustomerID', 'CustomerID', 'company', 0, 1, 'var' ],
>>> ],
>>> };
>>>
>>> i can login the customer, but it can not write any ticket.... i think
>>> that the default group for customer is user... but i disable all permission
>>> on this group... because i want to have more group in function of
>>> persimssion...
>>>
>>> the second ask is related to incoming email filter.... if an email are
>>> not in customer list, otrs ignore this... whit active directori, is the
>>> same?
>>>
>>>
>>> the third ask is related to the use of more Active directory's.... and a
>>> way do realize that....
>>> for example if i have 3 customer company, i have to login user from
>>> different domain..
>>>
>>> a good idea is to support the login int this format "domain\user"...
>>> because is possible that different company have equals user name...
>>>
>>> now for single company i use how ID the user name (in active
>>> directory sAMAccountName)... there is a variable of active directory that
>>> store in the same string the full name "domain\user"?
>>>
>>> thanks for the help
>>>
>>>
>>> On 10 July 2012 14:46, Gerald Young <cryth...@gmail.com> wrote:
>>>
>>>> What is your purpose of using Customer Groups? If they are to assign
>>>> queues, you may want to rethink this, unless they're for instance, location
>>>> based, or only certain agents are allowed to handle certain customers.
>>>>
>>>> Don't forget that Customer needs Auth and Membership (CustomerUser). If
>>>> you're using ldap, use it for both. It won't sync customers to database,
>>>> only pull from ldap.
>>>>
>>>> "if i have to login customers form others Ad" ... you'd add additional
>>>> back ends (up to 10?) for each AD.
>>>>
>>>>
>>>> On Tue, Jul 10, 2012 at 3:45 AM, Stefano Ricci <
>>>> stefano.ri...@riccimatic.com> wrote:
>>>>
>>>>> now i put on the login via ad of agents and client... but i have these
>>>>> open questions:
>>>>>
>>>>> - for the agents i assign with *
>>>>> $Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'}* the
>>>>> correct roles, and with *
>>>>> $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'}* i assign
>>>>> the inital group... How i can do the same with the customers?.... i
>>>>> have
>>>>> more queue, and a have to activate them in function of the user... fore
>>>>> example... if a customer are in particular group in ad, have to write
>>>>> only
>>>>> in queue1/group1....
>>>>> - otrs fileter the email if you aren't a customer in database, but
>>>>> with ad login, no data are in database... how i can: remove the
>>>>> filter, or
>>>>> put the customer data in otrs database and sync (the agent mode)
>>>>> - if i have to login customers form others Ad, how i have to do in
>>>>> the script? i have to logon whit this name "domain\user"... i have to
>>>>> split
>>>>> the login name by my self or there is ant attibute similar to
>>>>> sAMAccountName that have the complete name?
>>>>>
>>>>>
>>>>> thanks fot the help
>>>>>
>>>>>
>>>>> On 7 July 2012 13:38, Gerald Young <cryth...@gmail.com> wrote:
>>>>>
>>>>>> This means that there is no sAMAccountName that matches adone\agent1
>>>>>> in Active Directory. That's highly likely as most sAMAccountName are
>>>>>> simple
>>>>>> usernames.
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 6, 2012 at 12:29 PM, Mike Eduard <m...@znuny.com> wrote:
>>>>>>
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>>
>>>>>>> On 7/6/12 18:24 , Stefano Ricci wrote:
>>>>>>>
>>>>>>>> now i solve the error 187... but i have this response
>>>>>>>>
>>>>>>>> [Fri Jul 6 18:18:45 2012][Notice][Kernel::System::**Auth::LDAP::Auth]
>>>>>>>> User: adone\agente1 authentication failed, no LDAP entry
>>>>>>>> found!BaseDN='dc=adone,dc=lan'**, Filter='(*
>>>>>>>> sAMAccountName=adone\\agente1*)', (REMOTE_ADDR: xxxx).
>>>>>>>> [Fri Jul 6 18:18:45
>>>>>>>> 2012][Error][Kernel::System::**User::UserLookup][797]
>>>>>>>> No UserID found for 'adone\agente1'!
>>>>>>>>
>>>>>>>
>>>>>>> You do not have an agent with username "adone\agente1" in OTRS.
>>>>>>>
>>>>>>> You need to create this agent via admin interface first.
>>>>>>>
>>>>>>>
>>>>>>> mike
>>>>>>>
>>>>>>> --
>>>>>>> Mike Eduard
>>>>>>> Enterprise Services for OTRS
>>>>>>>
>>>>>>> Znuny GmbH // Marienstraße 11 // 10117 Berlin // Germany
>>>>>>>
>>>>>>> P: +49 (0) 30 60 98 54 18-0
>>>>>>> F: +49 (0) 30 60 98 54 18-8
>>>>>>> W: http://znuny.com
>>>>>>>
>>>>>>> Location: Berlin - HRB 139852 B Amtsgericht Berlin-Charlottenburg
>>>>>>> Managing Director: Martin Edenhofer
>>>>>>>
>>>>>>> ------------------------------**------------------------------**
>>>>>>> ---------
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
