Forum OpenACS Development: ACS 4 Module Services: Whats New, Merging Users, etc

1: ACS 4 Module Services: Whats New, Merging Users, etc

Posted by Carl Coryell-Martin on 04/24/01 08:15 PM

I just tried to use the merge users facility of the openACS 3.2.4 and realized that it was woefully up to date and that I have been building modules for years and not maintaining the /admin/users/merger/merge-2.tcl file to keep up with references to users in the data model.

I see some similar issues with site-wide/group administration and searching. Are there some standards for making modules plug into site-wide/group-wide services?

I did a cursory check of the ACS4x Tcl documentation but couldn't come up with any answers. If not, perhaps there should be.

Cheers,

2: Response to ACS 4 Module Services: Whats New, Merging Users, etc (response to 1)

Posted by Don Baccus on 04/24/01 08:53 PM

This is one of the weakest aspects of the approach taken by aD. Not only merging users but other areas where one must delete rows in tables lag behind.

There's no real solution in ACS4.x. Jon Griffin and I have discussed the need to come up with one. Janine Sisk (of Furfly) will undoubtably track me down and strangle me with her bare hands if we don't.

Do you have any bright ideas? My life may depend on them! :)

3: Response to ACS 4 Module Services: Whats New, Merging Users, etc (response to 1)

Posted by Carl Coryell-Martin on 04/24/01 11:41 PM

I don't know that I have any bright ideas other than the obvious of making a list of these services and doing something like the New-Stuff package in acs 3.2, where modules can register procs that do the right thing with a central admin facility.

The challenging part will be:

figuring out what all services there needs to be
figuring out what the interface should be.

Ideally this would be included in the APM so that you would be reminded of these services existing (or not) when you installed a package.

This makes me suspicious of the admin interface for the ACS4 (okay, so I have been busy with client work and haven't looked at it yet... smack)

cheers,

4: Response to ACS 4 Module Services: Whats New, Merging Users, etc (response to 1)

Posted by Andrew Piskorski on 04/25/01 04:36 PM

What admin interface for ACS4?

;) No, seriously, many of the admin pages in ACS 4.x are seriously
weak and un-scaleable. For example, many seem to use select boxes to
pick lists of users, where the select lists shows all users on the
system. For a real hoot, try going to the "/permissions/" page. Then
try going there again AFTER you've loaded the Places module. Trying
to display all 90000 Places objects on the /permissions/ page works
well only as a way to crash Netscape...

As a quick hack to avoid ever using the /permissions/ page, I've been
sticking links like:

"/permissions/one?object_id=0" site-wide admin permission

"/permissions/one?object_id=[myproject_package_id]"

into the upper-right "out of flow" position in my admin pages.

Of course, none of the above sins against scaleability should be
particularly hard to fix - I just haven't had the time to do it yet on
my own projects. What Carl and Don are talking about above, on the
other hand, is a genuine design problem that'll probably take some
real thought to solve nicely.

5: Response to ACS 4 Module Services: Whats New, Merging Users, etc (response to 1)

Posted by Michael Feldstein on 04/26/01 01:22 AM

Since Don has labeled me as "gadfly" on the volunteers list, I'm going to...er...gad. Or fly. Anyway...

Yet again I say that the admin interface problem points to the usefulness of integrating a usability testing module with the SDM.

6: Response to ACS 4 Module Services: Whats New, Merging Users, etc (response to 1)

Posted by Don Baccus on 04/26/01 02:56 AM

All great ideas sound a lot better when there's a list of volunteers willing to implement them :)

I think something like this would be great, it's a matter of getting a couple of people interested in doing it.

7: Response to ACS 4 Module Services: Whats New, Merging Users, etc (response to 1)

Posted by Carl Coryell-Martin on 05/11/01 02:29 AM

Just a couple of notes on the api: Most of the services are user oriented. So procs that do the following things would be nice:

1. Centralizing user maintainance:

Proc to delete all rows referencing a user id
Proc to change a user id to some other id (merging users)
Proc to list all content a user has contributed in the module user contributions)
Proc to list "tasks" for a user. Things they need to respond to.

2. Centralizing content (this may be taken care of in the content repository)

List new "content" since date (with optional admin tool)

Thats what I was thinking about today. cheers,