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.

Interesting. Could you document on the wiki how you're using this?

BTW: The attached patch seems to be reversed.

Hello Mr. Collins:

Did you ever document this on the wiki?

Do you have a description of how you are using this that can go there or
in this ticket?

Ralf:

Do you think this patch should be merged or should we mark it abandoned?

In it's current state it looks like we need to write:

  test_security tests to cover it
  where should doc for this go? customizing.txt??


Also it looks like the patch is inverted.

-- rouilj