Bug #8573
changing accessPolicies and rightHolders down the line of series can cause improper sync failures
30%
Description
the V2TransferObjectTask.validateSeriesId() method checks that the submitter has "control" of the SeriesID before allowing the sync task to proceed. In (admittedly rare) cases where the accessPolicy and or rightsHolder values change, changes to past series versions may fail synchronization, even though the seriesId is not changing (so there's no need to revalidate the seriesId.
This came up with an example from Pangaea where the second version changed rightsHolder. After that, systemMetadata updates (to add obsoletedBy field) failed because the second version was the head PID, and the old rightsHolder or submitter did not have ChangePermission on the newer object.
Associated revisions
refs: #8573. Limiting the validateSeriesId to sync tasks where a seriesID is being changed (newObjects, and certain updates).
refs: #8573. Limiting the validateSeriesId to sync tasks where a seriesID is being changed (newObjects, and certain updates).
History
#1 Updated by Rob Nahf over 6 years ago
in v2.3 branch, refactored V2TransferObjectTask so that the validateSeriesID method is only called for new objects and system metadata updates that change the seriesId value.
This solves the problem of systemMetadata updates of past versions of the series getting blocked when the object at the head of the series has different access policies, but is not a complete solution. Take for instance a situation where one wants to back-fill the seriesId to past versions (previously blank) and accessPolicies have changed.
Further changes to seriesId authorization may be needed that are more flexible, using a combination of obsoletes, accessPolicies, and authoritativeMemberNode (when authMNs match, defer to the MemberNode's decision making?)
#2 Updated by Rob Nahf over 6 years ago
- % Done changed from 0 to 30
- Target version set to CCI-2.3.10
- Status changed from New to In Progress
