> - 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. 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. 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 received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
