ok, but if i do all with OTRS database (manualy inseret of customers) i can
segregate without any problems customers to a partucular queues...
i cant't underand why, using ldap as backend, i loss this possibility...
i realize the configuration discussed in this topic on OTRS database
firstly, after i start the implementation of ldap authentication...
int this case i need to segregate customer, and i need to have only one
instance of otrs, because a part of agents have to work on all queues (have
a lot of instances create a lot of problems when they have to check the
tickets)..
i know that the customer can see only this tickets, or the company tickets
if is enabled the configuration...
On 10 July 2012 21:31, Gerald Young <cryth...@gmail.com> wrote:
> 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
>
---------------------------------------------------------------------
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
