-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Meeker wrote: >> - 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. > > Currently batch modification is done in one form. Doing it this way > 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. > > The problem I had with this is that the name of the status does not > 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.
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----- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
