[
https://jira.duraspace.org/browse/DS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18385#action_18385
]
Tim Donohue commented on DS-777:
--------------------------------
Mark,
There's an explicit reason why I chose to return 'null' from
PackageUtils.translateGroupNameForExport() if a group name includes an internal
Collection/Community ID.
The main reason is that these groups should *not* be exported into an AIP, as
during a restore process they have the potential to cause instability/security
problems. For instance, imagine this scenario:
(1) A group is named "COLLECTION_22_SUBMIT" and there is no longer a Collection
with ID=22 (suppose it used to exist, and used to have a Handle of
123456789/25). Suppose we export this group into an AIP with the unaltered
name "COLLECTION_22_SUBMIT".
(2) Suppose we have a separate Collection (ID=23, Handle=123456789/45) which
had a group name of "COLLECTION_23_SUBMIT". If this Collection still exists,
it's Group will be included in AIP with the *altered* name of
"COLLECTION_123456789/45_SUBMIT"
(3) When you restore via AIPs, there's no guarantee that the restored
Collection will have the same Internal ID as the original one (only the handle
is guaranteed)
(4) So, during a restore, it's possible that the Collection with handle
123456789/45 will be restored with a *new* internal ID of 22. In that case,
the Group named "COLLECTION_123456789/45_SUBMIT" in the AIP will be altered to
the DSpace System expected name of "COLLECTION_22_SUBMIT"
(5) If we also have an *old* group named "COLLECTION_22_SUBMIT" in the AIP, the
AIP process may end up *OVERWRITING* the group membership of the *new* group
named "COLLECTION_22_SUBMIT" (which now belongs to the Collection of Handle:
123456789/45)
So, in order to avoid these group conflict scenarios (which are actually more
likely then they may seem to be, especially during a full restore), I made the
decision to *never* export a group of the name "COLLECTION_<id>_<something>" or
"COMMUNITY_<id>_<something>" if the corresponding Collection or Community no
longer exists in DSpace. There's a warning message about this decision in the
current Documentation about the AIP Format -- see this section:
https://wiki.duraspace.org/display/DSDOC/DSpace+AIP+Format#DSpaceAIPFormat-ExampleofDSPACEROLESSchemaforaSITEAIP
That all being said -- it sounds like there is a small bug here. The
METSRightsCrosswalk is not accurately checking for a null value being returned
from translateGroupNameForExport(), which is causing an empty
<rights:Username/> tag to be exported. The proper fix should just be to *only*
export that <rights:Username/> tag if null is *not* returned. The
RoleDisseminator properly checks for this 'null' value, but the
METSRightsCrosswalk needs to be fixed.
I'll create a small patch and fix this on Trunk shortly -- it's a very minor
fix, but important.
Thanks for reporting this! Let me know if any of these decisions don't make
sense, or if you disagree with the decisions that were made (in which case we
can always rework things for 1.8 as necessary).
> PackageUtils.translateGroupNameForExport returns null unexpectedly
> ------------------------------------------------------------------
>
> Key: DS-777
> URL: https://jira.duraspace.org/browse/DS-777
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0
> Reporter: Mark H. Wood
> Assignee: Mark H. Wood
>
> We have a Community with a ResourcePolicy referring to Group
> COLLECTION_22_SUBMITTER, which seems to have been hand-created since the
> automatic naming would have yielded COLLECTION_number_SUBMIT. There is no
> Collection with ID 22, so PackageUtils.translateGroupNameForExport() returns
> null, and we wind up with <rights:UserName USERTYPE="GROUP" /> which causes a
> CrosswalkInternalException on ingestion.
> I think that, for a Group named type_id_whatever, if we cannot find an object
> of the given type with the given id, then we should consider the input not a
> match to the generated-name pattern and return the unaltered name. We should
> *never* return null or a zero-length
> String; we should *always* return either the unaltered input or a correct
> translation.
> Is there a reason for returning null here that I haven't seen?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
