Well, I would say that it's doing what it is supposed to, by preventing us from breaking one or more resource policies which would otherwise be referring to a nonexistent object. But that's not very interesting if you need to delete an eperson. DO you need to delete the account, or would it be sufficient to disable it? An administrator can set an account unable to login.
To actually delete the account, you'll first need to find the policies which refer directly to this eperson #12, find the objects to which those policies apply, and adjust their policy sets so that they are accessible as needed but no longer refer to the eperson. [Pokes around in a 5.2 instance's database] Actually I think it likely that a policy bound to an EPerson rather than a group indicates that it is associated with a workspace or workflow item, probably the latter. I found such an eperson, and on the (XMLUI) Administrative | People | this-eperson page I see "This eperson is unable to be deleted because of the following constraint(s): eperson has submitted one or more items, and eperson has a workflow task awaiting their attention." I haven't found a nice GUI way to track down pending submissions by user, but going into the database and executing "SELECT * FROM resourcepolicy WHERE eperson_id = 12" should give you a manageable list of objects to inspect. "List pending submissions by this user" might be a welcome addition to the user interface.... -- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
