<div class="gmail_quote">On Thu, Oct 14, 2010 at 1:44 PM, Otto <span dir="ltr">&lt;<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>&gt;</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 &lt;<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>&gt; wrote:<br>
&gt; On Thu, Oct 14, 2010 at 1:32 PM, Edward Caissie &lt;<a href="mailto:edward.caissie@gmail.com">edward.caissie@gmail.com</a>&gt;<br>
&gt; wrote:<br>
</div><div class="im">&gt;&gt; Also, just as a reminder for those not familiar with Trac, all<br>
&gt;&gt; resolutions, no matter their label, close the ticket.<br>
&gt;<br>
</div><div class="im">&gt; I&#39;m under the assumption at this point that, unless we hear otherwise from<br>
&gt; Otto or someone, that the original Trainee Workflow idea isn&#39;t feasible. So,<br>
&gt; under that assumption, we&#39;d have no need for &quot;suggest-approval&quot; or<br>
&gt; &quot;suggest-not-approved&quot; 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&#39;t know much about how<br>
to do it at present. Here&#39;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&#39;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>
&quot;review&quot; 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&#39;s see how the manual approach we&#39;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, &quot;Reviewer&quot; vs &quot;Authenticated&quot;). If we can generate reports of tickets assigned to Authenticated users (i.e. the Reviewer Trainees who are not yet added to the &quot;Reviewer&quot; group), then we can probably make-do with what we&#39;re doing now...</div>
<div><br></div><div>Chip </div></div><br>