Sune T. wrote: 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.

I'd like to add an additional method to the one Matthew P. described. We do something similar using the Customer_User table as described under "Customer with multiple IDs (Company tickets)" here in the manual: http://doc.otrs.org/3.0/en/html/customer-user-backend.html In our case we have two different needs implementing this. In one scenario, a company manager has responsibility for multiple sites - when he logs into the customer portal, he wants to see tickets for all the sites under his purview. We set up each site as a separate CustomerID in the customer_company table, then set up multiple CustomerIDs as described in the linked section of the manual above, adding fields to the customer_user table which allow one customer_user to view all tickets from any of the companies for which he has an additional customerID populated. Another scenario where this works is in the case of a group of associated companies - an owner of one company has a stake in several others and wants to be able to view tickets for all the companies he has a management interest in. The same technique can be used. We decided on using a naming convention in our customerID of a leading letter which corresponds to the type of entity followed by a one -up five digit identifier. It would be easy to simply decide on a convention of that type, perhaps adding a suffix to the customerID, or you could add additional fields if desired. For our purposes we simply decided to call new sites separate companies and use the customerID naming convention to identify sites or associated companies. As Matthew also said, this is but one of many ways to address the need. It seemed to us to be the simplest, requiring the least amount of customization to OTRS. Rob