Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362017-11-17T21:19:00ZEcoinformatics Redmine
Redmine Bug #7229 (New): Mis-Formatting of Data Package Contentshttps://projects.ecoinformatics.org/ecoinfo/issues/72292017-11-17T21:19:00ZThomas Thelen
<p>In MetacatUI we're getting a slight mis-formatting when displaying data package contents. This can be seen in the attached images. The issue was initially reported in MetacatUI as issue 379.</p>
<p><a class="external" href="https://github.com/NCEAS/metacatui/issues/379">https://github.com/NCEAS/metacatui/issues/379</a></p>
<p>From Bryce,</p>
<p>"The HTML in question is actually produced by Metacat and MetcatUI is just rendering it without modification from Metacat's View Service. ... The fix would involve changing the underlying eml-2 XSLT."</p> Bug #7182 (New): Allow partial package downloads when some of the objects are private https://projects.ecoinformatics.org/ecoinfo/issues/71822017-04-13T15:10:57ZLauren Walkerwalker@nceas.ucsb.edu
<p>When you try to download a package that has at least one private object, you get a 401 - Unauthorized response. When I am authorized to read at least one object in a package, I would expect to still be able to download the .zip package with those objects.</p>
<p>It's difficult for MetacatUI to tell when the "Download All" will fail, since it would need to check the /isAuthorized/{pid}?action=read result for every single object in the package, which can sometimes be >100. So right now we have an issue where users are getting a failed package download.</p> Feature #7171 (Closed): Run MDQ suite on insert/updatehttps://projects.ecoinformatics.org/ecoinfo/issues/71712017-01-05T00:40:26Zben leinfelderleinfelder@nceas.ucsb.edu
<p>We are looking to have Metacat handle quality reports by submitting new and updated metadata records to the MDQ engine and then storing the results (which will be indexed by existing Metacat index code).</p> Bug #7033 (Resolved): Add external link to FGDC stylesheethttps://projects.ecoinformatics.org/ecoinfo/issues/70332016-05-24T18:32:34Zben leinfelderleinfelder@nceas.ucsb.edu
<p>See <a class="external" href="https://redmine.dataone.org/issues/7747">https://redmine.dataone.org/issues/7747</a></p> Bug #7032 (Resolved): Add ONEDCX stylesheet for D1 view servicehttps://projects.ecoinformatics.org/ecoinfo/issues/70322016-05-24T18:31:28Zben leinfelderleinfelder@nceas.ucsb.edu
<p>see <a class="external" href="https://redmine.dataone.org/issues/7686">https://redmine.dataone.org/issues/7686</a></p> Bug #7030 (Closed): Add EML 2.1.1 to DC support for OAI providerhttps://projects.ecoinformatics.org/ecoinfo/issues/70302016-05-17T17:58:37Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Related to <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: Add EML 2.1.1 handling to OAI-PMH provider (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/7009">#7009</a> - I neglected to add support for EML to DC crosswalking.</p> Feature #7023 (Closed): Treat CHANGEPERMISSION the same as ALLhttps://projects.ecoinformatics.org/ecoinfo/issues/70232016-05-11T17:39:57Zben leinfelderleinfelder@nceas.ucsb.edu
<p>To better conform with the DataONE access control model, we are going to treat the change permission the same as all in the Metacat API. Currently, the three permissions are handled independently and do not cascade like they do in DataONE.<br />With this change, higher permissions will implicitly allow lower (write implies read; changepermission implies write and read; all will still mean all three)</p> Bug #6970 (Closed): MN.getPackage() omits data file extensionshttps://projects.ecoinformatics.org/ecoinfo/issues/69702016-02-29T17:24:03Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Erica Johns at Cornell reports that downloaded zip files do not have file extensions for the data files within the bagIt contents. <a class="external" href="http://support.nceas.ucsb.edu/rt/Ticket/Display.html?id=12349">http://support.nceas.ucsb.edu/rt/Ticket/Display.html?id=12349</a></p>
<p>I looked at the MN.getPackage() method and we are using the "Entity Name" rather than "Object Name" from the EML record. The latter usually has the original filename (with extension) whereas the former does not.</p>
<p>We have two options:<br />- continue to use the Entity Name and look up the file extension using the SM.formatId of the data<br />- switch to use Object Name</p> Bug #6959 (New): http response charset not includedhttps://projects.ecoinformatics.org/ecoinfo/issues/69592016-02-11T00:29:11ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>Metacat doesn't include the content type charset in the http response headers:</p>
<p>curl -o test.dat -v "https://knb.ecoinformatics.org/knb/d1/mn/v2/object/solson.25.5" returns</p>
<p>Content-Type: text/csv</p>
<p>but should be something like:</p>
<p>Content-Type: text/xml;charset=UTF-8</p>
<p>so that the client doesn't have to assume the charset</p> Support #6838 (In Progress): LTER user can't log inhttps://projects.ecoinformatics.org/ecoinfo/issues/68382015-08-28T23:41:47ZJing Taotao@nceas.ucsb.edu
<p>marco: ldap.lternet.edu should still work<br />[4:32pm] Jing: but why the search doesn’t work?<br />[4:32pm] Jing: and i can’t log in it from knb web page.<br />[4:34pm] marco: my guess is that the connection is trying to connect to 389, which IIRC is where startTLS initiates<br />[4:34pm] marco: port 389 is now blocked - not my decision<br />[4:34pm] Jing: aha.<br />[4:35pm] Jing: thanks, marco<br />[4:35pm] marco: if necessary, 389 can be opened for a specific IP or range<br />[4:35pm] marco: and startTLS enabled<br />[4:37pm] marco: we'll work with mark schildhauer next week to figure out the disposition of LDAP</p> Task #6827 (Closed): update SSL configuration directiveshttps://projects.ecoinformatics.org/ecoinfo/issues/68272015-07-29T21:10:42ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat ships with the metacat-site-ssl file showing how to configure Metacat for SSL support, and references this document in the Admin guide. Certain versions of SSL are now vulnerable, and so we need to ensure that our example configurations and documentation show how to exclude these vulnerabilities. See details below from the security advisory.</p>
<pre>
SSL Version 2 and 3 Protocol Detection (20007)
Synopsis:
The remote service encrypts traffic using a protocol with known weaknesses.
Description:
The remote service accepts connections encrypted using SSL 2.0 and/or SSL 3.0. These versions of SSL reportedly suffer from several cryptographic flaws. An attacker may be able to exploit these flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected service and clients.
NIST has determined that SSL 3.0 is no longer acceptable for secure communications. As of the date of enforcement found in PCI DSS v3.1, any version of SSL will not meet the PCI SSC'S definition of 'strong cryptography'.
See Also:
http://www.schneier.com/paper-ssl.pdf
http://support.microsoft.com/kb/187498
http://www.nessus.org/u?247c4540
https://www.openssl.org/~bodo/ssl-poodle.pdf
http://www.nessus.org/u?5d15ba70
Solution:
Consult the application's documentation to disable SSL 2.0 and 3.0.
Use TLS 1.0 or higher instead.
</pre> Bug #6796 (Closed): Cannot register DOI for private objecthttps://projects.ecoinformatics.org/ecoinfo/issues/67962015-07-15T17:37:49Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Looking through the KNB logs, I can see the EZID error when we attempted to register the DOI with metadata.</p>
<p>Caused by: edu.ucsb.nceas.ezid.EZIDException: bad request - invalid identifier status change</p>
<p>The order of events is:<br />1. mint DOI with EZID using minimal metadata (MN.generateIdentifier)<br /> status=RESERVED<br />2. register DOI with EZID using metadata harvested from the actual object we receive (MN.create/update)<br /> if the object is publicly readable<br /> status=PUBLIC <br /> else<br /> status=UNAVAILABLE</p>
<p>Going from RESERVED—>UNAVAILABLE is the cause of our error with EZID. See their documentation about this here:<br /><a class="external" href="http://ezid.cdlib.org/doc/apidoc.html#identifier-status">http://ezid.cdlib.org/doc/apidoc.html#identifier-status</a></p> Support #6793 (In Progress): Update DOIs from KNB to redirect to view servicehttps://projects.ecoinformatics.org/ecoinfo/issues/67932015-07-02T19:00:00ZMatt Jonesjones@nceas.ucsb.edu
<p>In <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Create a new service to update DOI pointers (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/6530">#6530</a> and <a class="issue tracker-5 status-5 priority-2 priority-default closed" title="Story: Keep DOI registrations current and resolvable (Closed)" href="https://projects.ecoinformatics.org/ecoinfo/issues/6440">#6440</a>, we added features to update DOI registrations, but we still have many originally assigned DOIs that redirect to the raw EML document rather than our landing page for a data set. We need to fix all of the /AA/ DOI registrations in the KNB and ensure they point to the right View service page. For DOIs for metadata, that would be the associated /view url for that DOI. For data files and resource maps, its to the view for the associated metadata. E.g.,</p>
<ul>
<li>Metadata doi:10.5063/AA/nceas.227.15 should redirect to <a class="external" href="https://knb.ecoinformatics.org/#view/doi:10.5063/AA/nceas.227.15">https://knb.ecoinformatics.org/#view/doi:10.5063/AA/nceas.227.15</a></li>
<li>Data doi:10.5063/AA/wtyburczy.30.1 should redirect to the same metadata file <a class="external" href="https://knb.ecoinformatics.org/#view/doi:10.5063/AA/nceas.227.15">https://knb.ecoinformatics.org/#view/doi:10.5063/AA/nceas.227.15</a></li>
</ul>
<p>Also, when a user updates metadata for a package (but doesn't change the data), the DOI redirect for the data will need to be updated to point to the new metadata. Let's verify that this is happening automatically in Metacat.</p> Feature #6196 (Rejected): ORE documents should be generated for new EML records from the Metacat APIhttps://projects.ecoinformatics.org/ecoinfo/issues/61962013-11-01T07:16:13ZMatt Jonesjones@nceas.ucsb.edu
<p>Currently, if a metadata document is uploaded via the Metacat API (action=insert or action=update), it does not contain an ORE document, as that API doesn't support it's upload. Consequently, even if we manually generate ORE maps from the admin control panel, each update of an object fails to create an associated ORE map even if it existed for the prior version. Thus, the data set drops out of any searches including the 'Has data' flag.</p>
<p>To fix this, just as we generate SystemMetadata automatically, we should also automatically generate an ORE document for the new metadata document that links all of the referenced data files into the resource map. This will avoid the need for large batch generation of ORE documents.</p> Bug #6194 (Closed): publish service does not create an ORE documenthttps://projects.ecoinformatics.org/ecoinfo/issues/61942013-11-01T06:59:27ZMatt Jonesjones@nceas.ucsb.edu
<p>When the 'publish' service is called from the GUI in MetacatUI, it should generate an OAI-ORE package so that the linked data and metadata files are all downloadable from the web 'Download' link. This should happen regardless of whether the original document had an ORE or not -- by selecting 'Publish', the user is opting to create a fully fledged data package linking all of the content together.</p>