Message4300
Attached is a patch which makes some (hopefully) minor changes to the
security system:
It adds a 'klass_check' flag to the Permission constructor. When this
flag is set, Permission.test() will call the check function even if
itemid is None, allowing check functions to be used for permissions that
don't have itemid set. It defaults to False, so the default behavior
should be exactly the same.
This patch also changes Permission.searchable() so that it *will* honor
check functions, but only if klass_check is set to True - as it is only
in this case that it makes sense for searchable to honor them. This
allows View+Issue to have a check function, and nevertheless operate in a
manner compatible with Security.filterSortspec(). By default, klass_check
is False for new Permissions, so searchable() will still return False if
a check function is present, preserving it's default behavior.
Allowing Permission.searchable() to call a check function required
altering it's call signature to pass in db & userid. This also required
altering Security.roleHasSearchPermission() to take in a userid, in order
to pass it to searchable(). This last bit might break compatibility with
existing deployments, if trackers are using roleHasSearchPermission
directly. Other than that, this patch shouldn't affect the current
behavior. |
|
Date |
User |
Action |
Args |
2011-04-18 20:16:31 | elic | set | recipients:
+ elic |
2011-04-18 20:16:31 | elic | set | messageid: <1303157791.13.0.420626183569.issue2550700@psf.upfronthosting.co.za> |
2011-04-18 20:16:31 | elic | link | issue2550700 messages |
2011-04-18 20:16:30 | elic | create | |
|