Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362013-06-05T18:00:12ZEcoinformatics Redmine
Redmine Bug #5997 (Closed): Restrict KNB trusted CAshttps://projects.ecoinformatics.org/ecoinfo/issues/59972013-06-05T18:00:12Zben leinfelderleinfelder@nceas.ucsb.edu
<p>Instead of trusting all commercial CAs, the KNB Member Node should only trust the DataONE and CILogon certificate authorities.</p>
<p>To see a list of all them that are (currently) trusted:<br /><pre>openssl s_client -connect knb.ecoinformatics.org:443</pre></p> Bug #5938 (Closed): sitemap format is deprecatedhttps://projects.ecoinformatics.org/ecoinfo/issues/59382013-05-22T02:34:25ZMatt Jonesjones@nceas.ucsb.edu
<p>The sitemap format used by Metacat has been deprecated, and should be updated to the current release (0.9) as published by <a class="external" href="http://sitemaps.org">http://sitemaps.org</a>.</p> Bug #5925 (Resolved): Clean up the jar files in the Metacat deploy directoryhttps://projects.ecoinformatics.org/ecoinfo/issues/59252013-04-25T18:13:32ZJing Taotao@nceas.ucsb.edu
<p>In the knb/WEB-INF/lib, i saw some jar files like:<br />spring-aop-2.5.5.jar spring-context-2.5.5.jar spring-core-2.5.5.jar spring-tx-2.5.5.jar spring-webmvc-2.5.5.jar<br />spring-beans-2.5.5.jar spring-context-support-2.5.5.jar spring-jdbc-2.5.5.jar spring-web-2.5.5.jar</p>
<p>imageio-ext-arcgrid-1.0.5.jar imageio-ext-gdaldted-1.0.5.jar imageio-ext-gdalenvihdr-1.0.5.jar imageio-ext-gdalmrsid-1.0.5.jar imageio-ext-imagereadmt-1.0.5.jar<br />imageio-ext-customstreams-1.0.5.jar imageio-ext-gdalecw-1.0.5.jar imageio-ext-gdalerdasimg-1.0.5.jar imageio-ext-gdalmrsidjp2-1.0.5.jar imageio-ext-tiff-1.0.5.jar<br />imageio-ext-gdal-bindings-1.4.5b.jar imageio-ext-gdalecwjp2-1.0.5.jar imageio-ext-gdalframework-1.0.5.jar imageio-ext-gdalnitf-1.0.5.jar imageio-ext-utilities-1.0.5.jar<br />imageio-ext-gdalarcbinarygrid-1.0.5.jar imageio-ext-gdalehdr-1.0.5.jar imageio-ext-gdalkakadujp2-1.0.5.jar imageio-ext-geocore-1.0.5.jar</p>
<p>and others.</p>
<p>We may need to clean them up.</p> Bug #5875 (Rejected): d1_cn_index_processor packagehttps://projects.ecoinformatics.org/ecoinfo/issues/58752013-02-21T23:55:30ZBrendan Hahnhahn@nceas.ucsb.edu
<p>Have maven jar up the classes from d1_cn_index_processor for use in metacat</p> Bug #5818 (Resolved): SOLR deployment on Lucene indexhttps://projects.ecoinformatics.org/ecoinfo/issues/58182013-01-24T21:54:51ZBrendan Hahnhahn@nceas.ucsb.edu
<p>Enable optional deployment of SOLR interface to Lucene index</p> Bug #5817 (Resolved): MN query for Lucene indexhttps://projects.ecoinformatics.org/ecoinfo/issues/58172013-01-24T21:54:38ZBrendan Hahnhahn@nceas.ucsb.edu
<p>Make Lucene index available via DataONE MN query interface</p> Bug #5816 (Resolved): REST for Lucene indexhttps://projects.ecoinformatics.org/ecoinfo/issues/58162013-01-24T21:54:23ZBrendan Hahnhahn@nceas.ucsb.edu
<p>Make Lucene index available via REST</p> Bug #5815 (Resolved): Integrate Lucene indexinghttps://projects.ecoinformatics.org/ecoinfo/issues/58152013-01-24T21:54:08ZBrendan Hahnhahn@nceas.ucsb.edu
<p>Add a Lucene index and query interface for metacat docs.</p> Bug #5813 (Resolved): Partition document storage on filesystemhttps://projects.ecoinformatics.org/ecoinfo/issues/58132013-01-24T20:35:22Zben leinfelderleinfelder@nceas.ucsb.edu
<p>There has been concern that ALL xml documents and revisions are saved into a single directory on the filesystem. There is a practical limit to the number of files any one directory can support (though I feel like we don't have definitive numbers on what those limits are exactly).</p>
<p>It would be wise if we could distribute our document/data storage across multiple directories. We could break the file name into subdirectory pieces, or do something more random. Suggestions appreciated.</p> Bug #5516 (Resolved): continue updating user documentationhttps://projects.ecoinformatics.org/ecoinfo/issues/55162011-10-26T20:19:11ZMatt Jonesjones@nceas.ucsb.edu
<p>Documentation needs editing to describe new 2.0.0 features, including support for new DataONE APIs, deprecation of older servlet APIs, and general cleanup.</p>
<p>If possible, moving the admin guide to the sphinx system now would be good.</p> Bug #3816 (Closed): Export action doesn't create complete packagehttps://projects.ecoinformatics.org/ecoinfo/issues/38162009-02-10T02:02:05ZShaun Walbridgewalbridge@nceas.ucsb.edu
<p>When using the export action, two bugs are noticeable:</p>
<p>1. Documents with associated data tables have files with the data table names included, but no data contained within:</p>
<p><a class="external" href="http://knb.ecoinformatics.org/knb/metacat?action=export&qformat=nceas&docid=nceas.912.8">http://knb.ecoinformatics.org/knb/metacat?action=export&qformat=nceas&docid=nceas.912.8</a></p>
<p>2. The resulting files are named after the docid and not based on our sensible naming logic (e.g. mbauer.5 instead of nceas.912.8-mbauer.5.2-Benicia_CABE-107-1.txt). Check with Jim / Rick as to their preference. Probably in the context of the package, the metadata docid is superfluous, and the docid-filename form is correct (mbauer.5.2-Benicia_CABE-107.1.txt).</p> Bug #3397 (Resolved): metacat needs server side sort mechanismhttps://projects.ecoinformatics.org/ecoinfo/issues/33972008-06-16T23:38:50ZChad Berkleyberkley@nceas.ucsb.edu
<p>in the past, we've been using xslt to sort search results going to a browser or client. This works fine until you use paged search results when you need the results sorted before the paging takes place. we need to add functionality to give the server an attribute to sort on before it pages the results. this should probably work similar to the returnfields mechanism (or with the returnfields mechanism).</p> Bug #3085 (Resolved): document the impact of re-deploying on metacat.propertieshttps://projects.ecoinformatics.org/ecoinfo/issues/30852008-01-22T21:00:18ZMatt Jonesjones@nceas.ucsb.edu
<p>There is some confusion about the act of re-deploying the metacat.war file in the tomcat servlet container and the impact that this can have on a customized metacat.properties file. When redeploying, the default metacat.properties file from the war file overwrites the deployed version, possibly reverting property values. This is unexpected. We should explain in the install documentation how to avoid this issue when deploying, either by backing up the customized metacat.properties file and restoring it after the redeploy, or by modifying the source properties file in metacat/lib/metacat.properties when building the war file.</p>
<p>We may also want to consider how to protect the metacat.properties file during a re-deploy or an upgrade. This might be accomplished by storing the properties file under a different name and making sure its not lost upon redeployment.</p> Bug #3017 (Closed): The Ampersand returns a blank page on searcheshttps://projects.ecoinformatics.org/ecoinfo/issues/30172007-11-27T17:51:58ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>Searching on the KNB brings up a blank page when using the Ampersand (&) symbol. A search on a title such as,"Species & functional diversity"will bring up empty page.</p> Bug #1984 (Resolved): add support for LSID identifiershttps://projects.ecoinformatics.org/ecoinfo/issues/19842005-02-18T01:50:30ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat currently supports identifiers of the form 'scope.id.revision' with a<br />'system' attribute inthe metadata. We need to modify metacat to support the<br />Life Science Identifier specification (LSID). LSIDs have the form:</p>
<p>urn:lsid:authority:namespace:localidentifier:revision</p>
<p>THis maps directly onto our existing scheme, and so there should be a one to one<br />correpondence <strong>except</strong> that we fail to store the EML system attribute in our<br />existing scheme. To support LSID fully, we need to:</p>
<p>1) Accept EML documents that use an LSID in their packageId or other Id fields<br />2) Accept LSID in the docid input parameters to the Metacat interfaces,<br />including insert, update, delete, and read among others<br />3) Implement an LSID resolver that is associated with Metacat that allows the<br />standard LSID web services to respond with information about the document<br />4) Allow LSIDs to be placed as identifiers withing the "url" field of EML to<br />reference the data objects that are associated with metadata documents</p>
<p>We probably also need to:<br />5) Allow data objects to be inserted with LSID identifiers<br />6) Allow LSID resolver calls for a dataset id to be able to locate the metadata<br />associated with the data file in order to propoerly respond to the resolver request</p>
<p>The last point requires some new info to be tracked, because right now we<br />maintain the linkage between metadata and data only in the EML documents -- we<br />probably need to extract this when ingesting an eml document and store it for<br />later retrieval.</p>