"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.
"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"?
"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)
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.
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.
1) A real pain in the butt, but a Supervisor has a customer_ids field of
all the individual customer_id whom he watches.
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.
---------------------------------------------------------------------
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
