On 12/19/2011 01:51 PM, otrs-request@otrs.orgmailto:otrs-request@otrs.org wrote:
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Dec 2011 12:01:09 +0000
From: "Sune T. Tougaard" mailto:stt@lyngsoesystems.com
Subject: [otrs] Company/Customer - addition of "levels".
To: "otrs@otrs.org"mailto:otrs@otrs.org mailto:otrs@otrs.org
Message-ID:
<307B82F59ACEC64A963EF7B6284114DD1C1E6D1B@DKMAIL01.lint.lyngso-industri.dk>mailto:307B82F59ACEC64A963EF7B6284114DD1C1E6D1B@DKMAIL01.lint.lyngso-industr...
Content-Type: text/plain; charset="us-ascii"
Hi list,
I've been looking a bit at the Company/Customer part in OTRS.
I'd like to add a level or two, I think. Not sure how else to implement.
As far as I understand, the "Customer" part is the end-user that may or may not have access to the customer web-interface.
And Companies let me group multiple customers under the same Company, and potentially all company tickets.
So, building on that understanding, let's say I wanted to do something like this:
Company1 / Site1 / Customer1
Company1 / Site1 / Customer2
Company1 / Site2 / Customer2
Company1 / Site2 / Customer3
Company1 / Site3 / Customer1
In this case I'm using sites. It could also have been Sub-Contractors or similar.
Do I have any built-in ways of accomplishing this?
I know OTRS can do all kinds of things just by fiddling around in sysconfig, but I'm not quite sure what to look for.
I'd like to use both internal and external customer databases.
Currently I'm thinking about pulling the "Site" part back as a queue, but I just see a potential queue/customer/group/agent management nightmare coming up. :)
I think I've seen a few similar requests, but not with a definitive answer, so I dare to ask again.
Thanks for any input...
--
/Sune T.
We do something similar here, the way we handle it is by using a structured customer ID.
1. First we enabled the additional Customer Ids option in the table and in the customer mapping as described in the admin/dev manuals.
2. Then we set up the "Main" Company Id (eg Company A = CPA, Company x = CPX),
3. Next each "Subgroup/site" adds to the ID (eg Company A new york = CPANY, Company A Toronto = CPATO)
4. Finally, the users get either the ID of the "Subgroup/site" or they can each have their own, depending on if you want them seeing each others tickets. (eg. company a users don't see each others tickets so: Company A new york user 1 id= CPANY01, user2 id= CPANY02. Company X sees each others tickets by default, so Company X London user 1 id= CPXLN, user2 id= CPXLN)
You have to do some extra processing at the database level to make this work nicely, you need either another table to keep track of which users should see other users, or else you have to enter all the additional Ids manually. but if you set this up, then when you set the additional IDs field, instead of default on the customer web interface, (where the my tickets just shows the tickets that user is listed on, and company tickets showing tickets with that customer ID) you get all tickets for that user under the my tickets, and under the my company, you get all tickets under theat id, plus any ticket under an id listed in their other ids entry.
It works pretty well for us, but we are only using one customer database. I imagine that if you used multiple databases for your customer auth, it might get slightly more difficult to sync up the additional Ids fields. Especially, if you can't add rows/tables to the external databases.
I'm not going to say this is the only way, just an Idea that we found functional.
--
Matthew Pulliam
System Administrator
Exegy Inc.
349 Marshall Ave, Suite 100
St. Louis, MO
Direct: (314) 218-3600 x656
Office: (314) 218-3600
Fax: (314) 218-3601
www.exegy.comhttp://www.exegy.com
________________________________
This e-mail and any documents accompanying it may contain legally privileged and/or confidential information belonging to Exegy, Inc. Such information may be protected from disclosure by law. The information is intended for use by only the addressee. If you are not the intended recipient, you are hereby notified that any disclosure or use of the information is strictly prohibited. If you have received this e-mail in error, please immediately contact the sender by e-mail or phone regarding instructions for return or destruction and do not use or disclose the content to others.
