[Rt-commit] rt branch, 4.2/force-approvals-disabled, created. rt-4.2.3-192-gf32098f

Alex Vandiver alexmv at bestpractical.com
Mon May 5 20:27:09 EDT 2014


The branch, 4.2/force-approvals-disabled has been created
        at  f32098fd23d4f8e3de439e83869ed9b2bd121c85 (commit)

- Log -----------------------------------------------------------------
commit 4f3a234ef73288cd4a2b8c9e62357d4d9d960144
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Fri May 2 13:29:17 2014 -0400

    Force Disabled and Lifecycle on the ___Approvals queue
    
    Because ___Approvals needs to be Disabled = 2 in order to be hidden but
    still have tickets created, we fixed the display of the Enabled?
    checkbox in f294fec4.  Since some users will have enabled and then
    disabled the queue prior to coming up to 4.2, they will be unable to
    create Approvals tickets without manually going and changing the value
    in the database.
    
    The same applies to the lifecycle; because we ceased listing the
    "approvals" lifecycle in b97a61b6, merely pressing "Save Changes" on the
    __Approvals queue would unfixably alter the lifecycle to "default"
    instead of "approvals".
    
    Force ___Approvals to have the Disabled and Lifecycle values assigned on
    a new 4.2 install.

diff --git a/etc/upgrade/4.2.4/content b/etc/upgrade/4.2.4/content
index 793661c..c56e369 100644
--- a/etc/upgrade/4.2.4/content
+++ b/etc/upgrade/4.2.4/content
@@ -16,3 +16,32 @@ push @Initial, sub {
     $exist->LoadByCols( ExecModule => 'AutoOpenInactive' );
     @ScripActions = () if $exist->Id;
 };
+
+push @Initial, sub {
+    my $queue = RT::Queue->new( RT->SystemUser );
+    my ($ok, $msg) = $queue->Load('___Approvals');
+    unless ($ok) {
+        RT->Logger->warning("Unable to load ___Approvals: $msg");
+        return;
+    }
+    unless ($queue->Disabled == 2) {
+        RT->Logger->warning("Going to force ___Approvals queue to be Disabled = 2");
+        ($ok, $msg) = $queue->SetDisabled( 2 );
+        unless ($ok) {
+            RT->Logger->error("Unable to set ___Approvals.Disabled = 2: $msg");
+            return;
+        }
+    }
+
+    unless ($queue->Lifecycle eq "approvals") {
+        RT->Logger->warning("Going to force ___Approvals queue to the approvals lifecycle");
+        ($ok, $msg) = $queue->SetLifecycle( "approvals" );
+        unless ($ok) {
+            RT->Logger->error("Unable to set ___Approvals lifecycle: $msg");
+            return;
+        }
+    }
+
+    return 1;
+
+};

commit 6392911d03517a6587178b26ccb6e67f63e622f7
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Fri May 2 13:39:53 2014 -0400

    Document 4.2.4/content
    
    This is the Approvals.Disabled and Approvals.Lifecycle changes as well
    as fixing Open Inactive Tickets being missed on upgrades.

diff --git a/docs/UPGRADING-4.2 b/docs/UPGRADING-4.2
index dd21c25..cb8b2c3 100644
--- a/docs/UPGRADING-4.2
+++ b/docs/UPGRADING-4.2
@@ -310,4 +310,23 @@ equivalent results in RT 4.2.
 
 =back
 
+=head1 UPGRADING FROM 4.2.3 AND EARLIER
+
+RT 4.2.4's upgrade scripts contain two fixes to normalize upgraded RTs
+with those installed new from a release of RT 4.2.
+
+We neglected to add the "Open Inactive Tickets" action mentioned earlier
+in this documents. It was available to fresh installs but not on
+upgrades. This Scrip Action is now created if needed.
+
+RT expects the ___Approvals queue to have a special value in the
+Disabled column so that it is hidden B<but> tickets can still be created
+(normal disabled Queues disallow ticket creation).  Users who enabled
+and then disabled the Queue on earlier releases will have the incorrect
+Disabled value, so we fix that.  A similar problem applies to the
+lifecycle, which must be set to the internal "approvals" lifecycle --
+which is not listed as an option.  RT 4.2.4 also includes enhancements
+to the Queue admin page for ___Approvals to prevent editing things which
+might cause problems.
+
 =cut

commit f32098fd23d4f8e3de439e83869ed9b2bd121c85
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Fri May 2 14:04:17 2014 -0400

    Reverse SetDisabled logic checking
    
    Since a Queue can be SetDisabled(2) for ___Approvals, checking on "1
    means disabled, otherwise enabled" means that SetDisabled(2) results in
    a transaction saying "Enabled queue" which is totally backwards.

diff --git a/lib/RT/Queue.pm b/lib/RT/Queue.pm
index 46d30d7..0a642bf 100644
--- a/lib/RT/Queue.pm
+++ b/lib/RT/Queue.pm
@@ -248,19 +248,19 @@ sub SetDisabled {
     my ($ok, $msg) = $self->_Set( Field =>'Disabled', Value => $val);
     unless ($ok) {
         $RT::Handle->Rollback();
-        $RT::Logger->warning("Couldn't ".(($val == 1) ? "disable" : "enable")." queue ".$self->Name.": $msg");
+        $RT::Logger->warning("Couldn't ".(($val == 0) ? "enable" : "disable")." queue ".$self->Name.": $msg");
         return ($ok, $msg);
     }
-    $self->_NewTransaction( Type => ($val == 1) ? "Disabled" : "Enabled" );
+    $self->_NewTransaction( Type => ($val == 0) ? "Enabled" : "Disabled" );
 
     $RT::Handle->Commit();
 
     RT->System->QueueCacheNeedsUpdate(1);
 
-    if ( $val == 1 ) {
-        return (1, $self->loc("Queue disabled"));
-    } else {
+    if ( $val == 0 ) {
         return (1, $self->loc("Queue enabled"));
+    } else {
+        return (1, $self->loc("Queue disabled"));
     }
 
 }

-----------------------------------------------------------------------


More information about the rt-commit mailing list