[rt-users] Help with Scrip for child / dependent tickets
Hi there,
We are wanting to have a scrip run on our queues which will move a ticket back
to the open state if all of its child and dependent tickets are closed
(resolved, rejected or deleted).
I have found Ruslan's scrip which opens a ticket once all of its child tickets
are closed here on the wiki:
http://requesttracker.wikia.com/wiki/OpenTicketOnAllMemberResolve which works
great. However we have tried to edit this to work on depending / dependent
tickets but cannot get it working. Here is the scrip, can anyone see what we
are missing?
# end if setting this ticket to resolved, deleted or rejected
return 1 if ($self-TransactionObj-NewValue !~
/^(?:resolved|deleted|rejected)$/);
# current ticket is a dependant of (Depended on by some parents)
my $DependedOnBy = $self-TicketObj-DependedOnBy;
while( my $l = $DependedOnBy-Next ) {
# we can't check non local objects
next unless( $l-TargetURI-IsLocal );
# if dependant ticket is not in active state then scrip can skip it
next unless( $l-TargetObj-Status =~
/^(?:new|open|stalled|pending|planning|holiday)$/ );
# the dependant ticket has dependencies (current ticket is one of them)
my $ds = $l-TargetObj-DependsOn();
my $flag = 0;
while( my $d = $ds-Next ) {
next unless( $d-BaseURI-IsLocal );
next unless( $d-BaseObj-Status =~
/^(?:new|open|stalled|pending|planning|holiday)$/ );
$flag = 1;
last;
}
# shouldn't open dependant if some dependency is active
next if( $flag );
# All dependent tickets closed - open depending ticket
$l-TargetObj-SetStatus('open');
}
return 1;
--
Once we can get this scrip working we would ideally like a single scrip which
will check all tickets on status change to see if it has a parent or depending
ticket; and then if all child or dependent tickets for its parent are closed,
to reopen the parent...
Any help greatly received!
Jon
-
Jon Witts
Director of Digital Strategy
Queen Margaret's School
Escrick Park
York YO19 6EU
Telephone: 01904 727600
Fax: 01904 728150
Website: www.queenmargarets.com
This email has been processed by Smoothwall Anti-Spam - www.smoothwall.net
[rt-users] Upgrading web/email server...should I upgrade RT itself too?
Hi all, We're running RT on Ubuntu 8.04...so it's time to get with the times. :-) A new CentOS server has been prepared for us. The database is actually running on a separate machine that is newer and there isn't a plan to upgrade it at this point. My question...is RT 4.0.17 itself old enough that I really ought to upgrade it as well? I'd like to minimize the amount of surprise for the users via new looks, so I'm wondering if there are any huge problems with staying at 4.0.17. I'm looking at the UPGRADING-4.2 document and I don't see anything like this version of RT turned into Ultron at 10% of installations. For context, this installation of RT is only available on our internal network, to a userbase of 10-20 people who are pretty used to RT working the way it does. They don't use most of the fancier features of the system. -- Kendric Beachey CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be confidential and/or legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
Re: [rt-users] Upgrading web/email server...should I upgrade RT itself too?
On Fri, 8 May 2015 14:11:08 + Beachey, Kendric kendric.beac...@garmin.com wrote: My question...is RT 4.0.17 itself old enough that I really ought to upgrade it as well? Yes. 4.0.17 has published security vulnerabilities against it (CVE-2015-1464, CVE-2015-1165, CVE-2014-9472): http://blog.bestpractical.com/2015/02/security-vulnerabilities-in-rt.html I'd like to minimize the amount of surprise for the users via new looks, so I'm wondering if there are any huge problems with staying at 4.0.17. Upgrading within a stable series will never cause any major user-visible UI changes, and should never break installed extensions. Upgrades within a stable series (from 4.0.17 to 4.0.23, for instance) are designed to be no-hassle bugfixes and security fixes. If we feel a change has the potential to give an administrator reason to _not_ upgrade within a stable series, it is unsuitable for that trunk. Please upgrade. All of this is hopefully also made clear on release policy page: https://bestpractical.com/rt/release-policy.html - Alex
[rt-users] Upgrading web/email server...should I upgrade RT itself too?
Hi, A more immediate issue I would expect is that newer versions (not to mention the switch from Debian to RPM based distros) of framework applications (Apache, MySQL, PHP, Mason, Perl etc) may have compatibility issues with your older RT installation. So yes, you may not have much choice but to upgrade anyway. Subject: [rt-users] Upgrading web/email server...should I upgrade RT itself too? Message-ID: 074c3ae4e206dc478ab4fa128b97914143d78...@olawpa-exmb05.ad.garmin.com Content-Type: text/plain; charset=us-ascii Hi all, We're running RT on Ubuntu 8.04...so it's time to get with the times. :-) A new CentOS server has been prepared for us. The database is actually running on a separate machine that is newer and there isn't a plan to upgrade it at this point. My question...is RT 4.0.17 itself old enough that I really ought to upgrade it as well? I'd like to minimize the amount of surprise for the users via new looks, so I'm wondering if there are any huge problems with staying at 4.0.17. I'm looking at the UPGRADING-4.2 document and I don't see anything like this version of RT turned into Ultron at 10% of installations.
[rt-users] Determining resolver of a ticket
As far as I can see, it is not possible to search for the resolver of a ticket. I have a single queue with members of different groups opening and resolving tickets. I can't seem to figure out how to figure out how many tickets Group 1 resolved vs Group 2. Is it possible to run a SQL search instead of using RT's query language? Thanks in advance. -Armen
Re: [rt-users] Determining resolver of a ticket
On 5/8/2015 3:03 PM, Armen Tashjian wrote: As far as I can see, it is not possible to search for the resolver of a ticket. I have a single queue with members of different groups opening and resolving tickets. I can’t seem to figure out how to figure out how many tickets Group 1 resolved vs Group 2. Is it possible to run a SQL search instead of using RT’s query language? Create a Custom Field for this purpose and set it in an OnResolved-triggered scrip, then... profit! You could perhaps also scan transactions for the one in which the ticket resolved and pull the actor from that transaction. In our instance, this could be RT itself in many cases, though, since we use an autoclose status that transitions to resolved after 72 hours via cron. Regards, Mark -- Mark D. Nagel, CCIE #3177 Emeritus mna...@willingminds.com Principal Consultant, Willing Minds LLC (http://www.willingminds.com) cell: 949-279-5817, desk: 714-495-4001, fax: 714-844-4698 ** For faster support response time, please ** email supp...@willingminds.com or call 714-495-4000
