1 customer, multiple contacts/logins

[Dieter_be]

Hi,
for some of our customers, there are several people who should be able to log in and check all tickets for their company. (ie tickets opened by them and by their colleagues)

If I understood correctly, a "customer" in otrs is just a person (or rather, an email address/login). So to model this, I followed http://doc.otrs.org/2.4/en/html/x1157.h ... ser-groups, so that I have multiple "customers" (users) which then go in a group (name of their company)
The documentation explains to create the customers, the group, add users to the group. create a queue, connect the group to the queue, and enable CustomerGroupAlwaysGroups. I did all of that.

However, I don't quite get some things:
1) how do incoming mails go into the right queue? Do I need to check incoming addresses myself and route them to the queue for their group myself? (ie with procmail). Because if such a customer sends an email, a ticket is made in the default queue, not the queue for the group that contains this customer.
2) I would expect that every customer which is part of a customergroup, gets to see all tickets for the entire group (queue) in his customer interface, however this is not true: they can only see their own tickets, which makes it less useful for us.

I use otrs 2.4.7 on debian

Thanks,
Dieter

[Dieter_be]

I found http://lists.otrs.org/pipermail/otrs/20 ... 10599.html, where they suggest to give the same customerID to multiple customers.
I did exactly that, i gave customer A and B the exact same (textual) customerID.
However, if A then sends a mail, only A can see it in his webinterface. B cannot see it, not even in "CompanyTickets"

edit: never mind, the mail needed a bit of time to propagate.
setting the customerid the same seems to work fine.

[crythias]

Customers are agnostic (don't know/don't care) what Queue they are a part of.

Yes, you can have a PostmasterFilter or Generic Agent that checks the user's customerid and change New tickets to the queue to that applies to the customerid.

I'm not entirely certain why B can't see A's email. As long as B and A have the same customerid, they should theoretically be able to see it. Won't affect tickets that were created before changing customerid.

[Dieter_be]

Yes, you can have a PostmasterFilter or Generic Agent that checks the user's customerid and change New tickets to the queue to that applies to the customerid.

that is cool. thanks.

Customers are agnostic (don't know/don't care) what Queue they are a part of.

Really?
Then why is it that under "new ticket" in the customer interface the customer can choose a queue?
I'm okay with the default queues (a queue for junk, postmaster, etc seems useful) but I don't want the "To:" selector to list all of them.
Even more, I will create more queues that I don't want any customer to be able to see. How can I finetune which queues can be seen by customers?

[crythias]

Really?
Then why is it that under "new ticket" in the customer interface the customer can choose a queue?

It's the default that they can be chosen. But, I think I meant to say that the customers might "help" by choosing what queues may be appropriate, but they generally are oblivious to other tickets in the same Queue. Basically: the customer doesn't own the queue by default. The customer submits tickets to be addressed appropriately (printing problems, computer down, etc.), which may have its own queue. Your workflow may vary.


Config Options: Ticket -> Frontend::Customer::Ticket::ViewNew
CustomerPanelOwnSelection:
Here you can insert the Queues, which the customer can select in the Customer-Interface.

If you have a generic email address by which new tickets are generated, the customer never really "knows" what the queue is.

[Dieter_be]

good. thanks. I disabled those queues in that config setting. Now I just need to remember everytime I create an internal queue, I should immediately go to the CustomerPanelOwnSelection to disable it again...

I also have another problem:
we have a customer from which a lot of different people will send us emails, it's practically impossible to create customer entries for all of them in advance.
So, when we receive an email from this company (we can match their email using from or to header) otrs should automatically know these emails belong to the customer. I thought about automatically moving them to a queue, but then it gets hard to make a customer "owner" of it's own queue (or not?) and this would basically be reinventing the customerID field, using queues, and more manual work to track it all.

So I tried automatically setting setting the customerId property, using procmail. this works nicely, however, the customer doesn't see the ticket in his interface. Also when I log in as agent, take a ticket, and set its customerID, it also won't show up for the customer.

Finally, I would add that modifying the customerID as an agent is not convenient and more errorprone: you need to manually write the string in a textbox, whereas the queues can easily be selected using the selecttag. Is there a fix for this?

[crythias]

customer_user_id is the unique id of the user who the ticket belongs to. customer_id is the company the user belongs to.

Now, tickets get created by anyone who sends an email, and the default action is to make the customer User to be the email address of the sender and the customerID to be the email address if the customer is unknown.

If the customer company will have people sending from random domains, you have a bit of a problem. If they're from the same domain, the procmail.dist already has an Example for assigning the "email domain as customer ID" automaticaly. Just uncomment the #'s

But I don't know why they can't see their own tickets, unless they have some problem logging in (no auth available), which could make sense...

I'm sorry. I'm trying to help, but I'm not certain I understand why customerID manipulation has anything to do with a customer seeing his own ticket. It would make sense to enable someone to see or not see in "Company Tickets" but Customer_User_ID should "win" for the customer.

[Dieter_be]

Thanks for the advice.
I found the sample in the .procmail and enabled it (though i slightly modified the regex, to not get the .TLD part)
The customerID assigning works nicely, I had an issue during testing that as customer, I could not see the mails. But apparently they wound up in queues that had group set to "admin". I don't think that was needed (the queues are just queues like the others), so i set them to "users", and now i can see the tickets in the customer interface

[Dieter_be]

So now, the real problems seem to be solved, only some inconveniences remain:

* modifying the customerID as an agent looking at a ticket is not convenient and errorprone: you need to manually write the string in a textbox, whereas the queues can easily be selected using the selecttag. Is there a fix for this? I would like a selectionbox for the customerId as well.
* everytime I add an internal queue, I must remember to immediately go to the CustomerPanelOwnSelection and disable it again, so customers don't see it...
* I can't get rid of the "To:" field for the customerinterface where they create a new ticket. I don't want them to choose a queue, but apparently there needs to be at least 1 entry in the to, which needs to be selected (not choosen, since there is only one), otherwise the form gives an error when submitting. Pretty pointless..