Lack of access rights for "previous" datafile prevent saving
I believe this problem was the culprit for [some of] James Wilkins' problems saving datapackages to Metacat.
Here's the scenario:
1. userA inserts EML (meta.1.1) and data (data.1.1) with access rules to allow ALL for userB.
2. userA edits EML and edits data file but it contains invalid XML
3. userA saves data file (data.1.2) the EML file (meta.1.2), but it fails on the EML parsing.
At this point, the server has data.1.1, data.1.2 and meta.1.1 but no access rules for data.1.2 because they were never parsed from the failed meta.1.2 document.
4. userB fixes the parsing error in the EML file and attempts to save
5. userB cannot save because userB does not have access to the data.1.2 file
#4 Updated by ben leinfelder over 7 years ago
Sarah Clark has also seen this behavior, but in a slightly different scenario. Instead of an any EML parsing error, the difference in data file permissions from old to new revision was intentional - they wanted to add all permission to the package so that anyone in the group could edit the packages. Unfortunately, that meant that the old revisions of the data files re still marked as protected from the group (I think).
#5 Updated by ben leinfelder over 7 years ago
- Status changed from New to Closed
Now checking the current and the previous revisions - if either allows updates, then the action proceeds successfully. This is more in keeping with the original permission scheme that metacat used, and prevents us from locking people out of their packages simply because there was an error saving EML but their data file was successfully updated.