Am Mittwoch, 21. September 2016 20:12:43 UTC+2 schrieb Peter Suter:
> Detailed step-by-step description of events:
> 1. The initial question is from web_ui.py about TICKET_VIEW.
> 2. The Permission System asks each policy about this in turn.
> 3. First it asks the privatetickets policy, which interjects (recursively
> "To answer that, I first need to know if TICKET_VIEW_REPORTER is
> 4. The Permission System again poses this new question to each policy in
> 5. First it asks the privatetickets policy, which expected this and
> replies "None".
> (This is not visible in the stack trace.)
> 6. Then it asks ReadonlyTicketsPlugin, which interjects:
> "To answer that, I first need to know if TICKET_ADMIN is available."
> 7. The Permission System again poses this new question to each policy in
> 8. First it asks the privatetickets policy, which interjects (recursively
> "To answer that I first need to know if TICKET_VIEW_REPORTER is
> And since 8. is exactly the same situation as 3. it continues in the same
> way forever.
So I am wondering if "patching" PrivateTicketsPolicy/check_permission would
do the trick: By adding "TICKET_ADMIN" to the list of "ignore permissions /
actions" the "mutual recursion" would stop, wouldn't it?
For me such a "patch fix" is absolutely ok; dropping the
PrivateTicketsPlugin is not. And I fear I am not of any help in tackling
"inherent problem with the design that was not foreseen."
(But I have the test system around for any tests you might want me to try
out, though. We are using Trac extensively here, so there is a strong will
to give back!)
You received this message because you are subscribed to the Google Groups "Trac
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.