Ideas and suggestions for Trac's Ticket Workflow
This page collects ideas and suggestions for enhancing the ticket workflow.
If you have a small nice idea but don't feel like starting a discussion on the MailingList or creating a new ticket, this is the place!
Reminder about open issues
- Text box for duplicate when a bug is a duplicate
- Provide Possibility to 'freeze' a Milestone
- tickets linked to multiple versions
- [PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...
- Timeline shows incomplete information about status changes for customized workflow
- Multiple Milestone Dates
- Enterprise workflow enhancements for request info
- [patch] Workflow tweak: handle "not-state" transition specifications
- Enhancement for trac-post-commit-hook.py for Enterprise Workflow
- different types of ticket need different workflows
- Wiki page and milestone deletes aren't shown in time line
- Different workflows when viewing own tickets/others tickets
- Workflow actions not translated
- Custom Query: Column with last status change
- Implement a set_field workflow action
- Log unknown attributes in ticket workflow
- Default values of ticket workflow fields should be configured in the [ticket-workflow] section
- Workflow graph should account for user/group permissions
- Ticket workflow should support negated permissions
- Add set_owner_default attribute to specify default value of set_owner in ticket-workflow
- Workflow status change should be an explicit operation
- Status changes for other operations not handled by ConfigurableTicketWorkflow
User interface guidelines
Note: This content was copied from the TracWorkflow page. It should be reviewed.
- the "operation" could be on the nodes, possible operations are:
- preops: automatic, before entering the state/activity
- postops: automatic, when leaving the state/activity
- actions: can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows.
This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.
- operations could be anything: sum up the time used for the activity, or just write some statistical fields like
A workflow plugin can add an arbitrary workflow operation, so this is already possible.
- set_actor should be an operation allowing to set the owner, e.g. as a "preop":
- either to a role, a person
- entered fix at define time, or at run time, e.g. out of a field, or select.
This is either duplicating the existing
set_owneroperation, or needs to be clarified.
- Actions should be selectable based on the ticket type (different Workflows for different tickets)
Look into the AdvancedTicketWorkflowPlugin's
- I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state.
You could do a query on the ticket table and the ticket changes table and find out transitions between individual states and the time the ticket had been in each of the available states.
may_set_owneroperations that overrides, or replaces, the global