[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