On Jun 28, 2008, at 9:14 AM, Evelina Vrabie wrote: Actually I agree with Squirrel on one point which is that it's more natural that when you want to add a user to a group you go to that user and click on a button to add groups for that users. That way you'll also see the current groups the user belongs too which we cannot see right now and that's a pain. It also scales much better since there are more users in a group than groups for a user. Also software that I can think of know also do this. However this is a bit of work so we won't have the time to do this in 1.5. Let's discuss it here to see if others agree but this is a feature I'd very much like too. So WDYT? Thanks -Vincent

(I still wish we had a proper forum...I don't like posting on mailing lists...makes it somewhat hard to display discussion nicely as users and mail-programs don't behave all the same) ;-) *Vincent wrote:* One solution could be to group them together into a Users & Yes. At least for me, users/groups and permissions are one administation task and should be together. I don't add a user without give him a group and with the group I give the user the permission at the same time. I don't add a group without setting the proper permission, either. On the other hand I don't add a group without purpose (users), but I explain that later on. Editing users is more seldom and if so, then it's most likely a permission/group change... *Vincent wrote:* > Some > > clickable filter (titles like 'username' 'groupname' etc.) and a > > search > > input-field. > I don't understand this one since we already have this I think. I meant that in context of my (ok, it was kind of weird, I didn't have enough time to write an essay ;-)) feedback. Right now you have the filter field, which is fine, but what I meant if you bring the user-administration and the group-administration together, you need a little bit more...more sorting functionalities. > *Squirrel** wrote:* > > And instead editing the group and add a new user to the group, > > you add the group(s) to the user. If you edit a group (click on the > > groups > > name) you will then not adding users but change the rights for the > > group > > ('Rights' section).... Actually I thought it's clearer *g*. Hmm...I see user-administration as one task which involves groups and permission. Groups and permissions don't make any sense without users (guest or unknown is a user too), I guess so far we all could agree, right? So why don't you just put the user into the focus? I'm not adding a group without purpose. If I decide to add a group I'm doing that because I have now (or will have) a specific bunch of people which I would like to separate from the others. But yet that alone would not justify a new group, it would not have any additional logical ingredient. It's the permission of this specific group which starts to give the group an actual meaning. It gives you the possibility to give this group access to a new space (that's a point I come back later on) you created, or more right on tasks. But again, even with this permission for the group, as long as there aren't any users, the whole thing did not change anything at all. It's the user(s) who are the central task for these sub-tasks... *Squirrel wrote:* > > if you add a group you give it a name and set the > > groups rights. > > * I miss a content overview...this interferes somehow with spaces, > > pages and > > rights... *Vincent wrote:* What do you mean by "content overview"? In my opinion, it's an administration task to show you all the content, which was created in your wiki in a nice overview. Who created/edited it, in which space, how many comments are there, how many clicks so far, etc. and make it possible to edit the content right from this spot. With edit I mean un/publish it, delete it, view/edit the content or change the space, etc. etc. I know there exists the 'Index Page', but it does not quite fit what I mean (but with a bit tweaking it should work). *Squirrel wrote:* > * The space preferences are (still) puzzling to me, although I don't > > have a > > better solution in my sleeves... > *Vincent wrote:* > Could you elaborate? While writing this I guess it's getting a bit clearer to me, what puzzles me *g*. It's again kind of missing context of the space administration task. It's just there. However, this task is actually very important side-task of the user-mgt. task. It should work in both ways, meaning like right now as a separate task, because rights on categories/spaces can indeed change and as a follow-up task when adding a new group. If you refer to my example above with the user/group/permission task, you can hopefully see, that this task wouldn't be finished at this point. What's the point of to group a bunch of people, give them task-permissions but DON'T give them content/categories/space permission? I know you could find an example which this is actually the case (if they have the right to add a new space by themself), however in most cases you want to specify what spaces can this group actually see/edit, right? So, finish the chain of tasks there. *Evelina wrote:* * However, I don't agree with your idea about modifying users and groups > sections. I didn't understand much from your proposal below, since some > of the phrases aren't finished. Btw, it used to be Users & Groups > category together but we decided it's best to separate them, especially > when you have a very large wiki, with hundreds of users and groups to > search for. More, I don't understand your concept of adding a group to a > user and setting rights by clicking on the group's name...it just > doesn't seem natural to me. So I find your proposal a bit weird, but > this is only my opinion. Well, I did administer 376 user (or was it 377?) on my own. Around 10-12 different groups and a lot of different rights. And this CMS (yes, it was a CMS and not a wiki, but the differences between a wiki and a CMS aren't that big anymore, especially with XWiki) had the user-mgt. I'm describing above and it worked very well. Personally, I wouldn't want manage hundreds of users in XWiki right now, I guess I would go crazy (please don't take that as an offend, it's not meant as one)... ;-) To manage hundreds of users there are just to few information about the user or group presented in the admin-task. Small example: How can I disable with one click a user? I can't. I can delete him, though, but that's probably not what you want all the time. BTW: I just found out that you can't add a user with the same name as a group... One more thing. The 'Presentation' task. Somehow I would change that too. I wouldn't set the skin stuff in the spaces, I would set the spaces to the skin. Besides less clicky clicky work you could list and show the skin (mouseover) which are currently installed on the system (or in the repository)... I hope I did made myself more clear then the other day... Cheers, Squirrel