Workflows and Validation of Transitions
Brian Meeker
of implementing #7709 from Trac-Hacks[1]. The end result should be
that actions not defined by the workflow will be disallowed and any
operations the action defines should be applied. I am looking at the
ITicketActionController interface and its implementation in
ConfigurableTicketWorkflow. Is there a straightforward way to ask,
given a ticket and a status, if it is valid for the ticket to be
transitioned to that status? I haven't been able to find this type of
validation being done anywhere else (and didn't really expect to).
Right now I have a (buggy) hack that uses the internals of
ConfigurableTicketWorkflow, but that could easily break for other
implementations of ITicketActionController. It keeps track of which
tickets have an invalid transition. If any are invalid the entire
transaction is rolled back and an error is raised describing which
tickets are invalid.
[1]: http://trac-hacks.org/ticket/7709
Steffen Hoffmann
Hash: SHA1
Brian Meeker wrote:
> I am starting to dig into how workflows are implemented with the goal
> of implementing #7709 from Trac-Hacks[1].
Thanks for facing the challenge. This is really useful stuff.
> The end result should be
> that actions not defined by the workflow will be disallowed and any
> operations the action defines should be applied.
- From end user perspective I would most probably expect kind of selection
(drop-down?) ordered by action priority (as configured) leaving me, the
end user, with only the choice among valid actions. So you still need
the data requested, but you'll need it on ticket selection well *before*
committing the set of changes.
> I am looking at the
> ITicketActionController interface and its implementation in
> ConfigurableTicketWorkflow. Is there a straightforward way to ask,
> given a ticket and a status, if it is valid for the ticket to be
> transitioned to that status? I haven't been able to find this type of
> validation being done anywhere else (and didn't really expect to).
modules
get_ticket_actions(req, ticket) and
get_all_status()
in
class ITicketActionController(Interface)
should just give you all the needed information.
> Right now I have a (buggy) hack that uses the internals of
> ConfigurableTicketWorkflow, but that could easily break for other
> implementations of ITicketActionController. It keeps track of which
> tickets have an invalid transition. If any are invalid the entire
> transaction is rolled back and an error is raised describing which
> tickets are invalid.
>
> [1]: http://trac-hacks.org/ticket/7709
Once again, I'd recommend pre-selecting valid actions and corresponding
statuses beforehand, so you'll know, the user choice will always be
valid, same way as ticket view page does for a single ticket.
Steffen Hoffmann
(hasienda)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkzPEaQACgkQ31DJeiZFuHfiyACg0dEUdH/CTUlXvK/+NksEkZdp
K2MAn1akXdcHQog1hepvCrM7KWjKwbYf
=lmY1
-----END PGP SIGNATURE-----
Brian Meeker
> (drop-down?) ordered by action priority (as configured) leaving me, the
> end user, with only the choice among valid actions. So you still need
> the data requested, but you'll need it on ticket selection well *before*
> committing the set of changes.
breaks it into two steps. The first step is selecting the tickets to
modify. Then the user chooses what they want to change. If they want
to change the status their choices should be the intersection of the
valid actions for each ticket. I could probably even reuse the same
the same action fieldset that is used when modifying one ticket. I'm
not a huge fan into splitting it in two, but it is preferable to
adding new methods to an existing interface.
>
> > I am looking at the
> > ITicketActionController interface and its implementation in
> > ConfigurableTicketWorkflow. Is there a straightforward way to ask,
> > given a ticket and a status, if it is valid for the ticket to be
> > transitioned to that status? I haven't been able to find this type of
> > validation being done anywhere else (and didn't really expect to).
>
> modules
> get_ticket_actions(req, ticket) and
> get_all_status()
> in
> class ITicketActionController(Interface)
>
> should just give you all the needed information.
match the name of the action, but maybe I am misunderstanding the
interface. For example, given a new ticket and the default workflow,
the valid actions are leave, resolve, reassign, and accept, but the
name of the status the user could have selected is accepted, assigned,
closed, and new. I don't see any way to reliably match these names for
arbitrary workflows. The root of the problem is that I currently have
users selecting a new status instead of an action. This will have to
change.
> Once again, I'd recommend pre-selecting valid actions and corresponding
> statuses beforehand, so you'll know, the user choice will always be
> valid, same way as ticket view page does for a single ticket.
splitting it into two parts as I outlined above. I will also need to
decide whether to make this an AJAX call. Does Trac have guidelines on
this? Is the automatic comment preview the only AJAX request currently
made? Thanks for the pointers.
Remy Blank
> I will also need to
> decide whether to make this an AJAX call. Does Trac have guidelines on
> this? Is the automatic comment preview the only AJAX request currently
> made? Thanks for the pointers.
We do tend to add more an more AJAXy stuff, and the guideline (for Trac
core at least, plugins are free to do whatever they want) is that the UI
should degrade gracefully if JavaScript is not available.
The following locations currently use AJAX:
- Side-by-side wiki editor
- Ticket comment preview
- Inline source tree expansion
- Inline changeset view in annotated source file
-- Remy
Steffen Hoffmann
Hash: SHA1
Indeed, and getting even more unpredictable with custom workflows with
localized action and or status names. I could dig for an example, if
you'd need to see one.
> I don't see any way to reliably match these names for arbitrary
> workflows. The root of the problem is that I currently have users
> selecting a new status instead of an action. This will have to
> change.
I strongly agree. Module render_ticket_action_control() has all the
needed information AFAIK, but not readily available, as it does what
better should be done in two steps: action->(valid) status mapping and
rendering of the actions list. If it is not already an enhancement
request, you should go and create it. :-)
>> Once again, I'd recommend pre-selecting valid actions and
>> corresponding statuses beforehand, so you'll know, the user choice
>> will always be valid, same way as ticket view page does for a
>> single ticket.
>
> Assuming my current understanding is correct, I agree. I will look at
> splitting it into two parts as I outlined above. I will also need to
> decide whether to make this an AJAX call. Does Trac have guidelines
> on this? Is the automatic comment preview the only AJAX request
> currently made? Thanks for the pointers.
You may find interesting(related) code in WatchlistPlugin's dev branch.
Current version actually does a lot of interactive actions without the
need to reload the web page. I can't produce such code myself, but I
guess there is a big space of possibilities within the AJAX approach,
that could even merge the 'two step' design back into one (page).
Steffen Hoffmann
(hasienda)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkzQe2wACgkQ31DJeiZFuHdpqgCgn5fbstDZkNOye4QN/ob5VMtB
6tYAnjOSq+VwEYcDHFreIT85A+WFPjI5
=l/er
-----END PGP SIGNATURE-----
osimons
hints and more. I needed this for the TracRPC plugin (XmlRpcPlugin),
but as I also needed the "fundamental" data for use by any type of
client, I also needed to de-compose the information as much if it
leaves TicketSystem (or plugins) only as rendered html fragments. This
entangling is not pretty, it makes any equals-matching of content more
difficult, and it just plain harder to reuse. If you can't reuse the
Trac action controls as-is, you need to start poking into the
internals as I did for TracRPC ticket.getActions() method. You may
want to have a look at it:
http://trac-hacks.org/browser/xmlrpcplugin/trunk/tracrpc/ticket.py#L97
:::simon
https://www.coderesort.com
http://trac-hacks.org/wiki/osimons
Eli Carter
> I am starting to dig into how workflows are implemented with the goal
> of implementing #7709 from Trac-Hacks[1]. The end result should be
> that actions not defined by the workflow will be disallowed and any
> operations the action defines should be applied. I am looking at the
> ITicketActionController interface and its implementation in
> ConfigurableTicketWorkflow. Is there a straightforward way to ask,
> given a ticket and a status, if it is valid for the ticket to be
> transitioned to that status? I haven't been able to find this type of
> validation being done anywhere else (and didn't really expect to).
Not directly. You could ask for each ticket, for each action available on
that ticket, what the resulting status will be. Then see if there is at least
one way to transition to that status. But you can't ask 'can this ticket
transition to that status' directly. Also note the 'at least one way'...
different actions may legitimately transition to the same status, but do
different things.
> Right now I have a (buggy) hack that uses the internals of
> ConfigurableTicketWorkflow, but that could easily break for other
> implementations of ITicketActionController. It keeps track of which
> tickets have an invalid transition. If any are invalid the entire
> transaction is rolled back and an error is raised describing which
> tickets are invalid.
>
> [1]: http://trac-hacks.org/ticket/7709
Something to keep in mind is that the Trac workflow is built around _actions_,
not _states_. I suspect people expect it to be state-based, and it kind of
looks like it is, and so people get a bit confused. But the workflow design
is intended to allow you to take actions on a ticket based on what the current
state is. That action often changes the state as part of what it does, but it
is not required to.
The way I use Trac and Svn, I create a branch in subversion for each ticket
that I work on.[1] The ticket has a 'branch' action, and once branched, it
will have a 'merge' action to merge it into what it was branched from.[2]
Other possible actions for tickets when using a branch-per-ticket, would be to
have a 'build' or 'run tests' action. Actions like that may not change the
state of the ticket. Or may trigger some automated process that will come
back at some later time and take another action on the ticket.
The ticket workflow code is far from perfect, and really needs a thorough re-
work, but I haven't had a chance to spend time on Trac since PyCon. :( I
tried to make it very extensible (the operations stuff), and allow people to
nearly completely replace the way the workflow is implemented using a plugin.
I don't think I succeeded in that as well as I would have liked.
If you look at the bugs filed against the AdvancedTicketWorkflowPlugin on
trac-hacks, you will also find that we need to have a way of describing
changes to arbitrary ticket fields, and the data used for ticket previews
needs to be reworked so we track both changes a user made directly as well as
the changes made by a workflow action so we can handle "preview, change
action, preview" correctly.
HTH,
Eli
[1] This is using my "mergebot" plugin for Trac, which you can find on
retracile.net. My coworkers _love_ this thing. It may seem odd, but it works
well and makes our lives much easier.
[2] The ticket action version of mergebot is not currently in production use;
a prior method is, so the described functionality may currently be broken. It
has been a while since I could make time for mergebot work. :( The _next_
round of layoffs may change that... :/
-----------------------. "If it ain't broke now,
EliC...@retracile.net \ it will be soon." -- crypto-gram
http://retracile.net `--------------------------------------------
Brian W
Remy Blank
> Where in the TracDev Wiki can I find these guidelines? What is the
> reason to still support non-JavaScript users?
Well, it's not a hard rule, rather it's what we have always done up to
now and has served us well. You can do all possible actions in Trac
without JavaScript. The functionality you don't get are just
nice-to-haves, and not mandatory to operate a Trac site.
For example, editing a ticket query with JavaScript is nice and fast. If
you don't have JavaScript, you still have the complete functionality,
but you must submit the form much more often (e.g. to add a field). This
makes the process longer, but everything still works. That's what I
meant with "graceful degradation".
Or take wiki page editing. If you have JavaScript, you get a nice
side-by-side editor with automatic preview. If you don't have
JavaScript, you need to submit the form with "Preview" to get the page
preview.
If we were to drop the "must work without JavaScript" guideline, we
could give Trac a completely different (and more dynamic) UI, like Gmail
or Google Docs, for example. That could certainly be nice, but nobody
has shown interest in doing that up to now.
We usually don't use the <noscript> tag, though, we have JavaScript-only
parts of a page hidden by default, and shown through JavaScript on load.
-- Remy
Noah Kantrowitz
On Jul 5, 2011, at 6:38 PM, Brian W wrote:
> Remy,
>
> Where in the TracDev Wiki can I find these guidelines? What is the reason to still support non-JavaScript users? I understand people may use plugins like NoScript, but a user of Trac can be informed via a <noscript> tag if JavaScript is required even though this isn't quite as graceful. My main reason for asking is in regards to plugins. Even though you say a plugin can do what they want, understanding the motivation for Trac's graceful degradation guideline may help inspire a plugin developer to do the same. If a Trac instance with several plugins installed violates a Trac core principle by introducing a JavaScript requirement, then I feel like it would undermine your efforts.
Supporting non-JS also generally encourages saner designs, especially around things like accessibility. Is there something in Trac that would be noticeably improved by requiring JS?
--Noah