You nailed it! The code below works. However, users are still able to
'edit' their own comments once a ticket is resolved as signed.
{{{
from trac.core import *
from trac.perm import IPermissionPolicy
from trac.ticket.model import Ticket
class ReadonlySignedTickets(Component):
implements(IPermissionPolicy)
def check_permission(self, action, username, resource, perm):
if resource is None or resource.realm != 'ticket' or \
resource.id is None or action == 'TICKET_VIEW' or \
action == 'TRAC_ADMIN' or 'TRAC_ADMIN' in perm:
return None
t = Ticket(self.env, resource.id)
return False
}}}
On Mon, Jul 28, 2014 at 10:38 AM, Peter Suter <[email protected]> wrote:
> On 28.07.2014 08:55, RjOllos wrote:
>
>> I'm encountering the dreaded issue: RuntimeError: maximum recursion
>> depth exceeded while calling a Python object
>>
>> The issue seems to be with the check: 'TRAC_ADMIN' in perm.
>>
>
> Oops, right. I think adding `action == 'TRAC_ADMIN'` to the check (before
> the `'TRAC_ADMIN' in perm` recursion) should be both sufficient to stop the
> recursion and correct in the non-recursive case:
>
> {{{
>
> from trac.core import *
> from trac.perm import IPermissionPolicy
> from trac.ticket.model import Ticket
>
> class ReadonlySignedTickets(Component):
> implements(IPermissionPolicy)
>
> def check_permission(self, action, username, resource, perm):
> if resource is None or resource.realm != 'ticket' or \
> resource.id is None or action == 'TICKET_VIEW' or \
> action == 'TRAC_ADMIN' or 'TRAC_ADMIN' in perm:
>
> return None
>
> t = Ticket(self.env, resource.id)
> return False
>
> }}}
>
>
>
> I tried reworking the conditional checks in various ways, such as making
>> it look as close as possible to SecurityTicketsPolicy:
>> http://trac.edgewall.org/browser/trunk/sample-plugins/
>> permissions/vulnerability_tickets.py
>>
>> Btw, in vulnerable_tickets.py, should the check be changed?:
>> if 'VULNERABILITY_VIEW' not in perm:
>> ->
>>
>> if 'VULNERABILITY_VIEW' not in perm(resource):
>>
>
> Hm, subtle.
>
> Usually in IPermissionPolicy `perm` should already be specific to the
> checked resource, so `perm` is the same as `perm(resource)`.
>
> But in SecurityTicketsPolicy resource might be changed to the parent
> resource (i.e. the ticket) if it was initially a child resource (e.g. an
> attachment). So here changing `perm` to `perm(resource)` would change the
> logic: Instead of the current behaviour where VULNERABILITY_VIEW is
> required on the child resource (attachment), it would be required on the
> parent resource (ticket).
>
> I guess for attachments (assuming the usual LegacyDelegate is used to
> forward the check to the parent anyway) it makes no difference.
>
> To me it sounds slightly better the way it is (require VULNERABILITY_VIEW
> on the child resource), but I've not used fine-grained permissions much.
>
> Or am I on the wrong track? :)
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Trac Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/trac-users/1GNDHTObQKg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/trac-users.
> For more options, visit https://groups.google.com/d/optout.
>
--
Jared Bownds
c. 916-224-2324
e. Jared.Bownds@g <[email protected]>mail.com
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.
