[
https://jira.duraspace.org/browse/DS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-777:
---------------------------
Attachment: METSRightsCrosswalk-updated.patch
I've committed a "quick fix" for this issue to Trunk (r5936). The original
attached patch was not quite correct, and now has been updated and re-attached
above.
Mark, if you have time, please test & confirm this fix. Afterwards we can mark
this issue as "resolved"
Also, Mark, do you feel we need to make any changes to the regular expression
(groupAnalyzer) in PackageUtils to avoid matching the Groups you don't want it
to match? Obviously, you've hit on a very specific case here (which I hope
will be unlikely that others would encounter, assuming they are not manually
naming groups similar to "COLLECTION_<ID>_*"). But, I'm just trying to
determine if there are any other fixes we need to think about, or if the
existing fix is "good enough" for now.
> 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
