[Bps-public-commit] RT-Extension-MandatoryOnTransition branch, master, updated. 0.13-10-gb44e9c7
Jim Brandt
jbrandt at bestpractical.com
Fri Oct 14 11:55:08 EDT 2016
The branch, master has been updated
via b44e9c78b6ab4de343f625a95ecfcda4fb71f376 (commit)
via 10d196f4391e05edfb1647edb11b9a9317b102e5 (commit)
via 5b443cddb0c4a73fc18a6d54420f399223dc0a05 (commit)
from f44b7229eec0a660065b0e6bed0f13683b722b38 (commit)
Summary of changes:
Changes | 3 ++
MANIFEST | 2 +-
META.yml | 2 +-
README | 27 ++++++++++-
lib/RT/Extension/MandatoryOnTransition.pm | 57 +++++++++++++++++++----
lib/RT/Extension/MandatoryOnTransition/Test.pm.in | 10 ----
xt/mandatory_on_create.t | 3 +-
7 files changed, 79 insertions(+), 25 deletions(-)
- Log -----------------------------------------------------------------
commit 5b443cddb0c4a73fc18a6d54420f399223dc0a05
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Oct 14 11:25:28 2016 -0400
Add labels for error messages
For error messages, specifically for queue change restrictions,
load the destination queue object and provide the queue name
for the user in the message. Keep the same hash structure for field names
so error messages can continue to support multiple transition
types.
diff --git a/lib/RT/Extension/MandatoryOnTransition.pm b/lib/RT/Extension/MandatoryOnTransition.pm
index 2ceef95..3a8602a 100644
--- a/lib/RT/Extension/MandatoryOnTransition.pm
+++ b/lib/RT/Extension/MandatoryOnTransition.pm
@@ -359,6 +359,20 @@ sub CheckMandatoryFields {
my $ARGSRef = $args{'ARGSRef'};
my @errors;
+ # Labels for error messages
+ my %field_label;
+ $field_label{'Status'} = $ARGSRef->{'Status'};
+
+ if ( $ARGSRef->{'Queue'} ){
+ # Provide queue name instead of id for errors and retain
+ # status handling.
+ my $dest_queue_obj = RT::Queue->new(RT->SystemUser);
+ my ($ret, $msg) = $dest_queue_obj->Load($ARGSRef->{'Queue'});
+ RT::Logger->error("Unable to load queue for id " . $ARGSRef->{'Queue'} . " $msg")
+ unless $ret;
+ $field_label{'Queue'} = $dest_queue_obj->Name;
+ }
+
# Some convenience variables set depending on what gets passed
my ($CFs, $CurrentUser);
if ( $args{'Ticket'} ){
@@ -379,7 +393,7 @@ sub CheckMandatoryFields {
Queue => $args{'Queue'} ? $args{'Queue'}->Name : undef,
From => $args{'From'},
To => $args{'To'},
- NewQueue => $$ARGSRef{'Queue'},
+ NewQueue => $$ARGSRef{'Queue'},
);
return \@errors unless @$core or @$cfs;
@@ -404,7 +418,7 @@ sub CheckMandatoryFields {
(my $label = $field) =~ s/(?<=[a-z])(?=[A-Z])/ /g; # /
push @errors,
$CurrentUser->loc("[_1] is required when changing [_2] to [_3]",
- $label, $CurrentUser->loc($transition), $CurrentUser->loc($ARGSRef->{$transition}));
+ $label, $CurrentUser->loc($transition), $CurrentUser->loc($field_label{$transition}));
}
return \@errors unless @$cfs;
@@ -471,12 +485,12 @@ sub CheckMandatoryFields {
if ( @must_be > 1 ){
push @errors,
$CurrentUser->loc("[_1] must be one of: [_4] when changing [_2] to [_3]",
- $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($ARGSRef->{$transition}), $valid_values);
+ $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($field_label{$transition}), $valid_values);
}
else{
push @errors,
$CurrentUser->loc("[_1] must be [_4] when changing [_2] to [_3]",
- $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($ARGSRef->{$transition}), $valid_values);
+ $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($field_label{$transition}), $valid_values);
}
next;
}
@@ -490,12 +504,12 @@ sub CheckMandatoryFields {
if ( @must_not_be > 1 ){
push @errors,
$CurrentUser->loc("[_1] must not be one of: [_4] when changing [_2] to [_3]",
- $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($ARGSRef->{$transition}), $valid_values);
+ $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($field_label{$transition}), $valid_values);
}
else{
push @errors,
$CurrentUser->loc("[_1] must not be [_4] when changing [_2] to [_3]",
- $cf->Name, $CurrentUser->loc($transition),$CurrentUser->loc($ARGSRef->{$transition}), $valid_values);
+ $cf->Name, $CurrentUser->loc($transition),$CurrentUser->loc($field_label{$transition}), $valid_values);
}
next;
}
@@ -510,7 +524,7 @@ sub CheckMandatoryFields {
push @errors,
$CurrentUser->loc("[_1] is required when changing [_2] to [_3]",
- $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($ARGSRef->{$transition}));
+ $cf->Name, $CurrentUser->loc($transition), $CurrentUser->loc($field_label{$transition}));
}
return \@errors;
commit 10d196f4391e05edfb1647edb11b9a9317b102e5
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Oct 14 11:34:18 2016 -0400
Use RTs standard cmp_version function
diff --git a/lib/RT/Extension/MandatoryOnTransition/Test.pm.in b/lib/RT/Extension/MandatoryOnTransition/Test.pm.in
index 87d127c..c3d08b5 100644
--- a/lib/RT/Extension/MandatoryOnTransition/Test.pm.in
+++ b/lib/RT/Extension/MandatoryOnTransition/Test.pm.in
@@ -48,14 +48,4 @@ CONFIG
require RT::Extension::MandatoryOnTransition;
}
-sub RTAtorNewerThan{
- my $version = shift;
- my ($my_major, $my_minor, $my_sub) = split(/[\.\-]/, $version);
- my ($major, $minor, $sub) = split(/[\.\-]/, $RT::VERSION);
- return ($my_major <= $major
- and $my_minor <= $minor
- and $my_sub <= $sub)
- ? 1 : 0;
-}
-
1;
diff --git a/xt/mandatory_on_create.t b/xt/mandatory_on_create.t
index 7224844..6511c86 100644
--- a/xt/mandatory_on_create.t
+++ b/xt/mandatory_on_create.t
@@ -32,8 +32,7 @@ diag "Test mandatory fields on create";
fields => { Queue => 'General',},
}, 'Click button to create ticket');
- print STDERR RT::Extension::MandatoryOnTransition::Test::RTAtorNewerThan('4.3.0');
- if (RT::Extension::MandatoryOnTransition::Test::RTAtorNewerThan('4.4.0')){
+ if (RT::Handle::cmp_version( '4.4.0', $RT::VERSION) <= 0) {
$m->title_is('Create a new ticket in General');
}
else{
commit b44e9c78b6ab4de343f625a95ecfcda4fb71f376
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Oct 14 11:54:05 2016 -0400
Update docs, prep for 0.14 release
diff --git a/Changes b/Changes
index fcad7e6..4c4ee65 100644
--- a/Changes
+++ b/Changes
@@ -1,3 +1,6 @@
+0.14 2016-10-14
+ - Add ability to mark fields as mandatory on queue transitions
+
0.13 2016-07-14
- Packaging fixes; reinstate latest Module::Install::RTx. Fixes
cpan#116138.
diff --git a/MANIFEST b/MANIFEST
index 858f773..868663b 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -36,4 +36,4 @@ README
xt/basic.t
xt/mandatory_on_create.t
xt/required_fields.t
-SIGNATURE Public-key signature (added by MakeMaker)
+
diff --git a/META.yml b/META.yml
index 24417f5..e1ea526 100644
--- a/META.yml
+++ b/META.yml
@@ -27,6 +27,6 @@ requires:
resources:
license: http://opensource.org/licenses/gpl-license.php
repository: https://github.com/bestpractical/rt-extension-mandatoryontransition
-version: '0.13'
+version: '0.14'
x_module_install_rtx_version: '0.38'
x_requires_rt: 4.0.9
diff --git a/README b/README
index 1e47690..85ef7e8 100644
--- a/README
+++ b/README
@@ -18,7 +18,8 @@ DESCRIPTION
Supported fields
This extension only enforces mandatory-ness on defined status
- transitions.
+ transitions. It also supports defining mandatory fields when
+ transitioning a ticket from one queue to another.
Basics
Currently the following are supported:
@@ -108,13 +109,35 @@ CONFIGURATION
'* -> resolved' => ['TimeWorked', 'CF.Resolution'],
},
'*' => {
- '* -> resolved' => 'CF.Category',
+ '* -> resolved' => ['CF.Category'],
},
);
The transition syntax is similar to that found in RT's Lifecycles. See
perldoc /opt/rt4/etc/RT_Config.pm.
+ Restrictions on Queue Transitions
+ The default behavior for MandatoryOnTransition operates on status
+ transitions, so a change from new to open or from open to resolved. It
+ also supports making fields mandatory when transitioning from one queue
+ to another. To define fields that are required when changing the queue
+ for a ticket, add an entry to the configuration like this:
+
+ Set( %MandatoryOnTransition,
+ Helpdesk => {
+ 'Engineering' => ['CF.Category'],
+ },
+ );
+
+ The key is the destination queue and the values are the mandatory
+ fields. In this case, before a user can move a ticket from the Helpdesk
+ queue to the Engineering queue, they must provide a value for Category,
+ possibly something like "bug" or "feature request".
+
+ Note that this configuration makes the most sense if the custom fields
+ are applied to both queues. Otherwise the users on the destination queue
+ won't be able to see the required values.
+
Requiring or Restricting Specific Values
Sometimes you want to restrict a transition if a field has a specific
value (maybe a ticket can't be resolved if System Status = down) or
diff --git a/lib/RT/Extension/MandatoryOnTransition.pm b/lib/RT/Extension/MandatoryOnTransition.pm
index 3a8602a..e7c125f 100644
--- a/lib/RT/Extension/MandatoryOnTransition.pm
+++ b/lib/RT/Extension/MandatoryOnTransition.pm
@@ -2,7 +2,7 @@ use strict;
use warnings;
package RT::Extension::MandatoryOnTransition;
-our $VERSION = '0.13';
+our $VERSION = '0.14';
=head1 NAME
@@ -27,6 +27,8 @@ See the configuration example under L</INSTALLATION>.
=head2 Supported fields
This extension only enforces mandatory-ness on defined status transitions.
+It also supports defining mandatory fields when transitioning a ticket
+from one queue to another.
=head3 Basics
@@ -136,13 +138,36 @@ Category selection before resolving tickets in every other queue.
'* -> resolved' => ['TimeWorked', 'CF.Resolution'],
},
'*' => {
- '* -> resolved' => 'CF.Category',
+ '* -> resolved' => ['CF.Category'],
},
);
The transition syntax is similar to that found in RT's Lifecycles. See
C<perldoc /opt/rt4/etc/RT_Config.pm>.
+=head2 Restrictions on Queue Transitions
+
+The default behavior for C<MandatoryOnTransition> operates on status transitions,
+so a change from C<new> to C<open> or from C<open> to C<resolved>. It also supports
+making fields mandatory when transitioning from one queue to another. To define
+fields that are required when changing the queue for a ticket, add an entry to
+the configuration like this:
+
+ Set( %MandatoryOnTransition,
+ Helpdesk => {
+ 'Engineering' => ['CF.Category'],
+ },
+ );
+
+The key is the destination queue and the values are the mandatory fields. In this
+case, before a user can move a ticket from the Helpdesk queue to the
+Engineering queue, they must provide a value for Category, possibly something like
+"bug" or "feature request".
+
+Note that this configuration makes the most sense if the custom fields are applied
+to both queues. Otherwise the users on the destination queue won't be able to see
+the required values.
+
=head2 Requiring or Restricting Specific Values
Sometimes you want to restrict a transition if a field has a specific
-----------------------------------------------------------------------
More information about the Bps-public-commit
mailing list