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.
