Feature Proposal: Implement "Smart Groups" that know who their members are

Motivation

TWiki has added an AllAuthUsersGroup. I like this idea, having done something like this (by hand, in my home wiki), but this approach is cumbersome. The back end could maintain this more easily without errors.

Description and Documentation

I envision this group as having an associated variable, %ALLAUTHUSERS%, that would act in similar ways to the %WEBLIST% variable. That is, it would expand to produce a list of all users, with parameters to change the separator, whether or not Main. is included, etc. This group and variable could be used not only for ACLs but in topic subscriptions, application development, etc.

The group alone is not as valuable as the group + variable combination.

Examples

%ALLAUTHUSERS% expands to the list of all authenticated users

%ALLAUTHUSERS{sep=", "}% same as above (comma would be the default)

%ALLAUTHUSERS{sep=" | "}% easy to use in a table

%ALLAUTHUSERS{link="on"}% would include the Main. part on each name (default)

%ALLAUTHUSERS{link="off"}% would not include the Main. part on each name

...

(note that I like the idea of a parameter that toggles inclusion of the Main. part, similar to WIKINAME vs WIKIUSERNAME. I'm not at all tied to link for the parameter, just the idea.)

Use cases:

• Do something with all users, e.g. applications that go beyond what UserReports offers, such as an application that sends email to all users, subscribing all users easily to topic changes, etc...

• The Main.AllAuthUsersGroup topic would exist, containing

   * Set Group = %ALLAUTHUSERS%

so that a TWiki Admin (or anyone with access) could look at this.

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- 30 Mar 2014 VickiBrown

Discussion

Not sure in how far the name "Smart Groups" relates to the proposed feature.

The name for the macro name %ALLAUTHUSERS is probably misleading as well.

In proper language it means "list all authenticated users", which is pretty much the same like wanting to know who is currently online being authenticated to the site ... probably not exactly what was intended the thing to do.

A better name would be %ALLKNOWNUSERS.

Note that this list is potentially very very long and might require a lot of processing time listing the complete user base of an installation.

A macro like this one expanding to a very long list of users is particularly badly suited to be processed by the ACL checker which currently crawls such a list from start to end to find out if a user is part of that list ... a pretty pointless operation anyway as the %ALLKNOWNUSERS list is designed to contain all users and this must return true anyway.

So for use in ACL checking it is best to use symbolic names as already defined in the BaseUserMapping (nobody, project contributor, guest, everybody, admin, ...).

The only real use case I can see is in writing wiki apps or autocompletion widgets to select a specific user from the list of all known users. This is indeed a missing feature in Foswiki and currently only feasible by means of %SEARCHing the Main web for UserForm topics ... which of course only works out for those user mappers that do create a user profile if at all, and only with this particular data form attached to it.

A similar macro for LDAP-only setups is part of LdapNgPlugin, called %LDAPUSERS which comes with parameters

• header
• format
• separator
• footer
• limit
• skip
• include
• exclude

where variables such as $wikiName, $displayName, $loginName and $emailAddrs are available in format strings.

I am all for a generic replacement of this macro, however not so much for the one proposed so far by Vicki, nor for its use to define an AllAuthUsersGroup.

-- MichaelDaum - 30 Mar 2014

Reading through the TWiki proposal, they implemented what has been warned about in AccessControl#How_Foswiki_evaluates_ALLOW_47DENY_settings - third item about empty DENY settings:. ! Attention: Use this with caution. This is deprecated and will likely change in the next release.

It is replaced by two pseudo-groups. AllUsersGroup and AllAuthUsersGroup. It appears that they are not actually populated with the list of users but represent the two cases of a user on the wiki at that instant (including guest), and a current session user who has authenticated.

So I read the above as a different implementation of the TWiki feature: It appears to request an instantiated group of all users, or all authenticated users.

1. Implement pseudo groups which can be used by the access controls to replace the "special cases" of the DENY settings.
   • Set ALLOW*VIEW = AllUsersGroup Equivalent to Set DENY*VIEW =
   • Set ALLOW*VIEW = AllAuthUsersGroup Equivalent to Set DENY*VIEW = WikiGuest
2. Implement %ALL*USERS% macros to actually list out all users or all authenticated users

Part 1 concept I fully support. It's good to remain some level of feature parity, and the feature has been listed as deprecated for years. It appears very easy to implement, but not as a list, AllAuthUsersGroup merely asks if the current session is authenticated, AllUsersGroup is even easier, it just matches everything. It eliminates some very confusing use of the DENY settings and is long overdue.

Part 2. the macros, I have concerns. This could be a huge list.. It could expand to tens of thousands of users. The Wiki I used to support was tied to a LDAP based SSO system. There were something like 70,000 users defined. I have a concern with any attempt to list the membership of these pseudo-groups.

As an aside... we implemented a pseudo group function in the mapper, but made no attempt to list the actual membership. The pseudo-groups were not required to be topics but were implemented purely in the mapper. Department527Group, Any employee an LDAP equery matched against department 527. Manager387493Group any employee who's manager's employee ID matched 387493. At this point the details have become pretty fuzzy, but I recall the size of these groups being potentially huge. They were not a performance issue however because the mapper only had to ask if the current session's user matched the conditions. If it had to query the database for all users matching the conditions, it would have had possible performance issues.

So I'm raising a concern because of the macros and the requirement to set the contents of these pseudo groups.

-- GeorgeClark - 30 Mar 2014

Since we already have %GROUPINFO%, how does %ALLAUTHUSERS differ from %GROUPINFO{AllAuthUsers}% ? Does that difference bring value?

-- CrawfordCurrie - 31 Mar 2014

I've got no preference (except I have concerns about a macro listing all users, like MichaelDaum and GeorgeClark), but I'd like to point out that the names AllUsersGroup and AllAuthUsersGroup may already be in use in existing wikis. It might make sense to give these special groups names that can't possibly exist already.

-- JanKrueger - 31 Mar 2014

Good point on the GROUPINFO macro, I had forgotten about that one. With that, the case for the ALLAUTHUSERS macro is even less necessary. However the original proposal also has a bit of a chicken & egg problem. The GROUPINFO macro expands the contents of the group, the proposal defines the group with a Set GROUP = %ALLAUTHUSERS%. If you substitute the GROUPINFO for the new ALLAUTHUSERS macro, you now are issuing "   * Set GROUP = %GROUPINFO{"theGroup"}% Does the macro list the group or does the macro define the group. In the TWiki implementation, these groups do not need to be Set.

As far as name collisions for AllUsersGroup and AllAuthUsersGroup, the solution there is to define the group names in configure like we do for the other special groups and users:

$Foswiki::cfg{SuperAdminGroup} = 'AdminGroup';
$Foswiki::cfg{AllUsersGroupName} = 'AllUsersGroup';
$Foswiki::cfg{AllAuthUsersGroupName} = 'AllAuthUsersGroup';

This way they can be renamed on sites that have already defined a group, and also translated, as these group names are meaningful to the end users.

-- GeorgeClark - 31 Mar 2014

I find the name "AllAuthUsersGroup" particularly bad. This has got nothing to do with authentication, more with registration so that the system knows the user. So "AllRegisteredUsersGroup" is better but only slightly. There are systems where registration is not required so my candidate for the name is AllKnownUsersGroup.

If possible I'd rather not support expanding this group unfiltered and without limit parameters.

-- MichaelDaum - 31 Mar 2014

The TWiki implementation implements AllAuthUsersGroup as any cUID except BaseUserMapping_666. So this would cover anyone who has authenticated to access the wiki. As you say, they are not necessarily registered, but I'll add, they had to have passed Authentication, in that they went through some process to identify them, be it an HTTP login, Template login, a client certificate, ... So I guess to me AllAuthUsersGroup is really more accurate than AllKnownUsersGroup. In any event, I don't see this as important enough distinction to add complexity for users migrating from TWiki.

Our implementation needs to be a bit more complex, as we have the Group API and need to make sure that users can't add themselves to the group.

I also agree that expanding the group unfiltered / unlimited would be an issue. I'd like to eliminate the %ALLAUTHUSERS% macro, and defer expanding the groups in %GROUPINFO% and get TWiki compatiblity ready for 1.2.

-- GeorgeClark - 03 Apr 2014

Admitted, authentication as well as authorization (which is more what we are talking about) both start with auth. Still the prefix is chosen wrong by its very nature. Why:

All authenticated users group is wrong, because (a) users don't have to be authenticated at some point at all for the system to know them. Using LDAP, user records are made available to the system without the user ever having hit the site. Even more so in a single sign on environment, where authentication doesn't happen on the Foswiki application level at all. (b) The state of being authenticated is a transient one. So the very same user can be authenticated to the system at some point in time and log out later on thus leaving this state. This does not correlate with him having clearance to content or not from the system's perspective.

All authorized users group is pretty off too. Authorized what for? Without having used it in an ACL the group ID lacks the object users are authorized for. Instead we are yet about to define the group ID ... which then could be used in ACLs later on. Only then will the list of users actually be authorized.

So the group ID AllAuthUsersGroup is frankly really bad. I can't see a reason why we should use it.

Any compatibility problems with TWiki should not be solved by taking over bad design choices made by the other project. To ease transition between the two, or even more exotic: when running the same content using both engines simultaneously, we have the TWikiCompatibilityPlugin. That's where we normally map IDs from TWiki to the ones used in Foswiki.

-- MichaelDaum - 03 Apr 2014

I always read this as AllAuthenticatedUsers_, So I guess that's reason enough that the name is bad.

Still, The macro duplicates %GROUPINFO% so to me that part of the proposal is dead.

IMO the only reason do do any work on this at all is to implement a way for the ACL's to ALLOW any Authenticated user vs trying to DENY the non-authenticated WikiGuest. or +ALLOW All Users_ vs. trying to the empty string. It reduces the need for some messy and confusing negative logic in the ACLs

And now that I read this and the confusion, maybe the two pseudo-group should be:

AllUsersGroup

A group that includes all users including the WikiGuest and Unknown users. (It's only purpose is to have an ALLOW = equivalent to the DENY = <empty>

AnyAuthenticatedUserGroup

A pseudo-group that represents any user who accesses the wiki from an authenticated session. This is the equivalent of DENY = WikiGuest.. Actually I'd prefer to write that one as just AnyAuthenticatedUser and drop the Group suffix.

-- GeorgeClark - 03 Apr 2014

This is all mixed up here. ACLs is all about authorization. It has got nothing to do with authentication. Can we please take authentication out of the equation? Our ACL checker is all fine operating on authenticated or not authenticated users. Authentication and authorization are two independent systems.

Instead of using auth as a prefix to the user group, can we please use

KnownUsersGroup: all users that have an account on the system

This works out best.

-- MichaelDaum - 04 Apr 2014

+1 to that. KnownUsersGroup, and how about ActiveUsersGroup for non-guests with an active session?

-- CrawfordCurrie - 04 Apr 2014

What are you going to do with ActiveUsersGroup? Any use case for it?

-- MichaelDaum - 04 Apr 2014

It's pretty much a given that any social networking feature is going to need it.

-- CrawfordCurrie - 04 Apr 2014

I think that the discussion has reached a point where the proposal needs a substantial rewrite.

-- MichaelDaum - 04 Apr 2014

I've taken a stab at a rewrite of the ACL aspect, eliminating any mention of a group. See RemoveDeprecatedEmptyDENYRule

-- GeorgeClark - 08 Apr 2014

Commenting is disabled while not logged in