[rt-users] FW: Determine who resolved how many tickets
I'm looking to baseline the performance of my team against the number of tickets they have resolved in RT over a given time. To do this I export the month's tickets from RT into Excel (queue, status=resolved and last updated by) I then use Excel to do a countif to produce my figures. The problem is, I could really do with using a "resolved by" calculation, rather then last updated by, as last updated by is not always the person who initially resolved the ticket. Any thoughts please? Thanks. First thing I would mention is why export to excel? Build your search, run it, then choose the Chart option, and on the lower left you can rebuild the chart using Last Updated by Real Name and it'll make a nice bar chart. That doesn't solve your "resolved by" problem though. Since it's not there by default (which I agree would be nice, and I've had dept managers ask me for the same thing), you could add a custom field and populate it when the ticket is resolved, then choose it in the Chart I mention above. If you limit your charting to a single queue, that CF will show up (or I guess any number of queues that CF appears in, but I haven't tested that). Brent
Re: [rt-users] RT loses MySQL connection
Hey Ken- Yep, I get that. I don't believe you can disable the wait_timeout entirely - by default, it's set to 8 hours, which is what I currently have. RT works great - for 8 hours. Just to be sane, I replaced my.cnf with the default my.cnf that gets built with a vanilla install of MySQL. Same issue. Clearly though, I have something going on that is not-normal because if this were a real bug, lots of people would be reporting it and it's never been an issue for me before. I'm going to start over with a clean build and try again. - Jay On Mon, Nov 25, 2013 at 5:53 AM, k...@rice.edu wrote: > On Sat, Nov 23, 2013 at 08:35:06AM -0800, Jay Christopherson wrote: > > Interestingly, adjusting the wait_timeout to the default (8 hours) worked > > great - for 8 hours. After that 8 hours, RT once again lost all > > connectivity to the database. Running a "show processlist" on MySQL > showed > > that RT had no connections to the DB, even though RT was still running. > A > > restart fixed it - for now. > > > > I am not sure how RT does connection handling, but it seems like it > should > > attempt to reconnect? > > > > Hi Jay, > > Again, a properly managed system does not require and certainly does not > expect > to have a connection ripped out from under it. Turn off your timeout and > you > will be fine. RT will connect just fine, as you have seen. It should not > need > to "reconnect" to a properly configured DB once it has a valid connection. > > Regards, > Ken >
[rt-users] callback need to load a ticket's CF value from DB, not web form
In my callback for Modify.html, I need to know what the value of a custom field was set to even if it was unchanged on this particular form submission. What I am seeing right now is that if the value was not changed on this form submission, the value shows in the callback as an empty string, so I need a function/method that I don't know about yet, hence this call for help. Modify.html/jblaine my $x = $ticket->LoadCustomFieldByIdentifier('Foofield'); my $xx = $ticket->CustomFieldValuesAsString('Foofield'); Both 'x' and 'xx' log as empty strings when I modify a ticket without touching Foofield (Foofield DOES have a value that was set previously). So, cool, fine, Foofield was not modified in this transaction. I still need to know what its value is from the database in order to perform some logic if someone is trying to resolve this ticket. How do I load Foofield's value from the database?
Re: [rt-users] RT loses MySQL connection
On Sat, Nov 23, 2013 at 08:35:06AM -0800, Jay Christopherson wrote: > Interestingly, adjusting the wait_timeout to the default (8 hours) worked > great - for 8 hours. After that 8 hours, RT once again lost all > connectivity to the database. Running a "show processlist" on MySQL showed > that RT had no connections to the DB, even though RT was still running. A > restart fixed it - for now. > > I am not sure how RT does connection handling, but it seems like it should > attempt to reconnect? > Hi Jay, Again, a properly managed system does not require and certainly does not expect to have a connection ripped out from under it. Turn off your timeout and you will be fine. RT will connect just fine, as you have seen. It should not need to "reconnect" to a properly configured DB once it has a valid connection. Regards, Ken