Susan: What I am doing at Cornell University is taking inactive persons and unchecking the "Can Log In" in dspace-admin/edit-epeople and putting "Inactive" in the "Phone field. I can then search on them in the database using select * from eperson where can_log_in='f' and phone='Inactive';
I know that's not perfect, but it might help as a work around until something else is developed. George Kozak Digital Library Specialist Cornell University Library Information Technologies (CUL-IT) 501 Olin Library Cornell University Ithaca, NY 14853 607-255-8924 -----Original Message----- From: Thornton, Susan M. (LARC-B702)[LITES] [mailto:susan.m.thorn...@nasa.gov] Sent: Friday, July 22, 2011 11:21 AM To: bfre...@unm.edu; George S Kozak; dspace-tech@lists.sourceforge.net Subject: RE: [Dspace-tech] Problem in DSpace 1.5.1 deleting an eperson who is also a previous Item submitter (item.submitter_id) Here at NASA, we have a "revalidation" process that requires us to determine on a annual basis if a User still needs access to our repository. We have to have some way to remove them if they don't. Perhaps a new column - something like eperson_status - could be added to the EPerson table. So when a User leaves, we can mark them as "Inactive" instead of deleting them and potentially causing problems in the data if they previously submitted an Item to the repository. I can see other uses for a column like that as well. As an alternative, I suppose we could create a group entitled "Inactive". Sue Walker-Thornton Software Developer/Database Administrator NASA Langley Research Center|LITES Contract (757) 224-4074 -----Original Message----- From: Brian Freels-Stendel [mailto:bfre...@unm.edu] Sent: Thursday, July 21, 2011 10:53 AM To: George S Kozak; dspace-tech@lists.sourceforge.net; Thornton, Susan M. (LARC-B702)[LITES] Subject: Re: [Dspace-tech] Problem in DSpace 1.5.1 deleting an eperson who is also a previous Item submitter (item.submitter_id) 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> ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
