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>
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
- 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...
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.
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.
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?
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).
P.S. BTW, your mail client's quoting is broken:
On Fri, Feb 8, 2013 at 9:03 AM, Vadim S. Goncharov <[email protected]
<mailto:[email protected]>> wrote:
On 08.02.2013 17:21, Steven Carr wrote:
On 8 February 2013 13:05, Israel Garcia<[email protected]
<mailto:[email protected]>> wrote:
OK Steve, so I should edit /opt/otrs/Kernel/Config.pm, add my
LDAP settings,
restart OTRS and volia!?
Also, I have seen in Admin/SysConfig/Frontend::__Customer::Auth
the same
parameters I have added to /opt/otrs/Kernel/Config.pm, should I
edit them
using this web page or editing directly the
/opt/otrs/Kernel/Config.pm
file?
Don't quite know about the "voila", more like cross your fingers and
hope it doesn't collapse in a heap.
One of my big issues with OTRS is the configuration is utter crap. Too
There are many places in OTRS which are crappy. E.g. different
conflicting notification systems (see e.g. bug #8953), and, on-topic,
customer groups. We have group attibute in LDAP for customers, and
simple intuitive and SCALABLE solution would be just use that word of
customer to regulate access. But "My Company tickets" in OTRS requires
comma-delimited list of "user1,user2,...user100500" for EVERY user.
Brain-damaged.
many places to configure things, everything should really be just
configured through Sysconfig instead of having to mess about with text
files (and perl based text files at that), and ideally stored in the
database to make upgrades a lot easier than worrying about which
config files you need and don't need.
I'm not sure the order in which the settings are applied but I would
guess that anything you put in Kernel/Config.pm will override anything
you configure in SysConfig (someone can correct me if I'm wrong).
Yes. Actually, Config.pm is applied TWO times: before SysConfig, and
once again after.
So just make your changes in one place and one place only and they
will be added to the overall config.
That's not always possible :)
--
Vadim Goncharov <[email protected] <mailto:[email protected]>>
RU-Center
NET Department http://www.nic.ru
NET-SYS Group phone:+7(495)737-7646
<tel:%2B7%28495%29737-7646> (ext.4019)
------------------------------__------------------------------__---------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/__pipermail/otrs
<http://lists.otrs.org/pipermail/otrs>
To unsubscribe: http://lists.otrs.org/cgi-bin/__listinfo/otrs
<http://lists.otrs.org/cgi-bin/listinfo/otrs>
---------------------------------------------------------------------
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
--
Vadim Goncharov <[email protected]> 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