lib-ir: FW: [Dspace-tech] groups

["JQ Johnson" <jqj@darkwing.uoregon.edu>]

Some interesting comments from the dspace implementors, pointing to the
current limits of the dspace authentication model.  Note in particular point
#3.

-----Original Message-----
From: STUVE,DAVID (HP-Corvallis,ex1) [mailto:david.stuve@hp.com]
Sent: Friday, June 06, 2003 12:56 PM
To: 'JQ Johnson'; dspace-tech@lists.sourceforge.net
Subject: RE: [Dspace-tech] groups


Hi JQ,

1) when a collection is created, automatically creat a submit group - good
suggestion, I'll add it to the list.
2) nested groups would be a major change, but we'll probably make that
change someday
3) our current best practices are to have one or two administrators who
manage the submit groups for MIT's collections.  Currently it's a very small
number of submitters; most collections have a couple, some have one.  As
DSpace grows at MIT, the number of people to manage will get large, so we
will migrate the collection and community admin tools away from 'superuser'
status to other people who only have permission to manage those collections
and communities.
4) hmm, no GUI tool to see where groups are referenced at the moment - I
think the better solution is for an error message to come up and tell the
admin where the group is referenced instead of a generic 'server error'
message.  I'll add something about this onto the features list.
5) in this context, anonymous simply means "anyone" - MIT has a MIT-only
group that is created by a clever filter that looks at IP addresses, so no
logins are necessary (entering the entire MIT community would be a
challenge).  It sounds to me like you're thinking along the lines of
creating a U of O group that enumerates the community there.  We avoided
that route with its accompanying difficulties with that MIT filter; take a
look at src/edu/mit/dspace/MITAuthenticator.java for our hack - we look at
the IP address and if it's part of MIT's network, then we make that person a
member of a special dynamic group of 'MIT only'.

Hope you're enjoying the heat wave out there in Oregon,

Dave

-----Original Message-----
From: JQ Johnson [mailto:jqj@darkwing.uoregon.edu]
Sent: Friday, June 06, 2003 11:41 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] groups


Another DSpace suggestion:  when an administrator creates a collection using
the web based UI, why not automatically create a group COLLECTION_x_ADD with
no initial members, and add that group with ADD rights to the collection?
This is the recommended manual procedure in the documentation.  Why not
automate it?

Also, would it be a major change to the groups model to allow groups to
contain other groups rather than just epersons?  One would of course need to
prevent loops as permissions were checked recursively. Currently, if we
wanted to add a person to the workflow for all collections in a community,
we'd need to edit multiple group entries.

Absent these changes, can anyone (MacKenzie?) give us current best practices
for managing collection-submission groups in DSpace?  Does MIT automatically
assign epersons to groups corresponding to their community?  Does it
delegate responsibility for manual assignment to a representative of the
community, and if so does that mean that lots of people at MIT have
administrator privileges?

Also, I note that to prevent dangling pointers "if you try to delete a group
that is referred to by an authorization policy or is a workflow group you
will get an internal server error".  Is there any easy way given an
arbitrary group to find out where it appears in authorization or workflow
policies?

And finally, a question about epersons:  I'm confused about the intended
semantics of the "anonymous" group.  I gather that it includes both
not-logged-in users and to any logged in user.  Is that right?  Would it be
possible to add a similar meta-group that included just all
(logged-in) users?  Such a group would be very useful for allowing access
that was restricted to the whole university community.  Or am I missing a
feature that's already there?

JQ Johnson                    	Office: 115F Knight Library
Academic Education Coordinator	e-mail: jqj@darkwing.uoregon.edu
1299 University of Oregon     	1-541-346-1746 (v); -3485 (fax)
Eugene, OR  97403-1299        	http://darkwing.uoregon.edu/~jqj



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech