[Rt-commit] rt branch, 4.0.21-releng, created. rt-4.0.20-43-g4a88ea8

Alex Vandiver alexmv at bestpractical.com
Wed Jul 2 15:09:22 EDT 2014


The branch, 4.0.21-releng has been created
        at  4a88ea8d1dcf42272ab19d0da52302d68c304a87 (commit)

- Log -----------------------------------------------------------------
commit 3a64944dbc1d3ef4d63116ac9fd1829dfed9a1d0
Author: Alex Vandiver <alexmv at bestpractical.com>
Date:   Mon Jun 9 18:40:54 2014 -0400

    GraphViz.pm does not depend on the libgraph.so, but rather the "dot" program
    
    This allows `configure` to better detect when GraphViz will be able to
    be installed smoothly.  It may cause additional dependencies on an
    upgrade -- however, failing to install these dependencies will not
    change RT's behaviour in any way, as the --enable-graphviz option merely
    controls default dependencies.  Enabling and disabling of the feature is
    done at startup time, based on the presence of the GraphViz module or
    the $DisableGraphViz configuration option.
    
    This also makes RT's `configure` no longer require a working gcc.

diff --git a/configure.ac b/configure.ac
index b8a9399..2dfda93 100755
--- a/configure.ac
+++ b/configure.ac
@@ -266,7 +266,7 @@ fi
 AC_SUBST(RT_DEVEL_MODE)
 
 dnl RT's GraphViz dependency charts
-AC_CHECK_LIB([graph],[aginitlib],RT_GRAPHVIZ="1")
+AC_CHECK_PROG([RT_GRAPHVIZ], [dot], "yes", "no")
 AC_ARG_WITH(graphviz,[],RT_GRAPHVIZ=$withval)
 AC_ARG_ENABLE(graphviz,
             AC_HELP_STRING([--enable-graphviz],

commit 6d885610e96775ca60d7e9d5b4e017738160bbc1
Author: Todd Wade <todd at bestpractical.com>
Date:   Mon Mar 31 12:44:15 2014 -0400

    instructions for how to add new global status
    
    In pre 4.0 versions, adding new statuses was documented well enough with
    
    http://bestpractical.com/docs/rt/3.8/RT_Config.html#ActiveStatus-InactiveStatus
    
    but with lifecycles this is no longer valid and there is no documentation
    on how to achieve this.

diff --git a/docs/customizing/lifecycles.pod b/docs/customizing/lifecycles.pod
index 29ab96b..f6612f0 100644
--- a/docs/customizing/lifecycles.pod
+++ b/docs/customizing/lifecycles.pod
@@ -6,6 +6,42 @@ But there can be any number of workflows where these status values
 don't completely fit. RT allows you to add new custom status values and
 define their behavior with a feature called Lifecycles.
 
+=head1 Adding a New Status
+
+Because Statuses are controlled via lifecycles, you must manipulate the entire
+lifecycle configuration to add a status. In earlier versions of RT new statuses
+could be added by adding a new element to an array in RT's config file. But
+because lifecyles are built around statuses, the entire lifecycle configuration
+must be modified even if you only need new statuses.
+
+=head2 Copy Lifecycle Config
+
+First, copy the C<%Lifecycles> hash from C<RT_Config.pm> and paste it into
+C<RT_SiteConfig.pm>.
+
+=head2 Add Status Value
+
+Add the status to the set where your new status belongs. This example adds
+C<approved> to the active statuses:
+
+    active => [ 'open', 'approved', 'stalled' ],
+
+=head2 Update Transitions
+
+Now the transitions section must be updated so that the new status can
+transition to the existing statuses and also so the existing statuses can
+transition to the new status.
+
+    new      => [qw(    open approved stalled resolved rejected deleted)],
+    open     => [qw(new      approved stalled resolved rejected deleted)],
+    approved => [qw(new open          stalled resolved rejected deleted)],
+    stalled  => [qw(new open approved         rejected resolved deleted)],
+    resolved => [qw(new open approved stalled          rejected deleted)],
+    rejected => [qw(new open approved stalled resolved          deleted)],
+    deleted  => [qw(new open approved stalled rejected resolved        )],
+
+=head1 Order Processing Example
+
 This guide demonstrates lifecycles using an order fulfillment
 system as a real-world example. You can find full lifecycles
 documentation in L<RT_Config/Lifecycles>.
@@ -21,12 +57,6 @@ The detailed configuration options are discussed below. Once you add it
 and restart the server, the new lifecycle will be available on the
 queue configuration page.
 
-If you want to modify the default lifecycle, you can copy it from
-C<RT_Config.pm>, paste it into C<RT_SiteConfig.pm> and make your
-changes.
-
-=head1 Order Processing Example
-
 To show how you might use custom lifecycles, we're going to configure
 an RT lifecycle to process orders of some sort. In our order example,
 each ticket in the queue is considered a separate order and the orders

commit 3be470c207d15a4171684ed048b53d93fc0f99fd
Merge: d1ee71d 6d88561
Author: Wallace Reis <wreis at bestpractical.com>
Date:   Mon Jun 30 18:12:50 2014 -0300

    Merge branch '4.0/new-status-pod' into 4.0-trunk


commit 4a88ea8d1dcf42272ab19d0da52302d68c304a87
Merge: 3be470c 3a64944
Author: Kevin Falcone <falcone at bestpractical.com>
Date:   Tue Jul 1 21:40:01 2014 -0400

    Merge branch '4.0/graphviz-detection' into 4.0-trunk


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


More information about the rt-commit mailing list