As far as I can tell, there is no easy way for a scrip to provide
feedback to end users.
For example if I have a scrip that reverts a status change, the
scrip’s Commit method could return (1, “Feedback Here”) and then in
the UI, instead of just seeing:
- Ticket 8: Status changed from ‘open’ to ‘stalled’
They would also see
- Ticket 8: Can’t be stalled without a Due date. Status changed back to ‘open’
or whatever.
Is there something that already provides this functionality or would a
patch be welcomed?
Bradley Bell
Classroom Support Services | University of Washington
035 Kane Hall | Box 353095 Seattle, WA 98195-3095
p 206.543.9900 | f 206.685.7892 | www.css.washington.edu
As far as I can tell, there is no easy way for a scrip to provide
feedback to end users.
For example if I have a scrip that reverts a status change, the
scrip’s Commit method could return (1, “Feedback Here”) and then in
the UI, instead of just seeing:
- Ticket 8: Status changed from ‘open’ to ‘stalled’
They would also see
- Ticket 8: Can’t be stalled without a Due date. Status changed back to
‘open’
or whatever.
Is there something that already provides this functionality or would a
patch be welcomed?
- Scrips are not best for such things. New RT allows you to prevent
operations much easily in UI by using checks_failure (grep) and callbacks.
I thought about using callbacks instead, but there are so many places
in the UI to change things it seems like the complexity in maintenance
goes up very fast, and I’d have to keep the scrip around as well
because I’d probably miss one. I do agree that checking beforehand
would be better than reverting transaction afterwards.
-
Patch is not bad. I want user visible feedback from Scrips too.
-
Return value of Prepare/Commit methods is not good candidate. Mostly
because of backwards compatibility. I think a method in scrip action’s class
can be used, for example AddMessage or something like that.
-
If you want to see it merged into RT core then it’s better to implement
something dirty and quick, publish it for review and comments on rt-devel@
list.
I will think about implementing this, I have to figure out if it will
solve my current problems though.
Another half-baked idea: custom conditions in the lifecycle?
actions => [
'open -> stalled' => {
label => 'Stall', # loc
update => 'Comment',
condition => sub { return $_->CheckOkToStall; }
},
but of course there are many things other than status to be concerned about.
Bradley Bell
Classroom Support Services | University of Washington
035 Kane Hall | Box 353095 Seattle, WA 98195-3095
p 206.543.9900 | f 206.685.7892 | www.css.washington.edu
As far as I can tell, there is no easy way for a scrip to provide
feedback to end users.
For example if I have a scrip that reverts a status change, the
scrip’s Commit method could return (1, “Feedback Here”) and then in
the UI, instead of just seeing:
- Ticket 8: Status changed from ‘open’ to ‘stalled’
They would also see
- Ticket 8: Can’t be stalled without a Due date. Status changed back to
‘open’
or whatever.
Is there something that already provides this functionality or would a
patch be welcomed?
- Scrips are not best for such things. New RT allows you to prevent
operations much easily in UI by using checks_failure (grep) and
callbacks.
I thought about using callbacks instead, but there are so many places
in the UI to change things it seems like the complexity in maintenance
goes up very fast, and I’d have to keep the scrip around as well
because I’d probably miss one. I do agree that checking beforehand
would be better than reverting transaction afterwards.
Callbacks can return person to the same form with all data in place, so he
can adjust input to fulfill required workflow. This is huge advantage in
user friendliness.
Instead of reverting Scrip that clobbers ticket’s history you can wrap
SetStatus method and return (0, “Can’t stall without Due”). This is valid
use as we have to use SetXxx methods in most cases exactly because of such
checks unless we want to play really dirty games for some reason. Such
implementation would abort the action. It just has the same problem as
scrips - it doesn’t prevent other actions on the same form.
- Patch is not bad. I want user visible feedback from Scrips too.
-
Return value of Prepare/Commit methods is not good candidate. Mostly
because of backwards compatibility. I think a method in scrip action’s
class
can be used, for example AddMessage or something like that.
-
If you want to see it merged into RT core then it’s better to
implement
something dirty and quick, publish it for review and comments on
rt-devel@
list.
I will think about implementing this, I have to figure out if it will
solve my current problems though.
Another half-baked idea: custom conditions in the lifecycle?
actions => [
'open -> stalled' => {
label => 'Stall', # loc
update => 'Comment',
condition => sub { return $_->CheckOkToStall; }
},
but of course there are many things other than status to be concerned
about.
It’s not that bad option.
–
Bradley Bell
Classroom Support Services | University of Washington
035 Kane Hall | Box 353095 Seattle, WA 98195-3095
p 206.543.9900 | f 206.685.7892 | www.css.washington.edu
–
RT Training in Seattle, June 19-20: http://bestpractical.com/training
Best regards, Ruslan.
As far as I can tell, there is no easy way for a scrip to provide
feedback to end users.
For example if I have a scrip that reverts a status change, the
scrip’s Commit method could return (1, “Feedback Here”) and then in
the UI, instead of just seeing:
- Ticket 8: Status changed from ‘open’ to ‘stalled’
They would also see
- Ticket 8: Can’t be stalled without a Due date. Status changed back to ‘open’
or whatever.
Is there something that already provides this functionality or would a
patch be welcomed?
One concern is that RT’s Scrips were never intended to be synchronous
and if we ever move to an asynch model, then pushing messages to users
would be harder/impossibler.
Regarding your lifecycle condition suggestion, have you seen
https://metacpan.org/module/TSIBLEY/RT-Extension-MandatoryOnTransition-0.04/lib/RT/Extension/MandatoryOnTransition.pm
-kevin
One concern is that RT’s Scrips were never intended to be synchronous
and if we ever move to an asynch model, then pushing messages to users
would be harder/impossibler.
Regarding your lifecycle condition suggestion, have you seen
https://metacpan.org/module/TSIBLEY/RT-Extension-MandatoryOnTransition-0.04/lib/RT/Extension/MandatoryOnTransition.pm
I just saw that the other day. It does look useful, but I decided to
make my own extension, with api wrappers and a custom lifecycle,
because my needs are fairly specific. Feedback is provided both in the
api and using callback for purely informational things.
The project right now is a basic asset reservation system. Anyone
who’s interested can check it out here:
I welcome feedback of any kind.
Brad
Bradley Bell
Classroom Support Services | University of Washington
035 Kane Hall | Box 353095 Seattle, WA 98195-3095
p 206.543.9900 | f 206.685.7892 | www.css.washington.edu