Feature Proposal: Add format and other stuff to the GROUPS macro

Motivation

GROUPS is currently the only way to retrieve group information. But the result is always in a pre-formatted table.

Description and Documentation

Adding the standard params like format, header, footer, some seperators and maybe a selector to retrieve members of just a single group. Probably adding more macros like GROUPMEMBERS.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: OliverKrueger - 17 Jun 2009

Discussion

It would be useful to know (1) what groups exist and (2) who is in those groups, subject to access controls. The macro name %GROUPS is unfortunate; %GROUPINFO would both be consistent with %USERINFO and also accept a parameter with the name of a single group for which you want a list of members. %GROUPS% would then be deprecated, and made a synonym of:

%GROUPINFO{
   header="| *Group* | *Members* |$n" 
   format="| $name | $percntGROUPINFO{$quot$name$quot format=$quot$dollarwikiname$quot separator=$quot $quot}$percnt |" 
   separator="$n"
}%

Or something like that, anyway. I think it's only used in the groups list topic anyway.

-- CrawfordCurrie - 17 Jun 2009

i'm pretty sure there's already a bug item in for the format= stuff - its part of why i'm working on ExtractAndCentralizeFormattingRefactor for 1.1 - I want to use that code for GROUPs etc

-- SvenDowideit - 17 Jun 2009

The attached patch (against 5125) does %GROUPINFO. Here's the doc:

GROUPINFO{"name"} -- retrieve details about a user

• Syntax: %GROUPINFO%
• Expands to: comma-separated list of all groups
• Syntax: %GROUPINFO{"groupname"}%
• Expands to: comma-separated list of users in that group
• Parameters:

format	Format of a single user or group in the list. $name expands to the group name, and (for users list only) $wikiname, $username and $wikiusername to the relevant strings. The standard FormatTokens are also supported.	$name for groups list, $wikiusername for users list
separator	separator between items in the list	,
header	Header for the list	''
footer	Footer for the list	''
limit	If set, limits the number of results to this	infinity
limited	If limit is set, and the list is truncated, this text will be added at the end of the list	''

• Related: USERINFO

-- CrawfordCurrie - 24 Sep 2009

For all formality I changed the decision back to None.

But this is a no brainer where the risk of rejection is very low. So I would go ahead and implement and I will keep an eye if someone raises concern and put it in accepted in two weeks.

-- KennethLavrsen - 24 Sep 2009

I'd like to change the params a bit

I think it would be better if %GROUPINFO% returned a list of all the groups, as %USERINFO{format="$groups"}% already returns a list of all the current user's groups, and we do need a way to list all groups.

$name should be the groupname even when you do %GROUPINFO{"groupname"}% - so you can make lists of group -> user

this is a somewhat similar issue to the one that lead me to add a USERLIST macro (with auto pagaing) to the HTTPDUserAdminContrib so that I could create a user admin UI (USERINFO returns a particular user's INFO, but we don't have a real way to output the list (or part) of registered users)

The Bulk Registration and Reset topics we ship only work if the user's have topics in the Main web, and if the Topic User mapping works - which we do need to abstract

I really think GROUPINFO should retrieve info about a group, and that USERINFO should retrieve info about a user

-- SvenDowideit - 27 Sep 2009

Thanks, Sven, for spotting that the doc is wrong; %GROUPINFO already returns all groups, not just those the current user is in. I went that route because I thought it would be more useful but of course you are right, that's user info, not group info. And you are right about $name.

-- CrawfordCurrie - 28 Sep 2009

sweeet next up replace the GROUPS call in the WikiGroups topics - I'm going to take a stab at doing that now, and then add support for the new trunk adduserToGroup code..

extra TODO - Tasks.Item2173 Foswiki::Users::isInGroup should also accept a groupname - which when implemented would be most of the way for the GROUPINFO to be able to list the unexpanded nested groups - rather than only being able to list the expanded list of users. (it'd have to be optional, as other times its better to know what foswiki thinks..)

-- SvenDowideit - 29 Sep 2009

Please have a look at Tasks.Item8704 for some inconsistencies that should be ironed out.

-- MichaelDaum - 14 Mar 2010

The original proposal as specced was accepted; the inconsistencies arise from Sven's changes, and can be tracked by task, so I'm closing this feature request.

-- CrawfordCurrie - 01 Apr 2010