Item9384: Add UI for adding and removing member of groups on the Group topics.

moved from Item2389

-- SvenDowideit - 24 Jul 2010

The new feature fails when the GROUP is defined in the topic instead of a setting. Ie. existing group topics that have not been created with the new feature.

It took me 10 minutes to figure out that the group definition is now in a setting. That is very very confusing.

People will get quite confused when they want to edit a group topic and hit edit and find that it just says %GROUP%

How are normal people supposed to ever figure this out? It took me - an expert - 10 minutes to figure it out. We cannot count on people knowing to go to WikiGroups and use the UI there.

Something redical needs to be done to fix that user interface so when you are on the group topic and the setting is in meta and not a Set bullet, you will know what to do.

That needs to get fixed before we can release 1.1

-- KennethLavrsen - 19 Jul 2010

I'm not convinced by your rhetoric.

Existing groups topics that contain * Set GROUP = can be plain text edited, and the group modfied therein, yes?

A new group created using the UI has %GROUP% in the topic, yes, but surely adding a simple HTML comment to this topic will clear things up for editors?

(18:30:42) Lavr: CDot. My first througt was that the group topics could just contain some docu saying how to change the groups. But then I tried to change an existing group.  Take this scenario.
(18:31:35) Lavr: User A changes an existing group topic using the WikiGroups feature. That converts a Set defined Group to a hidden preference setting defined group. But no docu.
(18:31:52) CDot: I *was* going to say the topic only needs to contain <!-- Use More topic actions -> edit settings -->
(18:32:18) Lavr: User B comes months after and wants to change the group but he arrives directly to the group topic and do not navigate via WikiGroups. And he clicks Edit and see nothing but %GROUP%
(18:32:35) CDot: %GROUP% and <!-- use more topic.... -->
(18:32:38) gac410: Settings in meta vs. settings inline is terribly confusing.  I've been caught by this many times.  Unless one uses the Settings dialog very regularly, it's easy to forget to look there.
(18:32:58) CDot: which is why I'm suggesting adding the comment
(18:33:22) Lavr: It would be better to fix the real problem.
(18:33:47) CDot: ? that's my point; I don't agree there *is* a problem
(18:34:04) CDot: I think storing the group in META:PREFERENCE is the right approach
(18:34:55) Lavr: Not from a user point of view. The Edit settings is a very hidden feature
(18:35:52) gac410: It's a generic issue -  maybe the Edit panel should contain a warning - "This topic has settings in META:PREFERENCE ... click here to access"   or something like that.

-- CrawfordCurrie - 23 Jul 2010

I stand by my original report.

We that administrate a Foswiki daily will be flooded with support questions like "Can you add NN to XXXGroup please?" even more than we are today.

This is already the single most common support question I get.

Adding other uses to a group is an end-user feature. We need normal people that never normally do Wiki apps to be able to add people to groups and they will not in practical life get to the WikiGroups topic to do it. They will click on the group name in a Set ALLOWTOPICCHANGE and hit the edit button. And they will be confused as hell by a bullet with a Macro and some html comment. It is too much geek shit.

You are trying to avoid fixing code. This is what drives this proposal to not do the right thing.

Either the code is fixed so the WikiGroups UI alters a normal Set GROUP = setting.

OR - and that is probably even more difficult - you find a way to add the same user interface that we have on WikiGroups to add and remove members.

One of the comments in the code was concerning multiline group settings.

But current code means that when you edit preferences you will see a Set GROUP = long as nightmare on a single line.

So we may as well just do that in the topic. Current code can read a setting from topic. Problem is that it saves it again as meta setting.

This just needs to be changed so it saves back to the topic replacing current * Set GROUP = followed by the comma separated list of group members.

-- KennethLavrsen - 23 Jul 2010

I am working on this now and I will do it the simple way.

The others can improve later if they want.

I want this done right seen from end users.

-- KennethLavrsen - 24 Jul 2010

I'd vote for you find a way to add the same user interface that we have on WikiGroups to add and remove members. - that isn't that difficult.

however, you seem to have hijacked a task for something completely different (related, but not the same issue at all)

I would prefer both - ie, that things save to whatever form of preference was in the topic (ie, not hardcoded to * Set, but rather detect and do what was there before) and change the UI.

I've commited an initial reuse of the WikiGroups UI - the twisties are still there, and its a little off formatting wise, but its a start.

see http://trunk.foswiki.org/Main/NewUIGroup - yes, it doesn't add the UI to groups with the %GROUP% stuff, and has other issues...

-- SvenDowideit - 24 Jul 2010

Sven, I like what you just started.

To clarify my view.

• I do not believe normal users will find out how to add/remove members from a group - even if guided by a one liner hint - by going through 'More Topic Actions' -> 'More Topic Settings' - > 'Edit Settings For This Topic'. That is far too geeky.
• Even todays Set GROUP = method creates support requests from my users. It is better but not perfect
• Having a proper user interface to add and remove groups - that is the best

So I welcome what you start now Sven. A few comments. Now that you add a nice user interface I would say

• Do not preserve the Set GROUP. Convert it to meta preference and add the user interface. No matter if the already present setting is a Set preference ot a Meta pref. That should also make things simpler in the code.
• I noted that the code makes sure that a person creating a group is always a member himself. That was both because of the implementation of the add to group feature and because it is smart. We should however additionally check if the person adding someone is in the admin group. Admins should be able to add and remove people and create groups without adding themselves. As admin you can always edit all topics anyway.
• We should consider a way for an upgrader to convert to the new and better format for existing groups. A simple way could be to allow submitting the form for adding a new user to a group without any new user. Ie allow the field empty. And then let the code proceed adding noone but changing the format from old to new. This way we upgraders can quickly add noone to each group topic. Even if I have 100 groups it would not be a big deal to do this once and for all and I could do it in small steps.

But great initiative Sven. With this UI on the group topics I would expect one less support question per week where I have to spend some minutes helping adding or removing a user from a group. Now they should have a better chance to do it themselves.

-- KennethLavrsen - 24 Jul 2010

I like the direction the development is taking.

I know Sven is still working on this but I will still just report what I see. Not as critique but as a list of things to remember.

• The upgrade of existing group topic seems incompletely implemented. The existing topic text in combination with the view template means that you get double headline and other garbage. The upgrade more or less has to wipe the old topic.
• When you create a new group the new group has no ALLOWTOPICCHANGE setting. It must have that and it must by default be set to the group itself. It would be OK to let this be a meta setting. It is not the ALLOWTOPICCHANGE normal users should fiddle with. Only the memberlist. It is OK that you have to be more of an expert to change the ALLOWTOPICCHANGE for the group topic so it can be hidden.
• Even though no ALLOWTOPICCHANGE has been defined - the view template shows "Persons/group who can change the list: AdminGroup" which is very misleading because in fact anyone can edit the topic.
• The plus and minus twisties should not be there.

Again. I like what I see. When we have ironed out the last bugs, this is a major improvement in usability.

-- KennethLavrsen - 25 Jul 2010

ok, added everything except the upgrading, and added some ajaxy stuff for adding users.

continuing to work on it.

man, ALLOWTOPICCHANGE undefined is a pig. it gets its value (as a preference) from the WebPreferences topic - even though that is not how ACL's work. who designed this thing?

-- SvenDowideit - 27 Jul 2010

ok, upgrade user topic code written, running tests atm, and really should do some unit tests - but gosh i'm running out of time - gotta feed the girls again

-- SvenDowideit - 07 Aug 2010

code commited - feedback needed.

-- SvenDowideit - 10 Aug 2010

It does not work at all. I think you must have some additional templates that you did not check in.

There are at least two problems.

The new feature depends on the AutoViewTemplatePlugin.

Who says it is enabled?

And this plugin has two modes it can run. One is Exist and this does not work because the form is in System web and the Template is in Main web. And the search path does not work this way.

And the other AutoViewTemplatePlugin works in is section. And that does not work either unless we define the right section in the GroupForm. Ie

%STARTSECTION{name="viewtemplate" type="section"}%%USERSWEB%.GroupView%ENDSECTION{name="viewtemplate" type="section"}%

I strongly suggest that we do not make this feature depend on AutoViewTemplatePlugin. Setting the VIEW_TEMPLATE variable is safer. As an extra safety measure we can also define a fall back to AutoViewTemplatePlugin in case someone removes the setting. And in that case we have to take care it works in both modes. I personally run the AutoViewTemplatePlugin in section mode on my production sites because I want full control of which template is used and I reuse the same view templates for different forms. So exist is a bad choice for me.

The WikiGroups topic upgrade feature works fine. But it needs a cosmetic surgery. When you have mix of group topics that can be upgraded and already upgraded groups the plus and minus icons scate from side to side. They should either be on the same line as the upgrade button or on the next line all the way to the right.

-- KennethLavrsen - 18 Aug 2010

More problems

The groups now have a form. This form - which I do not understand why we need in the first place - create a new confusing place people can edit. But all they can edit is a value called TopicUserMapping which is not hidden when you upgrade, and it is a link to a non existing topic.

If this form was created only to use to make AutoViewTemplatePlugin then it is a bad tradeoff.

People will click that edit button for the form and get confused.

-- KennethLavrsen - 18 Aug 2010

I think we have the fixes this bug item requested.

I am now setting this to Waiting For Release.

I have opened some new items

• Item9495 : WikiGroups topic Upgrade and +/- button allignment and UI needs improvement (Closed)
• Item9494 : Group topic upgrading will often add redundant names in settings (No Action Required)
• Item9492 : JQueryAjaxHelper adds nops to result from user section (Closed)

Let us persue those instead and open new specific reports if more pops up.

Sven I sincerely hope it was OK of me to go back to the simpler non form approach. I could not see any other documented or planned use of the form and it was just making things more complicated than they need to be.

-- KennethLavrsen - 18 Aug 2010

it would have been nice to have discussed this with me, rather than just blowing it away - especially as the Forms change was discussed on irc as being less geeky than the obscure VIEW_TEMPLATE mess.

I don't have time to play around with it, but imo the Forms version is more future proof, and tbh, AutoViewTemplatePlugin shoulc not be considered optional - we're intending to integrate it into the core - ie, its only optional by happenstance, but meh. I need 1.1.0 out months ago,

so just take it as, you've been annoying again.

-- SvenDowideit - 19 Aug 2010

I must agree with Kenneth that GroupForms wasn't a good idea. At least there was no real motivation for them at the time being removed as their definition was empty. Only to trigger an automatic VIEW_TEMPLATE is too weak of a justification for adding a form ... and a common missconception about auto-templating as well.

Fixed a couple of issues. For instance the nops by the ajax helper. For some reason foswiki doesn't process nop, noautolink etc when contenttype=text/plain.

There's still the issue that you can't bulk-add a comma separated list of users with the current interface.

-- MichaelDaum - 19 Aug 2010

mmm, I just tested (again, as its part of my normal dev testing) adding a comma separated list of users - works for me here on t.f.o - what are you doing? (yes, ok, so someone neutered the UI, but the server code works)

-- SvenDowideit - 19 Aug 2010

I also tested. And I can also add comma separated users.

I will reclose this bug. Please open new bug reports if there are new things that show up like I did. It is easier to devide the work between us than keeping on checking in to the same old bug item for more than a month

-- KennethLavrsen - 19 Aug 2010

Removed "Group definitions should not be forced to be METAPREFs" from the headline and regraded as an enhancement; at the end of the day, the groups UI is what we're interested in.

-- CrawfordCurrie - 06 Sep 2010

Re-opened as Urgent because the documentation we get now in the AdminGroup is rubbish. It tells the user to use the old scheme, when the VIEW_TEMPLATE will show him only the new one. It is very disturbing, I had issues understanding what I was supposed to do, so imagine a new user...

-- OlivierRaginel - 28 Sep 2010

Closing this again

This is an enhancement item which is complete. It need to be in the release note under enhancements. By reopening as urgent all the time we end up that this bug is closed as Urgent and not enhancement. Ie. in the wrong section in the release note. Ie. we will not tell the happy message of improved UI in the place potential upgraders will see it.

So please keep it Waiting For Release and Enhancement.

And open new bugs when you discover things that broke because of this. Same we have done with jQuery. We have an enhancement bug for jQuery and we raise and CLOSE bugs we find now.

I have raised urgent bug Item9759 to cover the AdminGroups bug which indeed is urgent and easy to fix (documentation).

-- KennethLavrsen - 28 Sep 2010

I have to correct myself. The original enhancement bug item is Item2172 which added UI to the Groups topic and a few other places.

What we then raised was a bug report that the feature needed further enhancements so that the new group format also had a UI on the groups topics them selves.

-- KennethLavrsen - 28 Sep 2010

Commenting is disabled while not logged in