[
https://jira.duraspace.org/browse/DS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18410#action_18410
]
Tim Donohue commented on DS-777:
--------------------------------
Mark,
Another thing to think about in regards to this issue.
I just realized that we probably could retain these extra groups and rename
them to something almost entirely random on export (rather than skipping over
them entirely, and not including them in the exported AIPs).
So, as described above, what we don't want to do is to keep them in the format
COLLECTION_<id>_<something> or COMMUNITY_<id>_<something>, as this implies a
relationship with a specific Community or Collection. Since that Community or
Collection no longer exists, we cannot and should not keep around that implied
relationship.
So, instead of just skipping these groups entirely on export, we could modify
PackageUtils.translateGroupNameForExport() to actually create a "dummy", random
group name rather than returning 'null'. So, we could reformat a group name
from COLLECTION_<id>_<something> to GROUP_<random-key>_<something> (e.g. you
could translate "COLLECTION_2_ADMIN" to "GROUP_314534ae323_COLLECTION_ADMIN" if
we find that the Collection of ID=2 no longer exists). In this way, we can
keep around the group (in case it really is still in usage elsewhere), while at
the same time avoiding conflicts on ingest. During ingest we'd just *keep*
that completely random group name, and not attempt to do any reverse
translation. So, if we went this route, all groups and memberships would be
kept (even if they are seemingly no longer used or their associated object no
longer seems to exist), while at the same time we'd avoid the potential group
conflicts/collisions during the restore.
Thoughts? Would this be an even better immediate solution to the problem?
- Tim
> 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: Tim Donohue
> Attachments: METSRightsCrosswalk-updated.patch
>
>
> 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
