Edgewall Software
Modify

Opened 9 years ago

Closed 6 years ago

Last modified 6 years ago

#869 closed defect (fixed)

Cumulative patch: New workflow system for tickets in Trac

Reported by: pkou@… Owned by: athomas
Priority: high Milestone: 0.11
Component: ticket system Version: devel
Severity: critical Keywords: workflow
Cc: addy.bhardwaj@…, pkou@…, nvihinen@…, dserodio@…, swalker@…, martin.d.johansson@…, tracissue@…, mrovner@…, ciaran.hennessy@…, dmlee@…, vyt@…, gytis@…, bene@…, maze@…, guillaume.tardif@…, barry.kaplan@…, shishz@…, trac@…, nicpottier@…, nick+trac@…, number5@…, nwhite@…, mjh-trac-tickets@…, rob.duncan@…, rmota@…, seemant@…, junk@…, fonolit@…, rhind@…, kevin@…, wfragg@…, rapin.s@…, trac.tickets@…, ged-trac-workflow@…, dombly@…, avif@…, d-sleeman@…, sstarr@…, deepak.jois@…, ronald.berger@…, yellen@…, sgeertgens@…, trac@…, e@…, trac.20.nickread@…, martin.marcher@…, pradeep.varadarajan@…, mmay@…, sdyson@…, peter.valtersson@…, sungje@…
Release Notes:
API Changes:

Description

A new workflow system is proposed (including implementation). See NewWorkflow for details. It includes the patch and comprehensive description of the changes.

Related tickets: #563, #301 (probably more).

IMHO it is one of most important features that need to be added to Trac.

Attachments (2)

patch-customworkflow-r1064.diff (24.3 KB) - added by pkou <pkou at ua.fm> 9 years ago.
Support customized workflows in Trac
patch-customworkflow-r1098-2.diff (31.0 KB) - added by pkou <pkou at ua.fm> 9 years ago.
Patch for the changes: Synchonized with trunk, changed according to comments on previous implementation

Download all attachments as: .zip

Change History (116)

comment:1 Changed 9 years ago by pkou <pkou at ua.fm>

The patch in NewWorkflow has been updated and changes not related to workflow system have been removed (they have been registered as separate tickets #877, #878, #879, and #880).

I do not see anything that can be simplified or improved for now. Thus, I am waiting for comments from Trac development team.

I would not like to apply the patch to my real projects because it changes database structure. Until I get a feedback, there is a risk than next database change will break compatibility between Trac code and NewWorkflow code.

Thoughts?

comment:2 Changed 9 years ago by cmlenz

First a couple of random thoughts on the proposal:

The one thing that I think is dangerous is that the workflow_version option is a pretty big switch that goes through the code-base, i.e. the "if workflow_version..." conditionals are too distributed.

Object-oriented programming theory says to use polymorphism instead of conditionals, so how about something like:

class SimpleWorkflow:

    def available_actions(self, ticket):
        if ticket['status'] in ['new', 'reopened']:
            actions = [ 'accept', 'reassign', 'resolve' ]
        elif ticket['status'] == 'assigned':
            actions = [ 'reassign', 'resolve' ]
        elif ticket['status'] == 'closed':
            actions = [ 'reopen' ]

    def ticket_changed(self, ticket, user, action, args):
        if action == 'accept':
            ticket['status'] =  'assigned'
            ticket['owner'] = user or ''
        if action == 'resolve':
            ticket['status'] = 'closed'
            ticket['resolution'] = args.get('resolve_resolution')
        elif action == 'reassign':
            ticket['owner'] = args.get('reassign_owner')
            ticket['status'] = 'new'
        elif action == 'reopen':
            ticket['status'] = 'reopened'
            ticket['resolution'] = ''


class ExtendedWorkflow:

   def get_actions(self, ticket, user):
        if ticket['status'] in ['new', 'reopened']:
            actions = [ 'accept', 'reassign', 'resolve' ]
        elif ticket['status'] == 'assigned':
            actions = [ 'reassign', 'resolve' ]
        elif ticket['status'] == 'resolved':
            actions = [ 'reopen', 'verify' ]
        elif ticket['status'] == 'verified':
            actions = [ 'reopen', 'close' ]
        elif ticket['status'] == 'closed':
            actions = [ 'reopen' ]

    def do_action(self, ticket, user, action, arg):
        if action == 'accept':
            ticket['status'] = 'assigned'
            ticket['owner'] = user or ''
        if action == 'resolve':
            ticket['status'] = 'resolved'
            ticket['resolution'] = arg
        elif action == 'reassign':
            ticket['status'] = 'new'
            ticket['owner'] = arg
        elif action == 'verify':
            ticket['status'] = 'new'
            ticket['owner'] = # XXX: get QA owner
        elif action == 'reopen':
            ticket['status'] = 'reopened'
            ticket['resolution'] = ''
        # XXX: etc

The ticket system/class would delegate to the workflow implementation where appropriate. The user would select between different workflows in trac.ini:

[ticket]
workflow = simple|extended

One could imagine users even plugging in custom workflow implementations by specifying the fully qualified name of the class:

[ticket]
workflow = mypackage.workflow.MyWorkflow

I think such an approach would also allow a more controlled introduction of the advanced workflow you propose: first refactor the ticket workflow so that it's basically pluggable, then add the new workflow implementation, together with the other changes such as adding qaowners to components, owners to milestones, etc.

What do you think?

Otherwise I think the patch is very high quality, and the feature has been requested often enough that we should seriously consider adding it to Trac. The best way forward would be (IMHO) to get you svn write access to a private branch in the repository (say pkou-dev/workflow), and try to merge the branch into trunk for 0.9 as soon as we all think it's ready.

BTW, I think attaching the patches to this ticket instead of to the Wiki page would be more appropriate.

comment:3 Changed 9 years ago by pkou <pkou at ua.fm>

I like the idea with removing workflow_version and replacing it with a parameter that specifies a workflow class. This will give us flexible customization of a workflow for tickets. I will be working on this implementation.

One of interesting moments here is that it is possible to move action-specific HDF code from Ticket.cs into separate files. The Ticket.cs should include a file with actions using code like:

 <?cs include ticket.workflow.actions_template ?>

and a workflow class should have a method that returns the name of included file, e.g.

class SimpleWorkflow:
    def get_actions_template(self, ticket, user):
        return 'Ticket_simple.cs'

class ExtendedWorkflow:
    def get_actions_template(self, ticket, user):
        # possible changes: return different templates depending on ticket fields
        # and/or logged user
        return 'Ticket_extended.cs'

What do you think about this approach?

Also, it seems to be a good idea to have a commonly accessible place in SVN where we can change code. Let's discuss the details via email. I would also agree with proposed approach: Refactor current code first, and then apply changes that are specific to new workflow.

p.s.: The patches have been attached to Wiki page because it is necessary to maintain change history for the sources. I would like to suggest to keep the change history with NewWorkflow page even if we switch from patches to SVN repository. This way everybody can communicate with each other and describe additional changes that are made. And at the end we will have a good documentation for the change.

p.p.s: Thank you for the feedback.

Changed 9 years ago by pkou <pkou at ua.fm>

Support customized workflows in Trac

comment:4 Changed 9 years ago by pkou <pkou at ua.fm>

Attached patch refactors existing code in trac/Ticket.py, templates/ticket.cs, and templates/newticket.cs in order to support customized workflows in Trac.

Note that the patch does not implement enhanced workflow, it just refactors existing code for existing workflow. However, the patch in NewWorkflow contains both this refactoring and support for enhanced workflow.

Section Refactoring of Trac code for easy support of customized workflows in NewWorkflow describes the changes with more details.

comment:5 Changed 9 years ago by cmlenz

One thing I do not like about this patch is the coupling of workflow classes with templates. Templates are part of the web presentation layer, and backend/logic classes such as the workflow implementations should not need to know or even care about them.

(Granted, the separation between presentation and backend/logic isn't strong or even existant in the current code base, but that's something we need to move away from, not move closer to.)

So ideally, the workflow classes would somehow export a data structure that gives the normal ticket template enough information to display the available options. Going back to my initial example code, maybe something like:

class SimpleWorkflow:

    def available_actions(self, ticket):
        if ticket['status'] in ['new', 'reopened']:
            return [
                ('accept', None),
                ('reassign', 'owner'),
                ('resolve', 'resolution')
            ]
        elif ...

I don't think there's any other information than the new owner (reassign) or the new resolution (resolve etc) that we'd need on status changes, so such an approach may work. Probably, we'll also want to provide a hook for workflows to determine the available resolutions per status change, for example:

class SimpleWorkflow:

    def available_resolutions(self, ticket, newstatus):
        if newstatus == 'resolve':
            return [ 'fixed', 'invalid', 'duplicate', 'worksforme' ]
        return []

You get the idea.

And going into nitpicking mode, I think on_create would be a better method name than on_insert, as the latter is too SQL-layerish, and the Ticket class also uses create.

Changed 9 years ago by pkou <pkou at ua.fm>

Patch for the changes: Synchonized with trunk, changed according to comments on previous implementation

comment:6 Changed 9 years ago by pkou <pkou at ua.fm>

New patch attached. Changes:

  • Sources synchronized with trunk;
  • Workflow operations on_insert and on_update renamed to on_create and on_save in order to match Trac conventions for tickets;
  • Additional workflow contributed in order to prove current implementation (see below).

It seems that we have different vision on this issue and I would like to explain why current design is implemented as it is.

Trac has rather good separation between presentation layer and business logic. There are three types of entities:

  • Python source code for business logic;
  • ClearSilver templates for presentation layer. However, the templates are linked to business logic in terms of data that is passed between these layers;
  • CSS templates for presentation layer.

An attempt to develop a customized workflow without appropriate changes in templates will not give a big value for developers of customized workflows.

Let's review what we cover by term customized workflow:

  • It does not change statuses for tickets. Although this is an interesting idea, it is not discussed here. Many other places in Trac depend on statuses (timeline, milestone, reports, etc) and a separate research needs to be done for this task;
  • A customized workflow does allow to customize actions on a ticket;
  • A customized workflow allows to implement custom fields within an action. Examples of such fields include 1) ticket owner changes; 2) resolution field; 3) other fields like time that is spent on an action.

Thus, the idea behind current implementation is the following: Trac provides enough statuses natively but transitions between these statuses can be fully customized and extended. Currently, it is even possible to implement actions for new tickets, which can be a nice feature for some workflows.

A workflow developer should be responsible for the following areas:

  • Which actions are allowed;
  • Which additional parameters should be entered for an action:
    • A workflow should manage owner changes;
    • A workflow should manage resolution changes;
    • A workflow can manage other action-specific fields.
  • Validation rules for a ticket;
  • Automatic field calculation.

All these responsibilities depend on 1) ticket status; 2) other ticket fields; 3) currently logged user; and 4) current environment parameters for a project.

In order to prove this concept, I would like to ask you to review two custom workflows that have been developed:

  • QaRmtWorkflow - See NewWorkflow for details;
  • TimeTrackWorkflow - available in attached patch. It is implementation that subclasses any other workflow in order to allow users to specify time that they spend on an action.

It is important to underline that

  1. These workflows do not require any changes in ticket-specific code in Trac;
  2. These workflows do require changes in templates (at least I do not see a possibility to implement these workflows without appropriate changes in templates).

Thus, if fields owner and resolution are managed in main Trac code, we lose an important feature: It will not be possible to implement additional workflow-specific fields like time-for-action.

What I would like to suggest is to leave minimal support for owner and resolution fields in main Trac code. The rest should be done by workflow classes. With attached patch, owner and resolution have minimal meaning in main code already. As an option, it is possible to remove resolution constants from table enum and make a workflow responsible for generating this list.

If we follow your proposal, then we will need to add code specific for owner and resolution in main Trac code. And this will not solve the whole problem because templates will need to be changed in order to add new actions.

Ugh, I finished :-)

comment:7 Changed 9 years ago by anonymous

Is there any update on this ticket?

I'm interested in using the patches, but would like to know that they are going to be committed. I'm in the process of writing conversion routines for our own custom tracking software for use with Trac, but I need the functionality offered by the patch. I've spent some time looking at just writing the custom fields using TracTicketsCustomFields. They do not seem to be a full solution to the problem as they do not address the issue of the two additional status codes (resolved and verified) or the workflow transitions to the respective entities.)

Thanks for the update.

comment:8 Changed 9 years ago by anonymous

  • Cc nvihinen@… added

My engineering organization is also very interested in this patch. Any idea when this might be released?

Thanks!

comment:9 Changed 9 years ago by Florent Guillaume <fg@…>

  • Cc fg@… added

comment:10 Changed 9 years ago by anonymous

  • Cc dserodio@… added

comment:11 Changed 9 years ago by anonymous

  • Cc swalker@… added

comment:12 Changed 9 years ago by graham_foster@…

I too am very interested in this patch being fully included ASAP. Will it make 0.9? Thx.

comment:13 Changed 9 years ago by pkou at ua.fm

Doing a patch for 0.9 is rather hard due to significant source changes that have been made for this release in trunk.

Because the patch has not been integrated at beginning of 0.9, it is pending until all major refactorings will be done for 0.9 (in order to eliminate redundant work).

In order to simplify the patch, separate tickets have been created for step-by-step improvement of Trac code (notably, #1546, #1545, #1544, #1547, and optionally but highly required - #1549).

Having prepared source code in trunk, the patch will address workflow-related issues only.

Note about a major difference between existing patch for 0.8 and new patch for 0.9: The new patch will make Trac status-independent. This will allow customizing Trac for different workflows and statuses without additional changes in codebase.

comment:14 Changed 9 years ago by anonymous

  • Cc martin.d.johansson@… added

comment:15 Changed 9 years ago by anonymous

  • Cc tracissue@… added

comment:16 Changed 9 years ago by anonymous

Is a patch available for 0.8.2? I tried using the patch-newworkflow-r1102.diff attachment, but had a couple of problems:

  1. tried applying this with patch but it couldn't seem to get the file names—I had to type these in (or cut-n-paste them in);
  2. also had lots of rejects once I entered the filenames.

It's the first time I've used patch, so perhaps I messed something up (I tried using -Np1 but that didn't help).

This new workflow is exactly what we need, so I'd love to get it set up prior to 0.9, unless that's imminent.

comment:17 Changed 9 years ago by anonymous

New patch for Trac 0.8.2 attached in NewWorkflow.

comment:18 Changed 9 years ago by tom at vikus.com

I've tried applying the 0.8.2 v2 patch onto versions 1752, 1768, and HEAD, but there are many Hunk failures, as well as missing files, specifically Ticket.py and WikiFormatter?.y.

I am anxious to apply this patch. Am I missing something?

comment:19 Changed 9 years ago by anonymous

  • Cc tom@… added

comment:20 Changed 9 years ago by eblot

I've tried applying the 0.8.2 v2 patch onto versions 1752, 1768, and HEAD

See [http:/trac/ticket/869#change_14 comment 14]. Trunk (i.e. pre-0.9) revisions are very different from the 0.8.2 branch, so do not expect to patch the trunk without going thru (heavy) modifications of the patch file.

comment:21 Changed 9 years ago by anonymous

  • Cc dstcruz@… added

comment:22 Changed 9 years ago by anonymous

  • Cc mrovner@… added

comment:23 Changed 9 years ago by anonymous

  • Cc ciaran.hennessy@… added

comment:24 Changed 9 years ago by David M. Lee <dmlee@…>

  • Cc dmlee@… added

Add one more vote for an improved workflow.

comment:25 Changed 9 years ago by Gunnar Wagenknecht <gunnar@…>

  • Cc gunnar@… added

comment:26 Changed 9 years ago by anonymous

  • Cc vyt@… added

comment:27 Changed 9 years ago by anonymous

  • Cc gytis@… added

comment:28 Changed 9 years ago by mgood

#1989 has been marked as a duplicate of this ticket.

comment:29 Changed 9 years ago by anonymous

  • Cc bene@… added

comment:30 Changed 9 years ago by randyjames@…

  • Cc randyjames@… added

comment:31 Changed 9 years ago by anonymous

  • Cc maze@… added

comment:32 Changed 9 years ago by cmlenz

#2102 has been marked as duplicate of this ticket.

comment:33 Changed 8 years ago by anonymous

  • Cc guillaume.tardif@… added

comment:34 Changed 8 years ago by anonymous

  • Cc barry.kaplan@… added

comment:35 Changed 8 years ago by anonymous

  • Cc trac@… added

My understanding is that this patch will not get into core Trac and needs to be rewritten using the new plug-in system. Is anyone working on this?

comment:36 Changed 8 years ago by anonymous

  • Cc ssalmine@… added

comment:37 Changed 8 years ago by anonymous

  • Cc shishz@… added

comment:38 Changed 8 years ago by anonymous

  • Cc trac@… added

comment:39 Changed 8 years ago by anonymous

  • Cc chris.hopper@… added

comment:40 Changed 8 years ago by anonymous

  • Cc fg@… removed

comment:41 Changed 8 years ago by anonymous

  • Cc nicpottier@… added

yet another votes for this to be possible in .9

comment:42 Changed 8 years ago by anonymous

  • Cc nick+trac@… added

I'd also like to put in my vote for this.

comment:43 Changed 8 years ago by mgood

#2511 has been marked as a duplicate of this ticket

comment:44 Changed 8 years ago by tom@…

I'm looking forward to this and would like to suggest an additional state which I've found very useful while working with Roundup, namely done, could be better a.k.a. donecbb.

In practice it happens often that something is fixed well enough to move on, but one still wants to have a list of all tickets that still could use some 'extra polish'. I found the donecbb state to be very helpful and would like to see it added to trac or that trac provide an easy way to customise states (as roundup does).

and just for the record: I think trac totally rocks ;-)

comment:45 Changed 8 years ago by anonymous

  • Cc roch.nadeau@… added

comment:46 Changed 8 years ago by anonymous

  • Cc number5@… added

comment:47 Changed 8 years ago by anonymous

  • Cc nwhite@… added

comment:48 Changed 8 years ago by anonymous

  • Cc mjh-trac-tickets@… added

comment:49 Changed 8 years ago by anonymous

  • Cc addy.bhardwaj@… added

comment:50 Changed 8 years ago by Alec Thomas <alec@…>

I've created a new patch, and a plugin which leverages this patch. They can be found here. This is against Trac's trunk, so if you are running 0.9.3 it may or may not work.

comment:51 Changed 8 years ago by anonymous

  • Cc rob.duncan@… added

comment:52 Changed 8 years ago by cboos

  • Keywords workflow added

There's now a sandbox branch dedicated to this effort: log:sandbox/workflow

comment:53 Changed 8 years ago by totmacher@…

  • Severity changed from critical to normal

Hello, My name is Christian Sprajc and I'm Project Manager of the Open Source Project "PowerFolder?" (http://www.powerfolder.com). We use Trac since three weeks and we like it very much. Thanks for this nice and useful Product. I'm looking forward to the Workflow component. I have read the "Whitepaper" of "New Trac Workflow" and I think something is still missing. I have the some Ideas to improve the "New" part of the workflow, the way a ticket comes into the system.

We have the problem, that someone who enters the ticket (a user or developer) is not responsible for sheduling a ticket on a milestone or version. Futhermore he might not have an idea to what component this ticket belongs to, nor what priority/Severity a ticket has. He also should not assign the ticket to a user.

I am thinging about a "Simple ticket entry" where all these properties have defaults which cannot be changed by the user. This ticket should then be evaluated by the project management, which sets these properties.

Workflow would be then: "Simple Ticket entry" (User, Developer) → "Evaluation and assignment" (Project management) → "Ticket new"

Best regards, Christian Sprajc

comment:54 Changed 8 years ago by anonymous

  • Severity changed from normal to critical

comment:55 Changed 8 years ago by anonymous

  • Cc rmota@… added

comment:56 Changed 8 years ago by anonymous

  • Cc mrovner@… ciaran.hennessy@… rmota@… added; mrovner@… ciaran.hennessy@… rmota@… removed

comment:57 Changed 8 years ago by anonymous

  • Cc seemant@… added

We would love to see this feature implemented here.

comment:58 Changed 8 years ago by anonymous

  • Cc junk@… added

ASAP please!

comment:59 Changed 8 years ago by anonymous

  • Cc fonolit@… added

comment:60 Changed 8 years ago by Russell Hind <rhind@…>

  • Cc rhind@… added

comment:61 Changed 8 years ago by cboos

  • Milestone set to 0.11
  • Owner changed from jonas to athomas

comment:62 Changed 8 years ago by cboos

#1581 has been marked as duplicate. That ticket reminds about the necessity to avoid hardcoding the status values in the templates.

Also, I've seen that this ticket doesn't yet link to the WorkFlow wiki page, which documents the way new flexible workflows will be possible in future Trac versions.

That page also keeps track of the development status of the workflow branch in the sandbox mentioned above.

comment:63 Changed 8 years ago by anonymous

  • Cc kevin@… added

comment:64 Changed 8 years ago by anonymous

  • Cc wfragg@… added

comment:65 Changed 8 years ago by cmlenz

#3056 marked as duplicate of this ticket.

comment:66 Changed 8 years ago by anonymous

  • Cc ciaran.hennessy@… au rmota@… br rapin.s@… added; ciaran.hennessy@… rmota@… removed

comment:67 Changed 8 years ago by eblot

  • Cc ciaran.hennessy@… added; ciaran.hennessy@… au removed

(fix up CC list)

comment:68 Changed 8 years ago by anonymous

  • Cc trac.tickets@… added

comment:69 Changed 8 years ago by anonymous

  • Cc ged-trac-workflow@… added

comment:70 Changed 8 years ago by anonymous

  • Cc dombly@… added

comment:71 Changed 8 years ago by anonymous

  • Cc avif@… added

I'd really like to see this integrated into Trac soon!

comment:72 Changed 8 years ago by anonymous

  • Cc randyjames@… removed

comment:73 Changed 8 years ago by anonymous

  • Cc tom@… dstcruz@… removed

comment:74 Changed 8 years ago by anonymous

  • Cc d-sleeman@… added

comment:75 Changed 8 years ago by anonymous

  • Cc sstarr@… added

comment:76 Changed 8 years ago by anonymous

  • Cc addy.bhardwaj@… pkou@… nvihinen@… dserodio@… swalker@… martin.d.johansson@… tracissue@… mrovner@… ciaran.hennessy@… dmlee@… gunnar@… vyt@… gytis@… bene@… maze@… guillaume.tardif@… barry.kaplan@… trac@… ssalmine@… shishz@… trac@… chris.hopper@… nicpottier@… nick+trac@… roch.nadeau@… number5@… nwhite@… mjh-trac-tickets@… rob.duncan@… rmota@… br seemant@… junk@… fonolit@… rhind@… kevin@… wfragg@… rapin.s@… trac.tickets@… ged-trac-workflow@… dombly@… avif@… d-sleeman@… sstarr@… removed

comment:77 Changed 8 years ago by anonymous

  • Cc addy.bhardwaj@… pkou@… nvihinen@… dserodio@… swalker@… martin.d.johansson@… tracissue@… mrovner@… ciaran.hennessy@… dmlee@… gunnar@… vyt@… gytis@… bene@… maze@… guillaume.tardif@… barry.kaplan@… trac@… ssalmine@… shishz@… trac@… chris.hopper@… nicpottier@… nick+trac@… roch.nadeau@… number5@… nwhite@… mjh-trac-tickets@… rob.duncan@… rmota@… br seemant@… junk@… fonolit@… rhind@… kevin@… wfragg@… rapin.s@… trac.tickets@… ged-trac-workflow@… dombly@… avif@… d-sleeman@… sstarr@… added

comment:78 Changed 8 years ago by sstarr

  • Cc to added

Put the missing CCs back. 'Anonymous' please be careful with editing CCs.

comment:79 Changed 8 years ago by eblot

  • Cc rmota@… added; rmota@… br to removed

(fix up CC: list)

comment:80 Changed 8 years ago by anonymous

  • Cc deepak.jois@… added

comment:81 Changed 8 years ago by anonymous

  • Cc ronald.berger@… added

comment:82 Changed 8 years ago by anonymous

  • Cc yellen@… added

comment:83 Changed 8 years ago by anonymous

  • Cc sgeertgens@… added

comment:84 Changed 8 years ago by anonymous

  • Cc gunnar@… removed

comment:85 Changed 8 years ago by anonymous

  • Cc ssalmine@… removed

comment:86 follow-up: Changed 8 years ago by anonymous

It would be good to get an update on this.

I'm running 0.1 and I'd like to use this feature, the ability to create new ticket states and actions is fundamental to a change control system. Do I have to wait or is there a work around/plug-in available?

comment:87 in reply to: ↑ 86 Changed 8 years ago by mgood

Replying to anonymous:

I'm running 0.1 and I'd like to use this feature, the ability to create new ticket states and actions is fundamental to a change control system. Do I have to wait or is there a work around/plug-in available?

As mentioned before this is being developed in sandbox/workflow and it's scheduled for 0.11. This cannot be implemented as a plugin, so if you want to try it ahead of time you'll need to get the sandbox branch, though it is not yet up to date with all the fixes in 0.10.

comment:88 Changed 8 years ago by anonymous

  • Cc trac@… added

I really, really hope this get into the 0.11 release. Having used Trac for a while I say you cannot do without this feature for serious work with an off-shore testing team. The situation rapidly becomes confusing withouth the additional states of a flexible workflow. Also PM needs to track the defects in the various stages of the defect fixing process.

comment:89 Changed 7 years ago by anonymous

  • Cc e@… added

comment:90 Changed 7 years ago by sid

#4338 was marked as duplicate of this ticket.

comment:91 Changed 7 years ago by anonymous

  • Cc trac.20.nickread@… added

comment:92 Changed 7 years ago by anonymous

  • Cc pradeep.varadarajan@… added

Is there a patch available for 0.10.x?

P.S. Thank you for trac.

comment:93 Changed 7 years ago by anonymous

  • Cc mmay@… added

comment:94 Changed 7 years ago by anonymous

  • Cc chris.hopper@… removed

comment:95 Changed 7 years ago by anonymous

  • Cc peter.valtersson@… added

comment:96 Changed 7 years ago by anonymous

  • Cc sdyson@… added

comment:97 Changed 7 years ago by trac@…

  • Cc trac@… removed

comment:98 Changed 7 years ago by anonymous

  • Cc sungje@… added

comment:99 Changed 7 years ago by sdyson@…

Since the workflow sandbox no longer exists does anyone know the status of this work?

comment:100 Changed 7 years ago by cboos

Check the WorkFlow page, there are links pointing to the old branch (on top of 0.10dev).

There has been rumors that a new port for 0.11dev will be attempted at the TracSprint during PyCon 2007.

comment:101 Changed 7 years ago by anonymous

  • Cc martin.marcher@… added; pradeep.varadarajan@… mmay@… peter.valtersson@… sdyson@… sungje@… removed

comment:102 follow-up: Changed 7 years ago by anonymous

  • Cc pradeep.varadarajan@… mmay@… added

please don't remove people from the cc list.

comment:103 Changed 7 years ago by anonymous

  • Cc sdyson@… added

comment:104 Changed 7 years ago by anonymous

  • Cc peter.valtersson@… sungje@… added

comment:105 in reply to: ↑ 102 Changed 7 years ago by martin.marcher@…

oops, something bad :(

Replying to anonymous:

please don't remove people from the cc list.

I'm sorry didn't intend to remove those people.

Anyway this could be a bug filed it under ticket:4720 and added a description how this happened. Feel free to remove my address if you need to gain the space to get the original addresses back in.

comment:106 Changed 7 years ago by cboos

Well, maybe we could reopen one of the many duplicates of #869, while waiting for #1459

Pick one of #1581, #1989, #2102, #2511, #3056 or #4338.

comment:107 Changed 7 years ago by roch.nadeau@…

  • Cc roch.nadeau@… removed

comment:108 Changed 7 years ago by bskinnes@…

Would be nice with a feature for removing history items, like all the cc changes here are really a waste of my scrolling time ;) Oh… and a multiline cc field :)

comment:109 Changed 7 years ago by ecarter

  • Resolution set to fixed
  • Status changed from new to closed

You can now (as of [5378] on trunk) customize workflows in Trac. While there is a lot more planned for WorkFlow, I believe this is enough to close this ticket.

comment:110 Changed 7 years ago by anonymous

praise the lord. i thought i would never get this email :)

comment:111 Changed 6 years ago by zywei@…

  • Milestone changed from 0.11 to 0.10.5
  • Resolution fixed deleted
  • Status changed from closed to reopened

How can I custom such workflow below:

  1. developer fixed a defect and assign to QA to verify.
  2. QA verify it, if works well, close this defect.

Issue: In 0.10.4, if developer set "resolve as" = fixed, this defect will be closed.
If reassign to QA without any comment, QA doesn't know what's happen, why reassign to me again?
Here I want the defect's status is fixed but owner change to QA, QA verify and close it.
For normal, only QA can close a defect.
Experts, how can I to it?
Thanks, Michael

comment:112 Changed 6 years ago by athomas

  • Resolution set to fixed
  • Status changed from reopened to closed

Please don't reopen tickets for configuration questions. Use the MailingList or IrcChannel for questions like this.

comment:113 Changed 6 years ago by zywei@…

Sorry for wrong action

comment:114 Changed 6 years ago by eblot

  • Milestone changed from 0.10.5 to 0.11

(restoring milestone)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain athomas.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from athomas to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.