On Tue, Feb 26, 2013 at 2:37 PM, Vadim S. Goncharov
On 08.02.2013 18:20, Gerald Young wrote:
"My Company Tickets" -- everyone who needs them should have the same CustomerId. http://forums.otterhub.org/**viewtopic.php?f=60&t=7531http://forums.otterhub.org/viewtopic.php?f=60&t=7531 <http://forums.otterhub.org/**viewtopic.php?f=60&t=7531http://forums.otterhub.org/viewtopic.php?f=60&t=7531
For instance: Everyone in a department has the same CustomerId. Multi-department managers have a CustomerIds of depta,deptb,deptc. Done.
From where have you obtained this information you've posted on forum? Docs, e.g. http://doc.otrs.org/3.2/en/**html/external-backends.html#** multi-customer-ids-ldaphttp://doc.otrs.org/3.2/en/html/external-backends.html#multi-customer-ids-ld...- don't say anything about CustomerID is really CompanyID and that way will work. Only comma-delimited field is described. OTRS docs had always been bad, though...
From where? The code. The code says that customer_id is the value that is checked for the tickets that can be seen by a customer in "Company Tickets". There is no such thing as "Company ID" but unofficially, I and others call customer_id "CompanyID" as it is essentially what customer_id represents. It is an attribute in free text attached to the ticket in the ticket table.
Can you guarantee that changing `customer_id` on all tickets (or what I supposed to do to enable this feature?) will break nothing, and that developers won't change this mechanism in future versions? I've digged a lot of OTRS code, but not all, I'm not sure even about current state, not even future.
No guarantees. If it breaks, you get to keep both pieces. But seriously, you CAN break it by overloading fields or something. I'm not going to tell you what it will or will not break for you, but I will tell you that customer_id is primarily used for two purposes: 1) linking a company (when company support is enabled) to a customer and 2) to determine the tickets visible in Company Tickets.
With regard to the conflicting notification systems, you did that to
yourself. Or, more accurately, your corporate policy did that to you.
That's not a good approach to describe why things are so broken and then do nothing instead of thinking how to reach the goals - to fix them. There is nothing very special in this corporate policy, and it could easily be implemented, if some more options in OTRS had existed.
This is a special policy. You are the first and only person who has presented in public forum in the past 3 years I've watched this that you are corporately required to send all outbound-to-customer responses to all agents in a queue. This is unique to you. It may not be special, but it's definitely not something that *generally* makes any sense to implement for the rest/majority of us.
Here's another bad thing about OTRS - I've proposed "Guys, I could do this work for you and contribute, just say what are your plans in this area to have no conflicts" there in bug report. But the bug remains in NEW state for already THREE months!
"We need the following behaviour: when one agent replies something to
customer
in a ticket via Web-interface - that is, 'SendAnswer' via 'AgentTicketCompose' page - then all agents subscribed to this queue must receive mail notification with that text"
Really? That's not OTRS fault.
It is. OTRS not send a notification about notification it has already automatically generated itself. Or have I say "thanks" to this being only just one garbage message instead of infinite loop of them? :)
Who does that? You might as well yell at
Microsoft because distribution group members don't receive emails sent by one of the distribution group member to someone who's not a distribution group member. Speaking of -- that is the solution to your problem. Create an email distribution group for each of the queues and cc or bcc that queue's distribution group when sending the Answer.
And then every agent on every answer must fill Cc:/Bcc: by hand? Why ever men should bother about things machine could easily do? Why should I put more work on people because of bug?
Yes, this is your policy. It's not normal. Read my paragraph above. You are asking for exactly the same thing as what I posted. How would you make Outlook behave according to this? This is not a bug. This is a feature request.
It won't stop doubling, though. Turn off notifications in agent
preferences.
You didn't read carefully, doubling was fixed in bug#7407, now it just one garbage message (body solely of '-' char) to agents on autoreply to client. Actually, for our agents not even so, because I fixed this with a dirty one-line patch to appropriate .pm. I don't submit it, though, because it is not a solution to a broken system but the crutches to local situation (solutions were proposed in bug report).
So, you are part of the problem for not submitting it?