Roundup Tracker - Issues

Message8161

Author schlatterbeck
Recipients rouilj, schlatterbeck
Date 2024-10-23.15:14:32
Message-id <20241023151429.wborbqihf5hnl3w2@runtux.com>
In-reply-to <1729695537.72.0.271294834985.issue2551330@roundup.psfhosted.org>
On Wed, Oct 23, 2024 at 02:58:57PM +0000, John Rouillard wrote:
> 
> A thought occurred to me. Permissions are some of the most complex
> things in Roundup.  I have spent a fair amount of time debugging them
> with people.

Yes, I can imagine.
I don't think this is specific to roundup, though...

> Am I correct that you implemented a new pathway pushing some
> permissions checks down to the database level and still have the older
> python only filtering (for dbm) intact?

The current default schemata do not implement any filter functions for
permissions (that are the ones that return filter parameters to be
applied during filtering the things returned from the db).

I *did* implement one for "query" in the new tests I wrote. These could
be used in the templates we have -- but I don't think many installations
will run into performance problems with the number of queries returned
for a user ...

> Would it be possible to turn off the SQL permission checks using a parameter?

Yes, I think we could make that configurable.

> Maybe something in interfaces.py as it should be used for debugging only.

We could make it a debug setting in config. Similar to the email debug
settings.

> My concern is that the SQL checks may return a different result for
> some set of permissions. We don't have very complex sets of
> permissions in the test suite.  But even if we add some more complex
> tests and data, it will still be far from what is in the wild.

Yes, this will not happen for the templates we distribute, these simply
do not have complex enough checks that warrant a filter function in
permissions.

But it would be very useful for debugging filter functions.
Because the user writing the check method and the filter function is
responsible for making them return the same set of results.
And I already discovered -- when modifying an existing tracker -- that
it is non-trivial to rewrite checks as filter functions.

> I would like a way in the field to be able to compare the original
> filtering against the new filtering. This is similar to how we had a
> flag to enable/disable the wsgi performance improvement in 2.2. 

We could make a flag that can turn off the usage of the filter functions
in permission checks. The user would be responsible for running it with
and without filter to compare results.

> In this case, SQL filtering will be turned on by default, but can be
> turned off by importing/setting a flag. Turning it off would return to
> the original python only filter. This way the user can do the same
> query with or without SQL permission checks to see if there is an
> issue.
> 
> I really need to make roundup-admin work correctly with the -u
> parameter (issue2551246).  This will allow a search from the CLI under
> a user's permission set. This would also make it easier for admins to
> test their permissions.

Yes, that should be easy now: Just replace the call to filter with the
call to filter_with_permissions when run as non-admin.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
History
Date User Action Args
2024-10-23 15:14:33schlatterbecksetrecipients: + schlatterbeck, rouilj
2024-10-23 15:14:33schlatterbecklinkissue2551330 messages
2024-10-23 15:14:32schlatterbeckcreate