On Fri, Mar 12, 2010 at 11:19 AM, Caryn Neiswender <[email protected]> wrote: > Hello, All~ > > I am working on a proposal about DSpace account management for the UCIspace > @ the Libraries system. As with other DSpace instances, we restrict access > to some bitstreams, and require interested users to submit an application > for access. > > >From what I can tell, there are two steps to providing access: > registration (either by the user or an admin), then an administrator adds > them to the "access" group. What I'm wondering is how do others handle > this, both from a user and admin perspective?
Mostly manually, which is a major pain-point for us. We (as a multi-institutional repository) do have some magic hackery under the hood that reads IPs and temporarily assigns sessions to a group based on associating IP addresses with a given campus. We also have some LDAP hackery that assigns sessions to an "affiliation" group, again based on campus affiliation proven through a central LDAP login system. I had thoughts once of using the ad-hoc "affiliation" groups to create a catch-all collection for each individual campus, so that people who log in for the first time expecting to be able to deposit can do so at once, even if I have to move their first few deposits and change their privileges later on. That idea didn't get any traction, unfortunately. What we can't do that I would very much like us to: - automagically populate the eperson directory based on LDAP login results and lookups (you logged in? congrats, you're an eperson! an admin looked you up? congrats, you're an eperson!) - assign people to a group based on being in a given department or research unit - assign people to a group based on being in a specific course (and revoke their access when the course is over) - assign people to a group based on program/degree status (ETDs!) Obviously this is not entirely DSpace's fault; our LDAP can't actually give us a lot of this information. We are taking baby steps with Shibboleth and course-management-system authentication in other library contexts that may eventually help with some of these challenges. For the time being, though, all I can do is be as speedy as I can about adding people to groups manually. Definitely not ideal. Dorothea -- Dorothea Salo [email protected] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
