[
https://jira.duraspace.org/browse/DS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24056#comment-24056
]
Tim Donohue commented on DS-937:
--------------------------------
Just to add a small complexity to my point about Backup/Restore. It has become
very apparent from recent "AIP Backup & Restore" questions on dspace-tech, that
folks are using AIPs more for Backup, Restore *OR* Migration. I agree with
MarkW that for a normal Backup & Restore process (where you are backing up &
restoring to the same DSpace instance), we likely should be able to restore
EPerson_ID values. However, a complexity may arise during "migrations" of
content, as it is *highly likely* that you will run into EPerson ID conflicts
(where two different EPeople have the same ID in two different installs),
because we simply just increase that value by one each time.
So, to give a more concrete example. Suppose you were to move Item(s) from one
DSpace to another (via AIP), and the Item(s) are known to be submitted by
EPerson_ID=10 (username: tdonohue) in the original DSpace. But, in the
destination DSpace, EPerson_ID=10 may be someone else (username: mhwood), and
perhaps the more appropriate user (tdonohue) exists under a different ID
(EPerson_ID=12). This EPerson conflict would require us to translate all
references to EPerson_ID=10 in the AIP (or AIPs) to EPerson_ID=12 to ensure we
didn't incorrectly restore this Item (or set of Items).
Currently, we don't encounter this issue with the AIP Backup & Restore as
everything is email-based (which means we can just lookup your user by email
address to find the appropriate EPerson_ID). But, if we are talking about not
requiring an email, that may not be an option in the future.
So, I'm not sure what the 'correct' answer is here. Maybe we just continue to
require an email address but we don't use that as the internal ID (which would
allow folks to change email addresses if they need to). That way when we
export AIPs we can use the email as the 'unique' ID for the person in the AIP.
> Stop using Email Address as Identifier for DSpace User.
> -------------------------------------------------------
>
> Key: DS-937
> URL: https://jira.duraspace.org/browse/DS-937
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.1,
> 1.7.2, 1.8.0
> Reporter: Mark Diggory
> Priority: Major
>
> Use of email address as a persistent identifier for the DSpace conflicts with
> the fact that email addresses are not persistent. Email addresses go away
> and/or are reassigned to other individuals. There are also policy concerns
> with Authenticators like Shibboleth and CAS that may or may not deliver an
> email address as a organizational policy.
> This Task is a placeholder to identify a solution to correct for the problem.
> 1.) DSpace should use a different identifier / key for the EPerson (netid? or
> combination of "authenticator + netID")
> 2.) DSpace should make providing an email address as optional for cases where
> the Authentication features lack this specific capability.
> 3.) Issuing emails should be optional for accounts without email addresses.
> 4.) Stop storing email address (or any other detail about who made the
> change) in dc.description.provenance field.
> One proposed solution to this problem is that the Authentication Method
> should be broken off of EPerson and stored separately, making EPerson a
> "Profile" and the method of Authentication be stored separately (Password,
> Certificate, LDAP, Shibboleth, CAS, Facebook, Google) Different
> AuthenticationMethods may store the data as they see fit. And the Profile
> would store only those local details for that user.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
