Fail cleanly when a scrip aborts the transaction with a database error

Custom scrips can contain code that causes deadlocks, potentially leading
to the failure of an entire database operation. However, when the automatic
rollback occurs, RT may have already returned a false success. For example,
if a scrip that runs on ticket create causes deadlocks, the system may
display a "ticket created" message, but it's a ghost ticket as it doesn't
actually exist in database.

Author: sunnavy

etc/cpanfile

@@ -25,7 +25,7 @@ requires 'DateTime::Format::Natural', '>= 0.67';
 requires 'DateTime::Locale', '>= 0.40, != 1.00, != 1.01';
 requires 'DateTime::Set';
 requires 'DBI', '>= 1.37';
-requires 'DBIx::SearchBuilder', '>= 1.85';
+requires 'DBIx::SearchBuilder', '>= 1.86';
 requires 'Devel::GlobalDestruction';
 requires 'Devel::StackTrace', '>= 1.19, != 1.28, != 1.29';
 requires 'Digest::base';

lib/RT/Transaction.pm

@@ -303,6 +303,11 @@ sub Create {
         RT::Ruleset->CommitRules($rules);
     }
 
+    # An aborted transaction is rolled back at Commit, so don't return an id for it.
+    if ( RT->DatabaseHandle->TransactionAborted ) {
+        return ( 0, $self->loc("Transaction could not be created; the database transaction was aborted") );
+    }
+
     return @return;
 }