On 27.02.2013 00:10, Gerald Young wrote:
On Tue, Feb 26, 2013 at 2:37 PM, Vadim S. Goncharov <vgoncha...@nic.ru
<mailto:vgoncha...@nic.ru>> wrote:
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=7531
<http://forums.otterhub.org/viewtopic.php?f=60&t=7531>
<http://forums.otterhub.org/__viewtopic.php?f=60&t=7531
<http://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-ldap
<http://doc.otrs.org/3.2/en/html/external-backends.html#multi-customer-ids-ldap>
- 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.
This is not somewhat obvious from it's name. As I said, official docs
doesn't mention this way, it gives the impression that this task is solved
by comma-delimited way only.
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.
"Guarantees" roughly means "officially documented" (so this won't be
something that will change suddenly breaking existing installations). Or at
least word from developers "we just forgot to document it, but yes, this is
true, it is intended for exactly this use".
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
We use this OTRS install strictly for inside-company tickets ("requests"),
and each queue usually corresponds to each working group of people (less
than 10, usually). So it is quite logical here that people in each
subdivision must know what their colleagues do on behalf of sibdivision's work.
definitely not something that *generally* makes any sense to implement for
the rest/majority of us.
It does not necessary require some specific implementing - event-based
notification is enough. There are just not enough events, and processing of
existing event is somewhat broken.
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.
I've described above for what purpose this policy was created. And as for
feature request, I was ready to implement this, see below.
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?
Do you really propose sending dirty hacks as bugfixes? Seriously? (btw, I've
already had to fix another broken part, 'coz patch is, um, dirty). Things
need to be done The Right Way, not hacks. Things need to be done so that
there is no need to re-do them soon. Taking a larger picture into account is
always better.
See http://bugs.otrs.org/show_bug.cgi?id=8953 - I've saw two variants, and
totally don't know, which of two paths (or third) will developers select.
And I don't want to waste time implementing a rather large patch, which
possibly will be rejected when (if) developers decide to go in other
direction of development. That's not fully community open source project to
accept any volunteer patches, OTRS is driven by commercial company - still,
I ready to contribute, if we'll agree *how* that should be done. After all,
that's what communication is for.
--
Vadim Goncharov <vgoncha...@nic.ru> RU-Center
NET Department http://www.nic.ru
NET-SYS Group phone:+7(495)737-7646 (ext.4019)
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
