[RFC] get_user_groups

[Christian Boos]

Hi,

As this is an interface change, I'd like to get some feedback on the
following patch, which basically just adds a `get_user_groups` method to
IPermissionStore and therefore to the DefaultPermissionStore, as well as
a `groups` method to the PermissionCache, giving back a set of group
strings for the perm user.

The use case would be for IPermissionPolicy plugins that would need to
ask directly for group membership of a given username (e.g. the
GringottsPlugin on TracHacks).

-- Christian

[Erik Bray]

This would definitely be useful to me, and it's a pretty harmless addition.

Erik

[Colin Guthrie]

I think it goes without saying that I like it ;)

Cheers

Col

[Jeffrey Hulten]

How will group membership be determined?  Is everything still stored in the permission table?  What about groups within groups?

I like it in concept.

[Christian Boos]

Jeffrey Hulten wrote:
> How will group membership be determined? Is everything still stored in the
> permission table? What about groups within groups?
>

Nothing new in this respect with the patch.
The current way to provide group information via
IPermissionGroupProvider components, see trac/perm.py.
The patch is more about being able to retrieve that information
explicitly, in the few case that might need it.
In most cases, the group membership information is not needed directly,
as permissions granted at the group level will be propagated at the user
level, and the code has only to check for permissions on for a specific
user (and resource, for fine-grained permissions). But it in some
specialized cases (like for some IPermissionPolicyProvider components),
getting group membership information explicitly is needed.

-- Christian

[Christian Boos]

Unfortunately, when adding unit-tests to the feature, I realized that
the current notion of group is wired into the DefaultPermissionStore,
itself a "kind of" group provider.

A proper way to fix this would probably involve to move the
IPermissionGroupProvider extension point from the DefaultPermissionStore
to the PermissionSystem and have the DefaultPermissionStore simply
implement the IPermissionGroupProvider interface. But this probably will
have performance issues.

In short: this requires more work to get it working properly, so
probably a 0.12 thing.

-- Christian

[osimons]

Agree on postponing this.

The notions of users and groups are recurring issues as they're not
really flexible and smart enough. Various ideas of user/group
directory/property providers and better core services have been raised
at regular intervals, and they touch on user issues related to
everything from auth, authz, workflow, notification etc. - essentially
a wide range of Trac and plugin issues and requested new features.
More smartness related to the idea of a 'user' should hopefully be on
the drawing board for coming releases, but I don't feel it is a good
idea to add bits of it without there being some sort of proposal that
draws the larger lines on where all this should be heading.


:::simon

https://www.coderesort.com