Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362010-03-23T18:09:49ZEcoinformatics Redmine
Redmine Bug #4900 (Resolved): LDAP referral connection timeouthttps://projects.ecoinformatics.org/ecoinfo/issues/49002010-03-23T18:09:49Zben leinfelderleinfelder@nceas.ucsb.edu
<p>When trying to authenticate with a SANParks username from Metacat hosts that point to ldap.ecoinformatics.org, the authentication fails (localhost, saeonocean, knb, dev). When authenticating through the sanparks.org ldap with a SANParks username, the authentication is successful.<br />This points to an issue in the referral handling.</p>
<p>Upon further investigation, it appears that the AMNH referral (ldap.biodiversityinformatics.amnh.org:636) is causing the problem:<br />-------------<br />knb 20100323-11:01:11: [WARN]: AuthLdap.ldapAuthenticate - Trying to authenticate: uid=test,o=SANParks,dc=ecoinformatics,dc=org Using server: ldap://ldap.ecoinformatics.org:389/ [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:01:11: [WARN]: Authentication exception: [LDAP: error code 49 - Invalid Credentials] [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:01:11: [WARN]: AuthLdap.getIdentifyingName - Searching for DNs with following filter: (&(uid=test)(o=SANParks)) [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:02:26: [ERROR]: AuthLdap.getIdentifyingName - Naming exception while getting dn: javax.naming.CommunicationException: ldap.biodiversityinformatics.amnh.org:636 [Root exception is java.net.ConnectException: Operation timed out] [edu.ucsb.nceas.metacat.AuthLdap]<br />knb 20100323-11:02:26: [ERROR]: AuthLdap.authenticate - Naming exception while authenticating in AuthLdap.authenticate: javax.naming.NamingException: Naming exception in AuthLdap.getIdentifyingName: javax.naming.CommunicationException: ldap.biodiversityinformatics.amnh.org:636 [Root exception is java.net.ConnectException: Operation timed out] [edu.ucsb.nceas.metacat.AuthLdap]<br />javax.naming.NamingException: Naming exception in AuthLdap.getIdentifyingName: javax.naming.CommunicationException: ldap.biodiversityinformatics.amnh.org:636 [Root exception is java.net.ConnectException: Operation timed out]<br /> at edu.ucsb.nceas.metacat.AuthLdap.getIdentifyingName(AuthLdap.java:411)<br /> at edu.ucsb.nceas.metacat.AuthLdap.authenticate(AuthLdap.java:158)<br /> at edu.ucsb.nceas.metacat.AuthSession.authenticate(AuthSession.java:84)<br /> at edu.ucsb.nceas.metacat.MetacatHandler.handleLoginAction(MetacatHandler.java:345)<br /> at edu.ucsb.nceas.metacat.MetaCatServlet.handleGetOrPost(MetaCatServlet.java:776)<br /> at edu.ucsb.nceas.metacat.MetaCatServlet.doPost(MetaCatServlet.java:489)<br /> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)<br />......................</p> Bug #4871 (Resolved): Need a new tag for utilities module on Metacat 1.9.2 releasehttps://projects.ecoinformatics.org/ecoinfo/issues/48712010-03-05T01:02:05ZJing Taotao@nceas.ucsb.edu
<p>I just fixed bug 4866. <a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4866">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4866</a></p>
<p>This fix involves the change on DateUtil class of utilities module. Currently the fix is the trunk. So we should create a new tag on utitlities and use this tag on our metacat build process.</p> Bug #4866 (Resolved): The date displaying on Workflow Run Schedule is incorrecthttps://projects.ecoinformatics.org/ecoinfo/issues/48662010-03-03T23:33:51ZJing Taotao@nceas.ucsb.edu
<p>I tried to schedule a workflow run on the scheduler interface. The start time is 03/03/2010 15:30:00 and end time is 03/03/2010 17:00:00. After clicking Schedule button, the result shows:</p>
<p>Start Time End Time<br />30/03/10 15:30:00 PST 00/03/10 17:00:00 PST</p>
<p>So the date displaying is incorrect. However, on 03/03/2010 15:30:00 the workflow did a run. So it is just displaying problem.</p> Bug #4850 (Resolved): Get the new TPC scheduler working with the new changes in Kepler from the K...https://projects.ecoinformatics.org/ecoinfo/issues/48502010-02-26T18:36:31ZJing Taotao@nceas.ucsb.edu
<p>On kepler side, the metadata format to describe the workflow kar file and workflow run files was changed. So TPC scheduler should be changed accordingly.</p> Bug #4841 (Resolved): Review page for new data registration omits spatial/temporal infohttps://projects.ecoinformatics.org/ecoinfo/issues/48412010-02-24T23:57:55ZJim Regetzregetz@nceas.ucsb.edu
<p>Both for the ESA and NCEAS data registries, information entered in the temporal coverage and spatial coverage sections does <strong>not</strong> appear on the review page that appears after submitting the initial registration form. This seems like an oversight, as all other fields on the form are presented for review.</p> Bug #4839 (Resolved): Fix URL in "revision notification" email sent to ESA moderatorshttps://projects.ecoinformatics.org/ecoinfo/issues/48392010-02-24T22:33:40ZJim Regetzregetz@nceas.ucsb.edu
<p>The "revise document" notification that gets sent to ESA moderators after requesting a revision contains a URL like this:</p>
<p><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65">http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65</a></p>
<p>It probably shouldn't specify stage=modify, because the moderator is unlikely to want to modify the document at this point. A simple view action for the document would be more appropriate.</p>
<p>Alternatively, it would probably be sufficient to omit the URL altogether, and instead just indicate the docid and include a link to the ESA registry home page as a convenience.</p> Bug #4838 (Resolved): Permissions error for link contained in Data Set Citation sectionhttps://projects.ecoinformatics.org/ecoinfo/issues/48382010-02-24T22:24:33ZJim Regetzregetz@nceas.ucsb.edu
<p>It's easiest to describe this by documenting the steps to reproduce. This involves ESA, but I haven't checked whether it happens with non-public documents viewed using other registries.</p>
<p>After logging into ESA, click My Submissions (or View Submissions if logged in as a moderator), then click to view any one of the listed documents. Note that these are all documents that are <strong>not</strong> publicly readable, but should be readable by the logged-in user. The Data Set Citation section near the top of the document contains a link that refers to the document itself, e.g.: <a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/metacat/esa.65.3/esa">http://esa-dev.nceas.ucsb.edu/esa/metacat/esa.65.3/esa</a></p>
<p>Clicking on the link produces an error:</p>
<p>--------------------------------<br />This XML file does not appear to have any style information associated with it. The document tree is shown below.</p>
<p><error><br />User public does not have permission to read the document with the docid esa.65.3<br /></error><br />--------------------------------</p>
<p>The underlying URL for the example above is:<br /><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/metacat?action=read&qformat=esa&sessionid=&docid=esa.65.3">http://esa-dev.nceas.ucsb.edu/esa/metacat?action=read&qformat=esa&sessionid=&docid=esa.65.3</a></p>
<p>Perhaps the issue is the missing session variable?</p> Bug #4837 (Resolved): Permission error when ESA moderator attempts to modify a documenthttps://projects.ecoinformatics.org/ecoinfo/issues/48372010-02-24T22:11:12ZJim Regetzregetz@nceas.ucsb.edu
<p>The "Revise document" notification emailed to moderators currently contains a URL that looks something like this:</p>
<p><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65">http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65</a></p>
<p>If already logged in as a moderator (and not the owner of this document), clicking this link produces the following:</p>
<p>---------------------------<br />Failure<br />An error occurred. Please check the list of errors below:</p>
<ul>
<li>You don't have permission to edit this document, which is owned by uid=test,o=NCEAS,dc=ecoinformatics,dc=org. (Access Error <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: some required elements should be optional (Resolved)" href="https://projects.ecoinformatics.org/ecoinfo/issues/3">#3</a>)<br />---------------------------</li>
</ul>
<p>ESA moderators, i.e. members of cn=esa-moderators,dc=ecoinformatics,dc=org, should have ALL permissions by default, so presumably they should be able to modify this document (and there may be times when they need to be able to do so).</p> Bug #4835 (Resolved): ESA review comments don't appear to users when viewing their documentshttps://projects.ecoinformatics.org/ecoinfo/issues/48352010-02-24T21:48:54ZJim Regetzregetz@nceas.ucsb.edu
<p>After the moderator enters review comments and sends a document back for revision, those comments are visible to the moderator in the left panel when viewing the document. However, when the original document submitter logs in and views that same document, the panel on the left reports "No reviews found".</p>
<p>I would imagine the submitter <strong>should</strong> be able to see the reviews, but in any case it certainly shouldn't say "No reviews found".</p> Bug #4834 (Resolved): Request to modify document redirects to registry home after loginhttps://projects.ecoinformatics.org/ecoinfo/issues/48342010-02-24T21:39:24ZJim Regetzregetz@nceas.ucsb.edu
<p>The "Revise document" notification emailed to document submitters currently contains a URL that looks something like this:</p>
<p><a class="external" href="http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65">http://esa-dev.nceas.ucsb.edu/esa/cgi-bin/register-dataset.cgi?stage=modify&cfg=esa&docid=esa.65</a></p>
<p>This redirects to the login page if the user is not already logged in, which makes sense. However, after logging in, the user gets dumped back at the home page rather being presented with the requested page.</p>
<p>Not sure if this issue is specific to ESA.</p> Bug #4818 (Resolved): ESA does not send an email to moderators when new document is added via reg...https://projects.ecoinformatics.org/ecoinfo/issues/48182010-02-22T17:50:42ZMichael Daigledaigle@nceas.ucsb.edu
<p>The register-dataset.cgi does not send an email when a new document is created via the ESA skin. It used to, and still should.</p> Bug #4787 (Resolved): User having WRITE permission couldn't update a documenthttps://projects.ecoinformatics.org/ecoinfo/issues/47872010-02-11T01:16:54ZJing Taotao@nceas.ucsb.edu
<p>I think i reproduced the bug Jim mentioned:</p>
<p>A user having WRITE permission couldn't update a document.</p>
<p>Here are steps I did:<br />1. Create a simple document under user uid=jing. This document gives "READ+WRITE" permission to user uid=tao.<br />2. Save the document to metacat dev server as jing.4.1<br />3. Switch to another profile which has uid=tao. <br />4. Search online to find jing.4.1 and open it.<br />5. Make minor change on its title.<br />6. Save it to metacat and get the error:<br /><?xml version="1.0"?><error>User tried to update an access module when they don't have "ALL" permission!</error></p>
<p>I did another test:<br />All conditions are same except giving uid=tao "ALL" permission rather than "READ+WRITE" permission. This time, the updated document by uid=tao can be sent to metacat successfully.</p>
<p>It seems metacat doesn't handle a user's update action correctly, who only has "READ+WRITE" permission.</p> Bug #4716 (Resolved): Metacat should run against Tomcat 6https://projects.ecoinformatics.org/ecoinfo/issues/47162010-02-01T17:46:49ZMichael Daigledaigle@nceas.ucsb.edu
<p>Matt sent:</p>
<p>Here are the two main issues I encountered in getting Metacat to run under tomcat6.</p>
<p>1) servlet-api.jar moved locations, so I needed to change build.xml. It would have been better to change it so that it could find the file in either the tomcat5 location or the tomcat6 location, but I just changed the path in place to allow compilation to continue.</p>
<p>hail:~/development/metacat jones$ svn diff build.xml <br />Index: build.xml
===================================================================<br />--- build.xml (revision 5204)<br />+++ build.xml (working copy)<br /><code>@ -48,7 +48,7 </code>@</p>
<pre><code>&lt;target name="config"&gt;<br /> &lt;property name="jsdk" <br />- value="${build.tomcat.dir}/common/lib/servlet-api.jar" /><br />+ value="${build.tomcat.dir}/lib/servlet-api.jar" /><br /> &lt;!-- usr for client testing, generally you don't need change--&gt;<br /> &lt;property name="mcuser" <br /> value="uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org" /></code></pre>
<p>2) Metacat was not allowed permission to log under tomcat6, so I had to add a new policy file to enable it:</p>
<p>grant codeBase "file:${catalina.base}/webapps/knb/-" {<br /> permission java.security.AllPermission;<br />};</p>
<p>I added that as a file (/etc/tomcat6/policy.d/51metacat.policy) where tomcat would load it. I probably should have granted a more limited set of permissions, but there were a bunch of errors related to logging so I decided to just open up the metacat code.</p>
<p>Other than that things seemed to work. I haven't run the unit tests on it in this configuration.</p> Bug #4645 (Resolved): handleGetRevisionAndDocTypeAction should search both xml_documents and xml_...https://projects.ecoinformatics.org/ecoinfo/issues/46452010-01-04T22:30:28ZJing Taotao@nceas.ucsb.edu
<p>handleGetRevisionAndDocTypeAction API will return both revision and doctype for a given docid. Currently, it only searchs the xml_documents. It may gives clients a wrong message in this case:</p>
<p>There is no record in xml_documents, but it did have records in xml_revision table.</p>
<p>Here is the solution:</p>
<p>1. Search xml_documents table first. If metacat finds a result, returns it back to client.<br />2. If couldn't find result in xml_documents, then search xml_revisions table.</p> Bug #4637 (Resolved): Metacat Harvester fails to catch some insert and update failureshttps://projects.ecoinformatics.org/ecoinfo/issues/46372009-12-17T19:34:31ZDuane Costadcosta@lternet.edu
<p>Metacat Harvester is not catching all insert and update errors.</p>
<p>Recently at LTER, there have been a handful of documents that have been reported by Metacat Harvester as successful inserts or updates, but in fact the documents are not being successfully inserted or updated into Metacat. <br />The logical error is in method HarvesterDocument.putMetacatDocument(). The problem is that Harvester treats the absence of an exception as a success condition, when it should instead require hard confirmation of success from the Metacat client that the insert or update operation succeeded:</p>
<pre><code>if (harvester.connectToMetacat()) {<br /> try {<br /> if (insert) {<br /> metacatReturnString = metacat.insert(docidFull, stringReader, null);<br /> inserted = true;<br /> harvester.addLogEntry(0, docidFull + " : " + metacatReturnString, <br /> "harvester.InsertDocSuccess", <br /> harvestSiteSchedule.siteScheduleID, <br /> null, "");<br /> }<br /> else if (update) {<br /> metacatReturnString = metacat.update(docidFull, stringReader, null);<br /> updated = true;<br /> harvester.addLogEntry(0, docidFull + " : " + metacatReturnString, <br /> "harvester.UpdateDocSuccess", <br /> harvestSiteSchedule.siteScheduleID, <br /> null, "");<br /> }<br /> }<br /> catch (MetacatInaccessibleException e) {<br /> logMetacatError(insert, metacatReturnString, <br /> "MetacatInaccessibleException", e);<br /> }<br /> catch (InsufficientKarmaException e) {<br /> logMetacatError(insert, metacatReturnString, <br /> "InsufficientKarmaException", e);<br /> }<br /> catch (MetacatException e) {<br /> logMetacatError(insert, metacatReturnString, "MetacatException", e);<br /> }<br /> catch (IOException e) {<br /> logMetacatError(insert, metacatReturnString, "IOException", e);<br /> }</code></pre>
<p>Harvester does not check the value of the string returned by Metacat ('metacatReturnString' in the above code). In the cases where the insert/update operations have been failing, the return string is empty or null. Harvester should examine the return string to confirm that it contains the substring "<success>" or something similar.</p>
<p>The fact that no exception is thrown by Metacat could point to an additional problem in Metacat, since the insert/update operation completes without raising an exception even though the document is not inserted or updated. The documents that appear to trigger this condition are unusually large EML documents (currently there are three documents from CDR and one document from LUQ that trigger this bug).</p>
<p>After the Harvester bug is resolved, or as part of resolving it, further investigation should be done to determine whether there is also a Metacat bug involved here, and if there is, a separate bug entry should be entered for it.</p>