On 01.03.2013 21:47, Gerald Young wrote:
"it is quite logical here that people in each subdivision must know what
their colleagues do on behalf of sibdivision's work."
Yes, but they don't *have* to be told that it happens. Also, what's the
point? Can they do anything about it? No, they just get told "hey, somebody
replied to a ticket" ... The same information, if they cared, they could see
from OTRS. But they don't, because it's not their ticket.
That's simply not true, because it depends on workflow. Our agents receive
full text copy, not just "somebody replied". As an example, just today I saw
messages of the ticket locked by another agent in one of my queues, and
decided to care, and helped that agent and originator. I was forced to leave
note-external, though, because ticket was locked and I couldn't answer, but
that's another story about another flaw.
"There are just not enough events"
Do tell. What kind of event is missing? Or, how many events do you need
before you consider "there are enough events"?
Are you trolling? I told this several times already, referring to text of
bug#8953, in which I described possible solution.
"processing of existing event is somewhat broken"
Ambiguous statement is ambiguous.
"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)."
The alternative being to complain that it's not fixed correctly? Even if the
hack is "dirty", it's actually your responsibility to provide it to anyone
who asks who uses your code. (GPL)
Of course my patch is available to everyone in my company. You missing the
point that complain is not about "not fixed", but rather "they don't give me
information about preferred way to change that subsystem". That's a
difference between "I want them to do the work" and "I want to hear there
are no barriers for me to this work for them".
Just because you hacked it doesn't mean that it has to be accepted and
incorporated as core code verbatim. You're not QC. You're simply giving your
version of, "I fixed it this way." Yes, provide the dirty hacks as bugfixes.
If it works for you, it might work for someone else. Until something
official/better comes along, your code *is* (likely) the best way to handle it.
Once again, there are not just 2 alternatives "they fix" vs "my dirty hack",
but I prefer 3rd "I could do better, if given some info". It is really much
simpler to write several paragraphs of me, and I will code, rather than do
the work themselves, right?
For Guarantees:
Kernel/Modules/CustomerTicketOverview.pm CompanyTickets searches CustomerID.
If the current user has a CustomerID or one of CustomerIDs, that matches
that stored with the ticket $Self->{UserObject}->CustomerIDs( User =>
$Self->{UserLogin} ), it will be shown in Company Tickets.
CustomerIDs is in Kernel/System/CustomerUser.pm and referenced in
CustomerUser/DB.pm and CustomerUserLDAP.pm
Whether delimited with semicolons, commas, or pipes:
# used separators
for my $Split ( ';', ',', '|' )
the values of customer_ids are obtained and then on that array, pushed the
CustomerID.of the current customer.
# use also the primary customer id
if ( $Data{UserCustomerID} && !$Self->{ExcludePrimaryCustomerID} ) {
push @CustomerIDs, $Data{UserCustomerID};
}
This array/list is then sent to the CustomerTicketOverview module, which
searches against that list.
"What happens if you change the customer_id in a historical ticket?" Not
much, ticket-wise. (This based also on personal experience). It won't
prevent a user from accessing her own ticket, but may change her permissions
regarding visibility in "Company Tickets"
"Do you think they'll change this paradigm?" No. Not that I'm 100% sure on
this, but considering how integral it is to accomplishing this goal, I can't
imagine that they'll change it any time soon.
Look at what the CustomerID *does*, especially with what happens when
CustomerCompanySupport is enabled. This is a critical function to just
arbitrarily change for the sake of "New version, let's just throw this out."
"But no documentation" ok. read this
<http://doc.otrs.org/3.0/en/html/x2282.html#multi-customer-ids-db> and then
understand that the default mechanism of OTRS is that everyone has a
different customer_id. There are essentially three ways to make "Company
Tickets" work in practice.
Surely I read this doc. And I referred to it several times already in this
flame (though you skip the quoting). The problem is that this doc does not
_imply_ that CustomerID is non-unique, and it is actually a CompanyID.
Instead, it forces the impression that your way #1:
1) A real pain in the butt, but a Supervisor has a customer_ids field of all
the individual customer_id whom he watches.
...is the only possible way to solve the problem. This is not even something
obvious if you even read some code, because OTRS is big, and nobody reads
all relevant code at once. E.g. I didn't ever dig to CustomerCompanySupport,
which is key to understand the actual meaning - because we don't use it, and
answer for the question in doc don't give a clue to look there.
2) Everyone in a company or department has the same customer_id (and sees
all everyone's-with-the-same-customer_id tickets in Company Tickets)
3) Everyone in a company or department has the same customer_id, but only
the Supervisor or Department Manager sees "Company Tickets"
(CustomerGroupMembership for access privileges) and multi-department
supervisors have customer_ids of departmentA,departmentB
Look at the code. If the result of "CustomerIDs" includes all of the current
customers' customer_ids (if exist) AND the customer_id, and this is what's
being used for TicketSearch for Company tickets.
OK, so the ability to reuse customer_id is undocumented. I figured it out,
so I'm sharing the knowledge. Until something official/better comes along,
my post is (likely) the best way to handle it.
Yep, and I will use it, of course, thanks. Just need to clarify the point
that this fact, and your effort, doesn't cancel another fact "doc is poor".
--
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
