Roundup Tracker - Issues

Issue 2550700

classification
Title: check functions for Permission.searchable [patch]
Type: rfe Severity: minor
Components: None Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: schlatterbeck Nosy List: elic, rouilj, schlatterbeck
Priority: Keywords: patch

Created on 2011-04-18 20:16 by elic, last changed 2016-07-02 19:45 by rouilj.

Files
File name Uploaded Description Edit Remove
searchable_checks.patch elic, 2011-04-18 20:16
Messages
msg4300 Author: [hidden] (elic) Date: 2011-04-18 20:16
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.
msg4347 Author: [hidden] (schlatterbeck) Date: 2011-07-15 14:23
Interesting. Could you document on the wiki how you're using this?

BTW: The attached patch seems to be reversed.
msg5588 Author: [hidden] (rouilj) Date: 2016-06-11 01:35
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?
msg5712 Author: [hidden] (rouilj) Date: 2016-07-02 19:45
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
History
Date User Action Args
2016-07-02 19:45:10rouiljsetmessages: + msg5712
2016-06-11 01:35:57rouiljsettype: rfe
messages: + msg5588
nosy: + rouilj
2011-07-15 14:23:50schlatterbecksetstatus: new -> open
assignee: schlatterbeck
messages: + msg4347
nosy: + schlatterbeck
2011-04-18 20:16:31eliccreate