Hi all, Yes - this is constrained via database foreign key rules. You can, if you want to, update the relevant user id for the item, but of course you'd lose the submitter / owner information.
What we've done at the University of Auckland is to make all theses (which are the biggest source of stale accounts) be submitted via SWORD. This means the actual deposits are made with a single user account, while our SWORD client (http://easydeposit.swordapp.org/) takes care of the user authentication. It also has the benefit of students not having how to learn the DSpace submission system for a single one-off deposit. Likewise, all our research outputs are deposited via a CRIS system (http://www.symplectic.co.uk/) which means our repository is now just a downstream system, with all its data being fed from more specialized systems. This model seems to work well for us. Thanks, Stuart Lewis Digital Development Manager Te Tumu Herenga The University of Auckland Library Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand Ph: +64 (0)9 373 7599 x81928 On 22/07/2011, at 2:53 AM, Brian Freels-Stendel wrote: > Morning, > > There doesn't seem to be a solid reason in the codebase that epeople > who've submitted can't be deleted; it seems to be something that was > decided on a database level. It makes sense, though, to keep it, on > that level. Otherwise, you have database fields that point nowhere, and > that can't be good. > > For general mass submissions, a workaround might be to use the original > admin account (assuming that's not a person who might later want to be > deleted.) > > For things like theses/dissertations, I think we have to be stuck with > having those one-shot accounts pile up year after year. There might be > some filter feature added so we don't have to look at accounts that are > locked, but with the search functionality, I'm not sure that would be > necessary. > > B-- > > > >>>> On 7/21/2011 at 7:32 AM, in message > <a3e58c957c81584e933f5da65fd9680606494fe...@mbxa.exchange.cornell.edu>, > George > S Kozak <g...@cornell.edu> wrote: >> Susan: >> >> I have run into the same problem, but in my case I was trying to > delete the >> ids of graduate students who left the University, but who had > submitted >> Theses and Dissertations to DSpace. I ended up disabling their > logins, but >> could find no way to actually delete them. >> >> George Kozak >> Digital Library Specialist >> Cornell University Library Information Technologies (CUL-IT) >> 501 Olin Library >> Cornell University >> Ithaca, NY 14853 >> 607-255-8924 >> >> From: Thornton, Susan M. (LARC-B702)[LITES] >> [mailto:susan.m.thorn...@nasa.gov] >> Sent: Wednesday, July 20, 2011 6:33 PM >> To: dspace-tech@lists.sourceforge.net >> Subject: [Dspace-tech] Problem in DSpace 1.5.1 deleting an eperson > who is >> also a previous Item submitter (item.submitter_id) >> >> I ran into a problem I wanted to report in one of our DSpace > instances. I >> was trying to delete an Eperson record as an Administrator, and I > kept >> getting an Internal Server Error. The error message in the > dspace.log file >> didn’t really give me too much to go on, but I finally figured out > that I >> couldn’t delete that person because that person (me!) was the > person who had >> added every Item to the repository and every single row in the Item > table had >> that eperson_id in column “submitter_id”. I don’t think there > should be any >> referential integrity between eperson.eperson_id and > item.submitter_id, >> because it would certainly be possible and appropriate that the > person who >> originally loaded the Items might eventually leave. I suppose > something >> would have to be done in that case or you might end up with an > eperson_id in >> “submitter_id” in the Item rows that no longer exists in the > eperson table, >> but maybe in that instance a generic eperson_id could be used. Does > anyone >> have thoughts on this? I’m not sure if this has been addressed in > a >> subsequent release of DSpace (we’re in the process of implementing > version >> 1.7.1 in our main Production DSpace instance). >> >> Thanks and Best regards, >> Sue >> >> >> >> Sue Walker-Thornton >> Software Developer/Database Administrator >> NASA Langley Research Center|LITES Contract >> SGT, Inc.|130 Research Drive >> Hampton, Va. 23666 >> Office: (757) 224-4074 >> Mobile: (757) 506-9903 >> Fax: (757) 224-4001 >> susan.m.thorn...@nasa.gov<mailto:susan.m.thorn...@nasa.gov> > > ------------------------------------------------------------------------------ > 5 Ways to Improve & Secure Unified Communications > Unified Communications promises greater efficiencies for business. UC can > improve internal communications as well as offer faster, more efficient ways > to interact with customers and streamline customer service. Learn more! > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
