<div class="gmail_quote">On Thu, Oct 14, 2010 at 1:44 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Oct 14, 2010 at 1:35 PM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>> wrote:<br>
> On Thu, Oct 14, 2010 at 1:32 PM, Edward Caissie <<a href="mailto:edward.caissie@gmail.com">edward.caissie@gmail.com</a>><br>
> wrote:<br>
</div><div class="im">>> Also, just as a reminder for those not familiar with Trac, all<br>
>> resolutions, no matter their label, close the ticket.<br>
><br>
</div><div class="im">> I'm under the assumption at this point that, unless we hear otherwise from<br>
> Otto or someone, that the original Trainee Workflow idea isn't feasible. So,<br>
> under that assumption, we'd have no need for "suggest-approval" or<br>
> "suggest-not-approved" as ticket resolutions.<br>
<br>
</div>The problem with the idea of a suggest-whatever resolution and the<br>
ticket closing has to do with how trac works. When a ticket is closed,<br>
changing it to another resolution means reopening it and then<br>
resolving it with the new resolution. Two steps, basically. This<br>
rapidly becomes annoying.<br>
<br>
Now, the TracWorkflow *is* adjustable, but I don't know much about how<br>
to do it at present. Here's a page on the topic:<br>
<a href="http://trac.edgewall.org/wiki/TracWorkflow" target="_blank">http://trac.edgewall.org/wiki/TracWorkflow</a><br>
<br>
For those who don't want to read through it all, this graphic<br>
illustrates the default workflow:<br>
<a href="http://trac.edgewall.org/chrome/common/guide/basic-workflow.png" target="_blank">http://trac.edgewall.org/chrome/common/guide/basic-workflow.png</a><br>
<br>
The wiki page has several examples of how we can modify it to have<br>
"review" states or similar. We can try to implement some of those if<br>
it would be helpful to the process.<br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div>I would suggest that, for now, let's see how the manual approach we're currently using works. </div>
<div><br></div><div>One thing that would help us would be the ability to create reports based on User Group (primarily, "Reviewer" vs "Authenticated"). If we can generate reports of tickets assigned to Authenticated users (i.e. the Reviewer Trainees who are not yet added to the "Reviewer" group), then we can probably make-do with what we're doing now...</div>
<div><br></div><div>Chip </div></div><br>