ruz at bestpractical
May 21, 2013, 2:01 PM
Post #4 of 6
(158 views)
Permalink
|
On Wed, May 22, 2013 at 12:18 AM, Bradley Bell <bradleyb [at] uw> wrote:
> On Tue, May 21, 2013 at 12:26 PM, Ruslan Zakirov <ruz [at] bestpractical>
> wrote:
> > On Tue, May 21, 2013 at 11:14 PM, Bradley Bell <bradleyb [at] uw> wrote:
> >>
> >> 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?
> >
> >
> > 1) 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.
> 2) Patch is not bad. I want user visible feedback from Scrips too.
> >
> > 3) 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.
> >
> > 4) 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.
|
