Bug #2498
Access rules sometimes adjusted for EML sci meta documents
100%
Description
The access policy for EML content is sometimes adjusted, apparently augmented with information from the EML access policy.
Case where adjustment did occur:
MN: https://demo2.test.dataone.org/knb/d1/mn/v1/meta/dave.20120315.006
CN: http://cn-dev-3.dataone.org/cn/v1/meta/dave.20120315.006
and where it did not for an identical sci-meta document:
MN: https://demo2.test.dataone.org/knb/d1/mn/v1/meta/dave.20120315.005
CN: http://cn-dev-3.dataone.org/cn/v1/meta/dave.20120315.005
History
#1 Updated by Ben Leinfelder over 12 years ago
- Assignee changed from Chris Jones to Ben Leinfelder
Hmm. I'm actually surprised we don't always have permission rules from EML showing up in system metadata.
It must come down to the order in which things happen:
Scenario on MN:
1) insert EML - permissions in EML are added to same table that also drives system metadata
2) system metadata is added and overwrites the extra rules
Scenario on CN
1) System metadata is replicated via Hazelcast map immediately
2) EML file is eventually replicated using traditional Metacat replication and the EML permissions get added to the system metadata when the EML is parsed
I can't dream up why it happens differently for the same doc content different times...
#2 Updated by Ben Leinfelder over 12 years ago
These are both truncated EML documents - not sure if that matters in this particular case, but it might come into play.
http://cn-dev-3.dataone.org/cn/v1/object/dave.20120315.006
http://cn-dev-2.dataone.org/cn/v1/object/dave.20120315.005
#3 Updated by Ben Leinfelder over 12 years ago
- Status changed from New to Closed
After the cn-dev-* environment was cleared and resynchronized, the extra EML-defined access rules did not appear. The document content is also not truncated on these docs. Hopefully it was a fluke. Does seem to be resolved now, though I didn't do anything code-wise.
