Forum OpenACS Q&A: groups admin UI

1: groups admin UI - designed by aliens?

Posted by Janine Ohmer on 08/29/02 06:55 PM

I know I've read posts about this before, but I just have to join in
the refrain. The admin UI for groups is possibly the worst thing I
have ever tried to use, in any version of the ACS (or most other
software, for that matter).

All I'm trying to do is set up a site where each of our clients can
have a private place to report bugs. It looks like bugtracker was
written with group scoping in mind, so I should be able to create a
group for each client, give that group rights to access their
bugtracker project, and then assign each user for that client to that
group. In 3.x, this would have been a piece of cake.

Unfortunately, I have wandered around in all the group admin pages I
can find, and I'm totally lost. I can't figure out how to do any of
these steps.

Has anyone written up a way to navigate this? Is what I want to do
even possible? Do I have to do it via psql?

Thanks in advance for any tips... this is really frustrating.

2: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Talli Somekh on 08/29/02 06:59 PM

Janine, the way we do it and the way I expect it would best be done is set up a subsite for each of your clients. It should solve all your issues regarding providing permissions for differnet individuals over different sections.

With subsites, you can also set up a bboard/forum instance for discussions which we've found helfpul.

talli

3: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Janine Ohmer on 08/29/02 07:06 PM

I actually started out with that approach, and you're right, if we want all the other stuff then this is the way to go. But I'd still like to understand how the groups stuff works, or doesn't. And to be honest, never having tried it, I don't know how to restrict users to their subsite anyway! :)

4: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Tilmann Singer on 08/29/02 07:34 PM

It's necessary to go via /admin -> Group Types -> Groups -> Add a group of this type. Adding members is confusing too (Members / Administration / Add Member ). And make sure to add members of type "Membership", not "User profile" if your installation still offers that - that was a bug fixed by Don recently IIRC.

Then you can grant permissions to that group on the bug-tracker instance via the site-map, or maybe there is a special way in the bug-tracker admin area for that.

No idea if that is the correct way - at least it worked for me a few times.

Yes, the UI is horrible.

5: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Alex Sokoloff on 08/29/02 07:37 PM

How does the subsite method solve the problem? If a user creates an account from the subsite, does ACS make the account exclusive to the subsite, or is the account site-wide? If the account is exclusive, that wouldn't be ideal if the user also needed login / access to the parts of the main site.

6: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Talli Somekh on 08/29/02 07:44 PM

Alex, we set up clients.museatech.net this way. Each client gets a subsite with a bugtracker and a bboard/forums instance. When they sign up, they don't get anything but once we go in and set the appropriate permissions they only have access to their site.

For another kind of site where you're not sectioning things off, this approach may not be very good. But for Janine's needs, a bugtracking site for clients, it's pretty ideal. At least in our experience.

There are probably instances that make it less relevant.

Either way, you still have to deal with the worst, most retarded UI ever devised. And that is certainly an objective statement.

talli

7: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Alex Sokoloff on 08/29/02 07:48 PM

You give the individual user the appropriate permission on the subsite in site map... and you don't worry about groups at all? That makes sense.

8: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Janine Ohmer on 08/29/02 10:01 PM

Thank you Tilmann, I will try that and report back whether I managed to get it working.

But right now, I'm attempting to experiment with subsites. My steps:

mount subsite while logged in as site-wide admin
log out
go to /subsite/register and create a new user
I got redirected to /pvt/home.tcl, which seems wrong; I should have gone to /subsite/pvt/home.tcl, which does exist
However, it does appear to have worked, in that my user registered via the subsite cannot see anything outside of the subsite. In fact, I can't even go back to /pvt/home.tcl without being asked to register - not sure how I got there the first time!

So this will work, I think, but I will look into using pure groups anyway, just because I need to know how to do it both ways. But that's a subject for a different post...

9: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Ben Koot on 08/29/02 10:46 PM

Hi folks,

I have been fighting with these issues for a few days now. I reread the doc's Vinod prepared for programmers, but still fail to see the logic in all this. Would it be possible to get a few demo user scenarios on the new ACS site, that would at least point newbies to the sructure of ACS4. Like Simon pointed out in another post, please concentrate on creating OpenACS4 into a toolkit people with average intelligence can understand, before venturing into yet again more enhancements at server level. It would be greatly apreciated by the users / potential customers of the toolkit.

I noticed a post about the gatekeeperpackage beeing able to run ACS 3 and ACS 4 together. it would be realy usefull, I feel, to have a clear explanation of how to achieve this on the openacs 4 home/pvt welcome page. It doesn't seem right this info is hidden in a bboard posting.

No offence folks, I understand everybody is pressed for time, but without simple things like this ironed out before a new release is published we waste everybodies valuable time. maybe ther is a role in this for a non techie. anyway, i volonteer.

10: Response to groups admin UI - designed by aliens? (response to 1)

Posted by Jun Yamog on 08/30/02 10:51 AM

Hi Janine,
<p>
My advise is study the data model and plsql first. The UI is very data modelly and plsql. After being familiar with it more or less the links in the UI is like what is really underneath. Membership and composition is very powerful, although I wished all that power can be harnessed through a UI rather than putting everything that groups can do on a UI.
<p>
Anyway you can try this api out and create your own. I have done small UI for one of our projects. Here are the helpful api.

<pre>
#create the group
set group_id [db_exec_plsql create_group "
select acs_group__new(
null, -- group_id
'group', -- object_type
now(), -- creation_date
:creation_user, -- creation_user
:creation_ip, -- creation_ip
null, -- email
null, -- url
:name, -- group_name
'needs approval', -- join_policy
null -- context_id
)"]

relation_add composition_rel $main_site_group $group_id

# delete the relationship
set rel_id [db_string get_relid "select rel_id from acs_rels where object_id_two = :group_id
and rel_type = 'composition_rel'"]
relation_remove $rel_id

# delete the group
db_exec_plsql delete_group "select acs_group__delete(:school_id)"

relation_add -creation_user $creation_user -creation_ip $creation_ip -member_state
"needs approval" membership_rel $teacher_group_id $user_id

if {![group::member_p -user_id $user_id -group_name
"Hastertwatch Teachers"]} {
</pre>

Those procs should be the likely procs you will use incase you make a small custom UI. Sorry for the code flood. I am a bit busy and could not have the time to explain and format this groups stuff.

Forum OpenACS Q&A: groups admin UI - designed by aliens?