Item9810: WikiGroups interface does not allow to add existing Groups as members of a Group (nested Groups) and behaves inconsistently when adding them manually using "More actions" and "Edit settings for this topic"

This relates to Foswiki 1.1.0

1.

The WikiGroups interface seems to allow to add existing users only, and refuses to add any existing Group. Typing a group name in the "Add" box results in an error complaining that this user cannot be found... Indeed, that's not a user, it is a Group we try to add.

This is wrong. WikiGroups interface should allow the user to select and enter existing Groups as well.

2.

The only way you can currently add a Group in another Group is by adding them manually using "More actions" and "Edit settings for this topic".

Say you have an existing TestGroup, which has 10 users directly members of this group, and you create a TestNewGroup like this, using "More actions" and "Edit settings for this topic": (Commented out to avoid issues with this task)

   * #Set GROUP = TestNewGroup, TestUser
   * #Set ALLOWTOPICCHANGE = AdminGroup
   * #Set VIEW_TEMPLATE = GroupView

In this case:

• the WikiGroups page does display the users directly members of the Group, and the users from the nested Groups, i.e. 11 users for TestNewGroup. That is the expected behaviour of WikiGroups
  • if, on WikiGroups, you click on "Remove user" for that Group, you get a list of the 11 users, from which you are prompted to pick the user you wish to remove. If you try to remove a user that is actually in a nested Group and the result will say "Success removing users from group", but if you view the WikiGroups (or the TestNewGroup), you still see the "removed" user there
  • that is a bug, and it is a wrong approach. You cannot blindly "remove" users from a Group without knowing how this Group is made, and whether or not the user is a direct member or a member of a nested Group.
  • if at all an interface for adding or removing users has to be in WikiGroups, it has to display the hierarchy of groups and their users. That would be much more useful than the current "add" and "remove"

that's not all

• when you view the topic corresponding to the TestNewGroup, the topic is presenting the 11 users too, hiding the information about the existence of nested groups
  • this is not the expected behaviour of a Group description page
  • this is wrong, since the user cannot figure out what is the structure of the Group
  • again, trying to remove a user from the list presented by this TestNewGroup indicates "success", but does nothing in fact when that user is a user coming from a nested Group
  • I believe that's a bug, and that nested groups were simply overlooked there. if a group is defined as a member of another group, then the most simple approach is just to:
    • allow to add/remove users that are direct group members
    • allow to add/remove groups that are direct group members

Of course, as I said above, if an interface for adding or removing users has to deal with users from a nested Group (or deeper nested), it has to display the hierarchy of groups and their users.

That would be the real user management improvement.

3.

On my installation, ACLs using Groups are broken in 1.1.0. I don't think this is directly related to the problems described above, but you may want to know that I opened Item9809 too, where this other issue is described.

-- RaulFRodriguez - 07 Oct 2010

Changing to confirmed. It appears to be not possible to use the Group API to manage nested groups.

-- GeorgeClark - 08 Oct 2010

Part of the problem is the FuncUserTests for nested groups are disabled.

-- GeorgeClark - 08 Oct 2010

the tests are commented out because we've never had the ability (internally to the core code) to know about nested groups.

This is due to the GROUP setting parser expanding GROUPS until there are only users in the list, and only storing that. And then I leveraged the existing code to serialise that list for add&delete.

It does need more work, and I'm sorry I forgot about that when we then added the cute html UI to add and remove.

Your other issues are all due to this internal representation of groups - everything is coded to show the group members as foswiki knows them, and until it knows internally about the nesting, it all gets simplified into a single array of users.

Anyone that is interested in taking a stab at changing the internal representation of groups to a tree of nested groups - please do - I'm not sure when I'd get around to it.

-- SvenDowideit - 08 Oct 2010

Thanks Sven. Now that you describe the source of the problem, I guess that the problem I described in the separate Item9809 I opened too might be related.

The ACLs seem to be effectively taking the information entered only if it relates to users who are directly specified in the ACL. If a Group is specified, it is ignored, and the users inside that Group (or nested from other Groups) are just ignored.

Please have a quick look at this Task Item9809 (it is a short one).

If the problem reported has the same origin as this one, then the person undertaking the correction should be aware of this other side effect, and ensure it is addressed.

-- RaulFRodriguez - 08 Oct 2010

Fix is committed to trunk. Waiting for review before committing to 1.1.1

-- GeorgeClark - 17 Oct 2010

Like in 9811 the fix seems to be in Release01x01 branch now. And I assume the only thing missing it test and review to put this in WaitingForRelease. Anything you think is missing George?

-- KennethLavrsen - 19 Oct 2010

I have quickly had a look at this after installing an updated version of trunk on my test server. There are some issues I would like to share with you. I will try to get back on this tonight.

-- RaulFRodriguez - 19 Oct 2010

OK, I have tested the changes on a pseudo-installed updated trunk, and an pseudo-installed updated branches/Release01x01

One is now able to properly add a WikiGroup to another Group. Thanks for the good work George !

Here are a few comments, I believe are important:

• the page WikiGroups is supposed to be presenting an expanded view of the groups (in all the versions of TWiki and Foswiki that I have had in my hands in the past). This is no longer the case now. Nested groups are not expanded. There is a choice here, we have to make, either:
  1. we leave it as it is now with your change, and we loose a behaviour expected by the Foswiki users, who expect the WikiGroups page to be presented an expanded view of the users
     • that allows the "Add member..." and "Remove member..." to be presented there: the user can add or remove existing users or groups which are direct members
  2. we expand the groups in the WikiGroups page, to enforce the expected behaviour and remove the "Add member..." and "Remove member..." buttons
     • using the "Add member..." and "Remove member..." buttons is not feasible as it, and these buttons should be removed, since you cannot add or remove members without knowing the structure of the group and whether you are removing direct members or not
  3. we expand the groups in the WikiGroups page, to enforce the expected behaviour and keep the "Add member..." and "Remove member..." buttons
     • we can keep the buttons in an alternative view of the content of the WikiGroups page
     • by default the Groups and expanded
     • at the end of Group a button "Show group structure" is available
     • when this button is clicked, the buttons "Add member..." and "Remove member..." appear and the Group structure is displayed showing the list of the direct members
     • when clicked, the button "Remove member..." allows removal of the direct members

other minor issues are:

• when "Add member..." is clicked, the edit field shows a greyed value "Name of user", though the instructions say "Add a user or group to this group"
• the javascript active on the edit field only looks-up users names, it should also look-up Groups

-- RaulFRodriguez - 19 Oct 2010

Nested groups is allowed after fixes I did on other bug items today.

Only thing missing would be to list the existing groups in the Ajax list so you see them when you start typing. This could be simple SEARCH for *Group in USERSWEB right after the user list.

Keeping this bug item open for this.

-- KennethLavrsen - 20 Oct 2010

Retested this morning. Nested groups can be added, removed, and now the javascript contains suggestions for Groups too now

About the expansion problem, to be clear: the WikiGroup page does not show anymore an expanded view expanding recursively any nested group to show only a list of users. In fact, this is fine with me because I don't really use this behaviour (which is quite limited anyway, because long lists would be truncated anyway). I just draw your attention that here we are choosing option 1. described above and removing an existing behaviour.

-- RaulFRodriguez - 20 Oct 2010

Since changes have been applied to trunk as well as branches/Release01x01, I change the Codebase to reflect this.

-- RaulFRodriguez - 20 Oct 2010

My preferences is for sure that the groups are not expanded. That is the only way you get the correct overview. So I like the way it works now and suggest we keep it this way.

Only concern left is the loading speed when you are admin and get UI for 100s of groups. But that is another enhancement item to look at. We are OK as it is now for 1.1.1

-- KennethLavrsen - 20 Oct 2010

Commenting is disabled while not logged in