Ticket #1913 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

0.11 workflow compatibility

Reported by: bewst Assigned to: bobbysmith007
Priority: high Component: TimingAndEstimationPlugin
Severity: critical Keywords:
Cc: aqualx@gmail.com Trac Release: 0.11

Description

In the reports I see conditions like 

   t.status IN ($NEW, $ASSIGNED, $REOPENED, $CLOSED)

but for 0.11 all reports with 

    status IN ('new', 'assigned', 'reopened', 'closed )

got upgraded to 

    status <> 'closed'

If you don't make a corresponding change, tickets disappear from reports when their status becomes 'accepted', and presumably the new workflow means tickets can go through any number of other states. I think this fact leads naturally to reconsidering the appropriateness of the status checkboxes in the query UI.

Attachments

Change History

08/09/07 11:35:17 changed by bobbysmith007

Yeah. I will look at making this database driven in the future so that it will work. Might be tough, but I will see what I can do.

In the mean time, check out the /query interface, to see if you can accomplish what you need.

Russ

08/10/07 04:30:33 changed by aqualx@gmail.com

  • cc set to aqualx@gmail.com.

08/31/07 15:17:55 changed by bewst

What /query interface?

(follow-up: ↓ 5 ) 09/04/07 09:00:44 changed by bobbysmith007

type /query after your main url , or click the "Custom Query" button on the "View Tickets" screen.

hth, Russ

(in reply to: ↑ 4 ) 09/17/07 10:23:39 changed by anonymous

Replying to bobbysmith007:

type /query after your main url , or click the "Custom Query" button on the "View Tickets" screen.

You can't use the query interface to get almost any of the useful reports. For one thing it queries by ticket, not by ticket change. For another thing there's no way to get e.g., the total hours worked by an individual. For another, there's no filtering by billing period.

But that should be obvious to the person who created the TimingAndEstimationPlugin (you had to build some pretty complex SQL queries), so I'm wondering if somehow I'm missing something.

09/17/07 10:43:51 changed by bobbysmith007

Yeah, It certainly doesnt fix everything (or even much of anything), but its is the best I can do until I can figure out someway to make this work. Last I worked on it, I could not come up with an elegant solution to this. Still thinking about it, but with no answer.

Sorry I cant be of more use, Russ

11/13/07 16:53:28 changed by bobbysmith007

  • status changed from new to closed.
  • resolution set to fixed.

(In [2774]) closes #1913

After much waiting and thinking, I came to the conclusion that the best way to handle the dynamic statuses was to rebuild the reports each time they change. To that end I have added code to check to see if the statuses have changed and then update the reports with the new statuses every time they change (requiring a trac-admin upgrade). Rendering out the statuses and the linkifying javascript were changed to be compatible with this.

11/13/07 17:01:45 changed by bobbysmith007

(In [2775]) re #1913 bumped version number to 0.5.0

11/13/07 23:15:26 changed by bobbysmith007

(In [2776]) re #1913

refactored reportmanager a bit more in response to feed back from Colin Guthrie

bumped version number to 0.5.1

Add/Change #1913 (0.11 workflow compatibility)




Change Properties
Action