Edgewall Software
Modify

Opened 11 years ago

Closed 10 years ago

Last modified 9 years ago

#8144 closed enhancement (wontfix)

set_status workflow operation

Reported by: gray.trac@… Owned by:
Priority: normal Milestone:
Component: ticket system Version: none
Severity: normal Keywords: needinfo
Cc: Branch:
Release Notes:
API Changes:

Description

So we have a large number of workflow steps: Design Q, Design Active, Dev Q, Dev Active, QA Q, …

Our PM folks create a task and then need to set its status so it goes into the right queue.

I've added a set_status command which gives a status pulldown.

Thanks _much_ for trac. We are loving it!

Attachments (2)

default_workflow.py.patch (1.5 KB ) - added by Gray Watson <gray.trac@…> 11 years ago.
Patch for default_workflow.py from 0.10.4.
set_status_example.txt (257 bytes ) - added by Gray Watson <gray.trac@…> 11 years ago.
set_status configuration example

Download all attachments as: .zip

Change History (7)

by Gray Watson <gray.trac@…>, 11 years ago

Attachment: default_workflow.py.patch added

Patch for default_workflow.py from 0.10.4.

by Gray Watson <gray.trac@…>, 11 years ago

Attachment: set_status_example.txt added

set_status configuration example

comment:1 by Christian Boos, 11 years ago

Keywords: needinfo added

Well, I wonder if that wouldn't be better served by a custom field.

Usually the TracWorkflow uses the status to reflect the evolution of a ticket, according to some precise rules. If you can set arbitrary status, that kind of defeats the purpose…

OTOH, you already have the StatusFixer plugin…

comment:2 by anonymous, 11 years ago

The problem is with complex workflows that you need to often jump the queue. Someone clicks the wrong button, some needs to move it to another state. An admin doesn't have to configure the set_status into their workflow but the functionality is critical for us and I suspect I'm not the only one. Right now we have the following workflow steps:

new → pdm queue → pdm active

→ design queue → design active → dev queue → dev active → qa queue → qa active → integration test → ops queue → ops active → deferred → declined → closed → reopened

A developer gets something, starts on it putting it in dev active, sends it to QA who needs to punt it back to the design queue because of a missing graphic.

Without the set status button, the number of different combinations approaches infinity. And, as admin, I would not want to have people ping me to fix a trac whenever we need to move it to another status.

Thanks.

comment:3 by anonymous, 11 years ago

In terms of a status field, we started with that but we really like the workflow steps and missed the other support that the status field has in terms of reporting and features. I still want my developers to use the workflow: dev-start to dev-complete to qa-queue to qa-active to reopened, etc..

But there are many of such queues (design, dev, qa, ops, business) and [again] all combinations approach infinity.

Thanks.

comment:4 by Christian Boos, 10 years ago

Resolution: wontfix
Status: newclosed

To me, the proposed patch seems to be defeating the purpose of the "controlled steps" approach of the workflow.

For your scenario in comment:2, in order to avoid a combinatorial explosion, you could define a few "restart" points, like the beginning of each "queue", and have them reachable from all the other states, or even from a single retriage state:

  • state x: you detect there's a problem with the current state, you need to restart from somewhere else (as in comment:2, missing graphics)
  • state x → state retriage, with a comment explaining why things have to be restarted ("missing graphics")
  • state retriage → state design queue, with or without a comment explaining in more details what has to be done ("please add an icon for the xyz menu entry, which should look like…")

Anyway, the patch looks good and might be useful in some specific cases, so maybe this could be contributed to the TracHacks:AdvancedTicketWorkflowPlugin?

in reply to:  4 comment:5 by anonymous, 9 years ago

Here is the code to add set_status to AdvancedTicketWorkflowPlugin

  • Modify controller.py and add the following code.
    import shlex
    ...
    class TicketWorkflowOpSetStatus(TicketWorkflowOpBase):
        """Sets the status
    
        Don't forget to add the `TicketWorkflowOpSetStatus` to the workflow
        option in [ticket].
        If there is no workflow option, the line will look like this:
    
        workflow = ConfigurableTicketWorkflow,TicketWorkflowOpSetStatus
        """
    
        _op_name = 'set_status'
    
        # ITicketActionController methods
    
        def render_ticket_action_control(self, req, ticket, action):
            """Returns the action control"""
            splitter = shlex.shlex(self.config.get('ticket-workflow',
                                action + '.' + self._op_name), posix=True)
            splitter.whitespace += ','
            splitter.whitespace_split = True
            field = list(splitter)
            if len(field) > 0:
              options = field
            else:
              options = [val.name for val in model.Status.select(self.env)]
            id = action + "_new_status"
            selected_option = req.args.get(id, '')
            actions = self.get_configurable_workflow().actions
            label = actions[action]['name']
            control = tag(['to ', tag.select(
                          [tag.option(x, selected = (x == selected_option and "selected" or ""))
                           for x in options],
                          id = id, name = id)])
            new_status = req.args.get(action + '_new_status')
            if new_status != self._old_status(ticket):
                hint = 'The status will change to %s' % new_status
            else:
                hint = ''
            return (label, control, hint)
    
        def get_ticket_changes(self, req, ticket, action):
            """Returns the change of status."""
            return {'status': req.args.get(action + '_new_status')}
    
        def _old_status(self, ticket):
            """Determines what the ticket state was (is)"""
            return ticket._old.get('status', ticket['status'])
    
        def _new_status(self, req, ticket):
            status = req.args.get(action + '_new_status')
            if status != '':
              return status
            else:
              return self._old_status(ticket)
    

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.