That is as I expected it to be with the permission sets; and also why the "accept" action is essentially a non-use item as well.<br><br><div class="gmail_quote">On Thu, Oct 14, 2010 at 3:20 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">"Accept" is something that is rarely used, realistically. Think of it<br>
like an acknowledgment that the ticket assignment has been received.<br>
<br>
To accept a ticket, people would need the TICKET_CHGPROP permission,<br>
which authenticated users do not have. TICKET_CHGPROP gives the<br>
ability to edit any properties of a ticket, except for description and<br>
cc. So it's probably not something to give to authenticated users.<br>
<br>
-Otto<br>
<br>
<br>
On Thu, Oct 14, 2010 at 1:59 PM, Edward Caissie<br>
<div><div></div><div class="h5"><<a href="mailto:edward.caissie@gmail.com">edward.caissie@gmail.com</a>> wrote:<br>
> Question: (Without actually testing with a second user myself ... ) Can<br>
> someone (Otto?) confirm if an Authenticated user can "accpet" a ticket, it<br>
> doesn't appear they can do much of anything except make comments?<br>
><br>
><br>
> Cais.<br>
><br>
> On Thu, Oct 14, 2010 at 2:54 PM, Edward Caissie <<a href="mailto:edward.caissie@gmail.com">edward.caissie@gmail.com</a>><br>
> wrote:<br>
>><br>
>> As Chip is suggesting, I would agree ... looking at the WorkFlow image<br>
>> (the wiki is now on my reading list), the "trainee" workflow is essentially<br>
>> the following:<br>
>><br>
>> New --> Assigned --> Accepted --> Closed (resolved?)<br>
>><br>
>> ... with "Accepted" not currently used in any of the Theme Review<br>
>> porcesses and a "Reviewer" is required to close, or make a resolution on the<br>
>> ticket.<br>
>><br>
>><br>
>><br>
>> On Thu, Oct 14, 2010 at 2:46 PM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>><br>
>> wrote:<br>
>>><br>
>>> On Thu, Oct 14, 2010 at 1:44 PM, Otto <<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>> wrote:<br>
>>>><br>
>>>> On Thu, Oct 14, 2010 at 1:35 PM, Chip Bennett <<a href="mailto:chip@chipbennett.net">chip@chipbennett.net</a>><br>
>>>> wrote:<br>
>>>> > On Thu, Oct 14, 2010 at 1:32 PM, Edward Caissie<br>
>>>> > <<a href="mailto:edward.caissie@gmail.com">edward.caissie@gmail.com</a>><br>
>>>> > wrote:<br>
>>>> >> Also, just as a reminder for those not familiar with Trac, all<br>
>>>> >> resolutions, no matter their label, close the ticket.<br>
>>>> ><br>
>>>> > I'm under the assumption at this point that, unless we hear otherwise<br>
>>>> > from<br>
>>>> > Otto or someone, that the original Trainee Workflow idea isn't<br>
>>>> > feasible. So,<br>
>>>> > under that assumption, we'd have no need for "suggest-approval" or<br>
>>>> > "suggest-not-approved" as ticket resolutions.<br>
>>>><br>
>>>> 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>
>>>><br>
>>> I would suggest that, for now, let's see how the manual approach we're<br>
>>> currently using works.<br>
>>> One thing that would help us would be the ability to create reports based<br>
>>> on User Group (primarily, "Reviewer" vs "Authenticated"). If we can generate<br>
>>> reports of tickets assigned to Authenticated users (i.e. the Reviewer<br>
>>> Trainees who are not yet added to the "Reviewer" group), then we can<br>
>>> probably make-do with what we're doing now...<br>
>>> Chip<br>
>>><br>
>>> _______________________________________________<br>
>>> theme-reviewers mailing list<br>
>>> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
>>> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
>>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> theme-reviewers mailing list<br>
> <a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
> <a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
><br>
><br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div></div></blockquote></div><br>