On Wed, Oct 30, 2013 at 2:36 PM, Stuart Cracraft <[email protected]>wrote:
>
> I don't follow you. Can you re-phrase?
>
It's easy to figure this out after a quick research
{{{#!sh
$ grep -n -r "No policy allowed" trac
trac/perm.py:469: self.log.debug("No policy allowed %s performing %s on %r",
Binary file trac/perm.pyc matches
}}}
... and then browsing to
http://trac.edgewall.org/browser/trunk/trac/perm.py#L482 (or a local
checkout of Trac source code) reveals this code
{{{#!py
def check_permission(self, action, username=None, resource=None, perm=None):
# ---- 8< ---- Further code omitted ---- 8< ----
self.log.debug("No policy allowed %s performing %s on %r",
username, action, resource)
return False
}}}
Therefore the answer to your question after a 5 min research is that such
lines are debug logging entries emitted prior to returning False for a
permission check , which means that
- Some permission check not scoped to a particular resource failed
- You will not see them if logging level is adjusted to leave DEBUG
entries out
* http://trac.edgewall.org/wiki/TracLogging
--
Regards,
Olemis - @olemislc
Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--
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/groups/opt_out.
