Bug #5620
closedaccess order="denyFirst" now means public deny (except pre-existing docs)
0%
Description
This is a feature, not a bug:
Metacat 2.0.0 no longer implements denyFirst, only allowFirst.
Ben explained to me why the same eml doc already-submitted to the metacat2 installation on lava is public read while the same eml doc submitted to the metacat2 on demo2 makes it not public read.
Observation:
https://demo2.test.dataone.org/knb/metacat/knb-lter-mcr.2003.2/default
User public does not have permission to read the document with the docid knb-lter-mcr.2003.2
http://lava.lternet.edu:8080/knb/metacat/knb-lter-mcr.2003.2/default
displays fine (not restricted)
That same eml doc on the LTER metacat 1.9.5 is public read.
The reason:
Metacat 2.0.0 no longer implements denyFirst, only allowFirst. EML docs with order="allowFirst" are not affected by this change. EML docs already in metacat before the upgrade will not be affected. EML docs with order="denyFirst" which are updated or inserted after the upgrade will not be public read. This is to protect any possible deny rules not implemented (even if those eml docs contain no deny rules.)
Since the EML 2.1.0 specification still contains denyFirst and does not warn of this change in Metacat, users may be caught unaware.
Im runing a pathQuery on LTER's metacat 1.9.5 now to see how widely denyFirst is used. I'll post summary results as a comment to this "bug".
Updated by gastil gastil over 12 years ago
Results of pathQuery:
In the current inventory on the LTER metacat, the only occurance of access order="denyFirst" are 144 SBC docs, 1 MCR doc and 1 SEV doc.
knb-lter-mcr.2003.2
knb-lter-sev.402.1
So this is only important for consistent documentation for future eml creators.