Explanation of Customer and Customer Options

[rjcunningham]

Can someone explain the relation between Customers and Customer Companies, Customber<>Groups,a nd Customers<>Services ?

Ive tried the manual but am not getting anywhere, in face I don't see any reference to the "companies" and "services" at all.
I'm still VERY new to this, so it's possible i still have to turn on options or something like that to make some of these work.
here is my train of thought:
all my customers (users who will call or email w/ trouble) to be in as customers
I have different queues set for the type of system I am supporting, some customers will be calling for a single queue or multiple queues
I would like to allow all customers of a company to see all of that companies tickets, not just the ones that that person called in
however only that customer shoudl be allowed to manage the ticket


Randy Cunningham
----------------------------------
OTRS 3.0.2
OS:Windows 2003 w. all default install apps

[inewman]

> Can someone explain the relation between Customers...

A Customer is a person (that works for a Customer Company, identified by CustomerID. It's a bit confusing the CustomerID refers to a Customer Company, but there you go...). In order for a Customer to be able to login (http://yourhostname/otrs/customer.pl) and view/raise tickets they have to be a 'user' of OTRS, so they have to be put a the 'users' group (Customers<->Groups). A Customer can also be associated with defined Services.

> all my customers (users who will call or email w/ trouble) to be in as customers
Yes, correct.

> I have different queues set for the type of system I am supporting, some customers will be calling for ....
> I would like to allow all customers of a company to see all of that companies tickets...
> ...only that customer shoudl be allowed to manage the ticket

That's OK. Providing each ticket relevant to the Customer has been assigned the correct CustomerID (remember, this is a reference to a Company not a person), then the Customer will be able to see tickets related to his company by clicking on the 'Company Tickets' link when logged in.

If the Customer User has been permissioned in the 'users' group with 'rw' access, they will be able to modify the tickets assigned to that Customer (Company). Otherwise, they will have 'ro' access. Note that is set up per Customer User (person) not Customer Company.

Hope that helps

Ian.

[IcarusNM]

A Customer is a person (that works for a Customer Company, identified by CustomerID. It's a bit confusing the CustomerID refers to a Customer Company, but there you go...)

Wait, wait, wait. Is that consistent throughout OTRS? Every reference to a "CustomerID" is supposed to be an abbreviated COMPANY name?? You cannot be serious. I am playing with this idea, now, and I'm not sure... but I've never really understood this. This could explain why!

[Giulio Soleni]

Please ... let me add some pieces to the puzzle

OTRS just do not allow to directly deal with Companies by default ... unless you turn it on the "company support".
Just search through the /opt/otrs/Kernel/Config/Default.pm file for a line like:
# CustomerCompanySupport => 1,
It's never a good idea to edit the Default, so if you would like to turn "company support" on, just copy and paste that line in your /opt/otrs/Kernel/Config.pm file and uncomment it.

From the moment you enable the company support onwards, each CustomerID has to be associated to the corresponding CustomerID (they should have called it CompanyID IMHO, but that's not important...) of each company you will define.
Before, the CustomerID for each customer user was a free text field and it was unique for each single customer user.
From the moment you enable the company support on, the CustomerID for each customer become a dropdown menu that let you chose among the CustomerIDs you have already defined for each Company, and two (or more) customers may share the same CustomerID, since it has become an attribute that associate each customer the Company he belongs to.

Another thing that you should do, along with the company support enablement, is the definition of multiple CustomerID's for each single user. Unless you do this config also, the company enablement is not so useful by itself only.
The steps to prepare the database and to configure the system to have multiple IDs for each Customer are well explained in the admin guide.

[IcarusNM]

Please ... let me add some pieces to the puzzle

Thank you for this. Companies must have been an afterthought, and were wedged into the CustomerID value as a hack. There's no other explanation for such a misleading misnomer from this usually cautious band of German programmers. It's still pretty ugly, for example, that if I rename a Company, I have to go change the CustomerID in all associated Customers to match. This defies the best practice of MySQL unique row IDs like OTRS has everywhere else. Even worse, a name like "CustomerID" leads one to believe this WAS standard OTRS programming.

I will try CustomerCompanySupport => 1.
I will not, however, go through the additional hackery to enable multiple companies with semicolons. Yuck!

Companies must've been coded on some long Friday night by an Australian after a few German beers. Multiple Companies ... possibly done the next weekend as a coding race at Stanford.

[Giulio Soleni]

It's still pretty ugly, for example, that if I rename a Company, I have to go change the CustomerID in all associated Customers to match.

Not sure about this... I think ... but please try this only on a test system - that as soon as you change the "CustomerID" of a company, each customer belonging to that company will automatically rely to that new CustomerID. I repeat, I am not sure about that.

I will try CustomerCompanySupport => 1.
I will not, however, go through the additional hackery to enable multiple companies with semicolons. Yuck!

Mind that without that addition the company support is quite useless...
To let users share their tickets (in the scope of the same company I mean) through the "Company Ticket" tab you see in the Customer frontend, you should configure the same value in CustomerID (from the dropdown menu) and in the CustomerIDs right below.
If you do not set the CustomerIDs in that way, the "Company Ticket" tab is absolutely equal to the "My Tickets" tab, and even two users belong to the same company they cannot see each other tickets.
Of course, another condition for sharing ticket (obvious) is that both of them share the access to the same queues.

There's another flag in Default.p that should be enabled ... unfortunately I dunno remember precisely and right now I do not have access to my system to check.
This flag allow to exclude one user's own ticket to be seen under "Company Ticket" ... so that, there he may find only the tickets actually created by his collegues and not by himself.

Companies must've been coded on some long Friday night by an Australian after a few German beers. Multiple Companies ... possibly done the next weekend as a coding race at Stanford.

Yes, maybe but still, if well configured this mechanism works quite well...

[crythias]

http://forums.otrs.org/viewtopic.php?f=60&t=7531

You cannot assign services to Company/CustomerID. You can only assign services to customers.

You can take a look at this:
http://forums.otrs.org/viewtopic.php?f=62&t=12487
to batch assign customers to services.

[IcarusNM]

Ugh. This is all so disgusting. I think I just threw up a little in my mouth. I presume it goes without saying, this Company business needs to be re-coded from the ground up? Does that need to be submitted as an "idea" to the ideas board? In the meantime this is certainly more of the same kind of inconsistent insanity in OTRS that keeps people like you employed, crythias.

[crythias]

Most people don't pay me. I don't work for OTRS.

Here's the deal:
1) If you support something, you'll have to determine if you're supporting a company or a representative of the company.
2) If you're supporting a company, then the company should be the customer, unless you need to support 1500 people under the service purchased for the company.
That is the inherent problem with your request. Most of the time, a customer will have a service and therefore an SLA, and when a company has 1300 people who can submit against your SLA, that does put a damper on your ability to fulfill your SLA. Most of the companies who buy a service, and therefore an SLA, understand this and because the company pays big money for the SLA, they also understand who can submit a request and limits that because it's a nightmare and you the support provider also need to limit how many "real" requests go against the SLA.

If you don't have an SLA, then services as such are probably not necessary to assign. (This is my opinion.)
You would use queues for this purpose (what?). Yes, queues (as I like to define them) are [types of] agents who can handle certain requests. Queues should not (again, in my opinion), be related to "who" is making the request but to "what" is the request?

I say [types of] in brackets because sometimes you assign agents, sometimes you assign types of agents. But the queues are agent side answering, "What can I handle?"

[IcarusNM]

Here's the deal:
1) If you support something, you'll have to determine if you're supporting a company or a representative of the company.
2) If you're supporting a company, then the company should be the customer, unless you need to support 1500 people under the service purchased for the company.
That is the inherent problem with your request. Most of the time, a customer will have a service and therefore an SLA, and when a company has 1300 people who can submit against your SLA, that does put a damper on your ability to fulfill your SLA. Most of the companies who buy a service, and therefore an SLA, understand this and because the company pays big money for the SLA, they also understand who can submit a request and limits that because it's a nightmare and you the support provider also need to limit how many "real" requests go against the SLA.

OTOH a central internal IT support desk for a company might actually have 1500 customers submitting requests.
Or it might be a mix - some number of individuals submitting requests, plus some number of companies or vendors, etc.

Clean solution: Design primarily around the idea of a Customer being a person, and a Company being a company. Customers (People) do well being thought of as people. Even a single POC for a company could very well be Joe Smith, a real person jsmith@someco.com. If that rep changes, then maybe you deal with Sam Jones, another person @someco.com. Maybe Sam backs up Joe or works a different shift, whatever.

Obviously here the Company is SomeCo.Com, and the Customers are Joe Smith and Sam Jones. By default if I set up both of those customers each with the Company: "SomeCo" then if OTRS presents a menu option called "Company Tickets" to Joe, that should work as expected and show him all tickets that he has permission to see from requestors also at SomeCo. Maybe that includes himself and then he has an easy toggle to turn that part (his tickets) on/off.

This functionality should not require me as the OTRS Admin to modify the application's database schema and enable some obscure "Customer" (Company) "ID" versus "IDs" and start using semicolons in my data ... just to make this work as it should, in the first place.

Even if SomeCo.Com chooses to present me with some generic interface email address like "requests_from@someco.com" that's fine. I'd create a Customer called "SomeCo Requests" with that email: requests_from@someco.com, and the Company: "SomeCo".

After all, what's the alternative? "someco.com" is not a valid email address! You will never literally have a Company making requests in that sense.

As for SLAs, I don't see any problem here. OTRS already ties an SLA to a Service (not a queue etc). Then Customers are currently linked to Services. In my model, above, I have to separately manage several accounts for one Company, and maintain their links to Services keeping them always all the same. So now we get to the heart of it: perhaps OTRS should link Companies to Services instead of Customers to Services. It's hard to imagine that being a problem for anyone. If you really have a different SLA with two departments within a customer company, just call that SomeCoA and SomeCoB - separate Companies but there's still no reason to get this all tangled up with Customers.

People submit tickets. You are always dealing with a person. There should never be any confusion: A Customer is a Person.

I don't think anything I've said here violates ITIL.

But thanks. This does help me understand better what's behind the current implementation, even if I disagree with it.

[crythias]

By default if I set up both of those customers each with the Company: "SomeCo" then if OTRS presents a menu option called "Company Tickets" to Joe, that should work as expected and show him all tickets that he has permission to see from requestors also at SomeCo. Maybe that includes himself and then he has an easy toggle to turn that part (his tickets) on/off.

This is as default. Except whether the user can see his tickets in Company Tickets is a global config.

Edit to add: you do not need to use email address as "CustomerId" ... it is only provided as a placeholder in case you don't assign one.

[IcarusNM]

Mind that without that addition the company support is quite useless...
To let users share their tickets (in the scope of the same company I mean) through the "Company Ticket" tab you see in the Customer frontend, you should configure the same value in CustomerID (from the dropdown menu) and in the CustomerIDs right below.
If you do not set the CustomerIDs in that way, the "Company Ticket" tab is absolutely equal to the "My Tickets" tab, and even two users belong to the same company they cannot see each other tickets.

So, crythias, the above is false?

[crythias]

Mind that without that addition the company support is quite useless...
To let users share their tickets (in the scope of the same company I mean) through the "Company Ticket" tab you see in the Customer frontend, you should configure the same value in CustomerID (from the dropdown menu) and in the CustomerIDs right below.
If you do not set the CustomerIDs in that way, the "Company Ticket" tab is absolutely equal to the "My Tickets" tab, and even two users belong to the same company they cannot see each other tickets.

So, crythias, the above is false?

First statement is accurate. Without enabling, Company Support doesn't work. (You can't add companies).
First half of second statement is accurate, and as per my HowTo: by *default*, customers with the same CustomerID will see all of the tickets for that CustomerID in Company Tickets. There is no need to modify schema for that purpose. Read my HowTo again and ask me based upon that.

The third statement is accurate. Customers each having a different CustomerID, even belonging to the same company, will not see each other's tickets.

Summary:
1) CustomerID is what shows what's in "Company Tickets"
2) CustomerID doesn't have to be unique per customer and doesn't have to be an email address or anything "validated".
3) CustomerID should, but doesn't have to, match a CustomerID in Company.
4) CustomerID is assigned as an email address simply because the default assumption is that a new customer is *unique*.
Also:
5) The "Company Tickets" tab can be available permission-wise only to department heads by CustomerGroups (if that is enabled).
6) Customer_IDs (the one with multiple, schema change, semicolons) is useful for (in my opinion) managers of multiple departments, when the customers are segmented into departments per company, and you'd like that multi-department manager to see all the tickets from customers with customerID CompanyADeptA; CompanyADeptB
(or CompanyANorth; CompanyASouth)

[IcarusNM]

Mind that without that addition the company support is quite useless...
To let users share their tickets (in the scope of the same company I mean) through the "Company Ticket" tab you see in the Customer frontend, you should configure the same value in CustomerID (from the dropdown menu) and in the CustomerIDs right below.
If you do not set the CustomerIDs in that way, the "Company Ticket" tab is absolutely equal to the "My Tickets" tab, and even two users belong to the same company they cannot see each other tickets.

So, crythias, the above is false?

First statement is accurate. Without enabling, Company Support doesn't work. (You can't add companies).

Sorry, I didn't quote back far enough. The question is whether I have to enact the schema-altering Multiple Company hack just to enjoy the simple sanity of putting two People (Customers) in the same Company, and have the My Company's Tickets tab work.

6) Customer_IDs (the one with multiple, schema change, semicolons) is useful for (in my opinion) managers of multiple departments, when the customers are segmented into departments per company, and you'd like that multi-department manager to see all the tickets from customers with customerID CompanyADeptA; CompanyADeptB (or CompanyANorth; CompanyASouth)

Finally something that makes sense. Thank you.

[IcarusNM]

This Customer stuff is a total mess. Looking at the internals, OTRS uses a nice numerical "id" system as unique row identifiers throughout the database scheme, with foreign keys like "type_id", "this_id", "that_id" e.g. ticket:

Code: Select all

                      id: 1991
                      tn: 123456
                   title: Help me I cannot get up
                queue_id: 5
          ticket_lock_id: 1
         ticket_answered: 0
                 type_id: 1
              service_id: NULL
                  sla_id: NULL
                 user_id: 3
     responsible_user_id: 3
                group_id: 1
      ticket_priority_id: 3
         ticket_state_id: 2

All those foreign_id keys point to other tables by "id", always an INTEGER.
Everything is roses and blue skies until we get here. What's this? Not INTEGERS!

Code: Select all

     
             customer_id: user_blah@some.com
        customer_user_id: user_blah@some.com

Now let's look at the main customer table.

Code: Select all

mysql> describe customer_user;
+-------------+--------------+------+-----+---------------------+----------------+
| Field       | Type         | Null | Key | Default             | Extra          |
+-------------+--------------+------+-----+---------------------+----------------+
| id          | int(11)      | NO   | PRI | NULL                | auto_increment | 
| login       | varchar(200) | NO   | UNI |                     |                | 
| email       | varchar(150) | NO   |     |                     |                | 
| customer_id | varchar(150) | NO   |     |                     |                | 
| pw          | varchar(64)  | YES  |     | NULL                |                | 
| title       | varchar(50)  | YES  |     | NULL                |                | 
| first_name  | varchar(100) | NO   |     |                     |                | 
| last_name   | varchar(100) | NO   |     |                     |                | 

That "customer_user" table has 3 confusing fields: id, email, customer_id.
Does customer_id in ticket refer to the id in this table... staying consistent with the other 100 tables in OTRS? NO.
Does customer_user_id in ticket refer to the id in this table... staying consistent with the other 100 tables in OTRS? NO.

We learn instead that customer_id here is some other magical thing, a VARCHAR which can be a COMPANY name if you pervert your configuration just right. Else an email, or not ... it's madness.

Now in customer_company the wheels really come off the bus. Notice anything missing below? The id column! It's gone altogether! Does customer_id replace it, as an INTEGER, a row index? NO. Again it's a VARCHAR, which might match some customer_id you set elsewhere, if you were careful.

Code: Select all

mysql> describe customer_company;
+-------------+--------------+------+-----+---------------------+-------+
| Field       | Type         | Null | Key | Default             | Extra |
+-------------+--------------+------+-----+---------------------+-------+
| customer_id | varchar(150) | NO   | PRI |                     |       | 
| name        | varchar(200) | NO   | UNI |                     |       | 
| street      | varchar(200) | YES  |     | NULL                |       | 
| zip         | varchar(200) | YES  |     | NULL                |       | 
| city        | varchar(200) | YES  |     | NULL                |       | 
| country     | varchar(200) | YES  |     | NULL                |       | 
| url         | varchar(200) | YES  |     | NULL                |       | 
| comments    | varchar(250) | YES  |     | NULL                |       | 
| valid_id    | smallint(6)  | NO   |     | 0                   |       | 
| ...
+-------------+--------------+------+-----+---------------------+-------+

Remember back in ticket we have both customer_id and customer_user_id. Just keep those the same. Save yourself the pain. God knows what they really mean, or what else they can be and still maintain data consistency. OTRS is going to treat at least one of them as an Email address, even though there's a separate email field in the customer_user table already.

Here's a fun one to try:

Code: Select all

mysql> select count(id) from ticket where customer_id = customer_user_id;
+-----------+
| count(id) |
+-----------+
|     11822 | 
+-----------+

mysql> select count(id) from ticket where customer_id != customer_user_id;
+-----------+
| count(id) |
+-----------+
|      1090 | 
+-----------+

This is Relational Database 101 stuff, folks. It's simple: the ticket should have a single customer_id field which maps to a single id in the customers table.

I'm not wasting any more time on this. I'm not touching Companies with a 10-foot pole. I just have one question: is there any TODO item on the forecast to clean this all up? This schema bubbles straight up into the application and causes all sorts of confusion. You guys on the inside who have been administering and/or authoring OTRS for years are used to it. For anyone else coming in ... it's a nightmare. Please. I'm begging. Fix the madness.

[jojo]

There is nothing to fix...

Customers are persons
persons can belong to companies (but don't have to)

Tickets should be assigned to customers, and can be assigned to a company

[crythias]

What jojo said.

Company information (Customer_ID) is not relational because it doesn't have to exist.

If a customer has a customer_id, and that customer_id matches a company's customer_id, then gather information from the company table, else don't bother with it.

Yes, Company is an add-on. It has no relationship to a ticket whatsoever.

If a Company exists and it has the same customer_id as a customer's customer_id, they're linked, otherwise, they're not.

That's all.

[crythias]

This is Relational Database 101 stuff, folks. It's simple: the ticket should have a single customer_id field which maps to a single id in the customers table.

No. not at all. customer_user_id does that.
customer_user_id holds the login. customer_id holds an arbitrary value that can be practically anything.

customer_user_id (login) determines "My Tickets"
customer_id determines "Company Tickets"
Both of them are free text because there is no general way, especially for customer_user_id, to hold any other personal identification index across all possible methods of authentication.

Rephrased: Let's say you move from database authentication to ldap authentication (or another database source). Would it be easier to use the identical login name or would you rather reverse-populate a field in ldap from the database for the id?