"that's a story about another flaw" No, it's just not what you would do, but it's the way the system works. It's not your ticket to fix. It's the locked owner's ticket to fix. It's specifically so you don't barge in there confusing both the agent and the customer on who, exactly, is handling the ticket.
The proper way to do what you want is to create a Ticket Event. It's not a bug. Nobody but you needs it, and it's not necessary in core code, and will likely keep across upgrades. "how?" http://forums.otterhub.org/viewtopic.php?f=60&t=10090 Psuedo code: Check for ArticleSend Get the queue for the ticket. Get the queuegroup Get the members of the group Get the message that's being sent Send to the members of the group It's all nice, neat, tidy, and yours. On Fri, Mar 1, 2013 at 1:34 PM, Vadim S. Goncharov <vgoncha...@nic.ru>wrote: > 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<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<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
