Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362013-11-01T06:59:27ZEcoinformatics Redmine
Redmine 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> Bug #6193 (Closed): obsoleted versions of objects show up in KNB themehttps://projects.ecoinformatics.org/ecoinfo/issues/61932013-11-01T06:53:47ZMatt Jonesjones@nceas.ucsb.edu
<p>From the MetacatUI page for solson.11.6, I logged in and used the Publish button to generate the DOI doi:10.5063/F1QN64NZ. Now, when searching the KNB skin for the phrase 'olson', both the new document (doi:10.5063/F1QN64NZ) and the now obsoleted version of the document (solson.11.6) show up in search results. Correct behavior would be to only show non-obsoleted versions in search results by default in MetacatUI.</p>
<p>N.B. Of course, the SOLR search itself should be able to search and find obsoleted versions.</p> Bug #6191 (Closed): Wrap ldapweb.cgi links from register-data.cgi metacatui template in divhttps://projects.ecoinformatics.org/ecoinfo/issues/61912013-10-31T23:48:22Zben leinfelderleinfelder@nceas.ucsb.eduBug #6183 (Resolved): CNodeService API calls don't honor authoritative MN certificateshttps://projects.ecoinformatics.org/ecoinfo/issues/61832013-10-30T22:25:19ZChris Jonescjones@nceas.ucsb.edu
<p>In working with Mark Reyes on calling CN.archive() and CN.setObsoletedBy() calls for the Merritt repository, he reported a NotAuthorized exception on updating system metadata fields for objects that are managed by Merritt. Using the CN certificate, I have successfully called these and other CN API calls to manipulate system metadata. Since this is more of an integration test, we don't have a unit test to ensure that MN certs are able to modify content on their system by calling the CN API.</p>
<p>In CNodeService, we use D1NodeService.isAdminAuthorized() to check for administrative authorization in calls like CNodeService.archive(). Within that call, we also check for MN-level node administrative authorization using isNodeAdmin(). However, isNodeAdmin() only checks to see if the cert subject is the subject of the local Member Node. It doesn't check to see if the cert subject matches the cert subject of the authoritativeMemberNode listed in the object's system metadata.</p>
<p>We need to add another method, something like D1NodeService.isAuthoritativeNodeAdmin(), and in calls to the CN API, check the cert subject by getting the Node entry from the NodeList in the given environment that corresponds to the authoritativeMemberNode listed in SystemMetadata, and comparing the Node Subject to the cert Subject.</p>
<p>This is a pretty critical bug fix since all CN calls using an MN Subject are likely going to fail. The Merritt ORE fixes are blocked by this issue.</p> Bug #6161 (Closed): Add access_log indexes to support DataONE log retrievalhttps://projects.ecoinformatics.org/ecoinfo/issues/61612013-10-18T19:14:38Zben leinfelderleinfelder@nceas.ucsb.eduBug #6157 (Resolved): Couldn't control the log level in solrhttps://projects.ecoinformatics.org/ecoinfo/issues/61572013-10-17T20:36:24ZJing Taotao@nceas.ucsb.edu
<p>Our current log control didn't work with the log from solr. It has the default value - INFO. The log message was very big.</p> Bug #6154 (Resolved): The metacat configuration showed that it was done even though the dataONE c...https://projects.ecoinformatics.org/ecoinfo/issues/61542013-10-17T00:23:36ZJing Taotao@nceas.ucsb.edu
<p>It seems the configuration ignore the dataONE part.</p> Bug #6137 (Resolved): Add a new action reindexall to reindex all the solr indexhttps://projects.ecoinformatics.org/ecoinfo/issues/61372013-10-09T23:14:34ZJing Taotao@nceas.ucsb.edu
<p>Currently we have an action named reindex. If the action has a parameter pid, it will reindex the solr index of the specified pids. If there is no pid, it will reindex all solr index.</p>
<p>Even though only the administrator has the privilege, it is still easy to reindex all solr index accidentally, which sometimes is very expensive. We should remove the "index all feature" from reindex and add a explicit action reindexall.</p> Bug #6122 (Resolved): Metacat-index can't index taxon informationhttps://projects.ecoinformatics.org/ecoinfo/issues/61222013-10-04T00:46:10ZJing Taotao@nceas.ucsb.edu
<p>With the help of Skye, we patched 5 files: application-context-eml-base.xml, application-context-eml201.xml, application-context-eml211.xml, application-context-eml200.xml and application-context-eml210.xml. <br />We can't use those files in d1_cn_index_processor 1.2 since they have some new classes. We have copied the taxon part from version 1.2 to the version 1.1.2. Those files stays in resource directory. After being deployed, they will stay in the context/WEB-INF/classes directory. They will overwrite the files with the same names in the d1_cn_index_processor-1.1.2.jar.</p> Bug #4690 (Closed): register-dataset.cgi should have its permissions sethttps://projects.ecoinformatics.org/ecoinfo/issues/46902010-01-21T22:23:56ZShaun Walbridgewalbridge@nceas.ucsb.edu
<p>Currently, the registry script does not get the execute bit set when deployed from a WAR file -- either we should fix this by making the permissions stick, or if this isn't possible, provide a post-installation hook which performs the action. The registry on dev was down due to this issue, a chmod a+x did the trick.</p>