So! As I continue to fiddle with Trac to do this migration, I'm having a lot
of fun with milestones. Made a [[MilestoneChanges()]] macro to list out the
closed issues in the milestone that will for sure make it to the release,
the ones which are done in development and now sitting in a QA inbox
/hopefully/ to make it to a release... and then I came up with a slight
conundrum: how do I represent the issues that /must/ end up in that release?
We have a somewhat specialized priority, "blocking", that sits up on top. I
mean specialized because its not 'highest' always; its actual value is
relative. It has no meaning outside of a milestone-- what it means is that
for this milestone to get closed, the blocking issues MUST get solved.
Maybe its an acceptance criteria by a customer; or something beta-testing
turned up that they won't tolerate.. or just an advertised feature we must
have done. Most development is a bit more wishy-washy then that, if done and
through QA cycle by the time a milestone is done then its in that milestone;
if not, the next is fine. But blocking issues, those are big and bad.
Now, I can /show/ them easy:
query = Query.from_string(formatter.env,
"milestone=%s&status!=closed&priority=blocking" % (resource.id,))
results = query.execute(formatter.req)
if results:
output.append("'''Issues
[[span(blocking,style=color:red)]]:'''")
output.append(",,(milestone MUST include these critical
issues),,")
for record in results:
output.append(' * [%s] #%s %s' %
(record['owner'][0:2].upper(), record['id'], record['summary']))
...essentially. No real difference then the 'closed' and 'in QA' issues I
have going before that.
But what I'd really like is for the progress bar on top to show any
non-closed blocking issues with bright redness and to tally them like it
tallies the other milestone-groups.
This I can't figure out how to do. At least, I'm hoping what I think I need
to do is not-- because I haven't figured out new-trac internals good enough
to understand how the heck to go about doing it :)
Is my guess right that I need to implement a new plugin for
ITicketGroupStatsProvider? If so-- eep. Anyone know of any hacks/examples
that do so besides the DefaultTicketGroupStatsProvider in the core?
In trying various ways to accomplish my ends, I ended up making a
super-complicated customized version of the enterprise workflow, with
basically a whole set of parallel statuses-- assigned_blocking,
in_progress_blocking; in_QA_blocking; infoneeded_blocking, etc. Each normal
state had a 'block' button to escalate it up, each blocking version had a
'unblock' to downgrade, and you could follow the normal progression just in
the 'blocking' path. In this method, I could get that milestone to show up
just like I wanted... but -my- was the documentation I had to write
explaining the entire workflow complicated as heck then.
So, those are the two ways I've figured out to get what I want-- I think. Am
I on the wrong track? The complexity of maintaining #2 is why I went digging
and found ITicketGroupStatsProvider. I'm hoping I missed something, or that
others have done unusual things implementing their own plugin of that, so I
can peek and get a better feel for all that's going on.
Thanks in advance.
--Stephen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
