Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362002-03-07T22:50:36ZEcoinformatics Redmine
Redmine Bug #442 (Resolved): There is no entry in xml_access table for access document itselfhttps://projects.ecoinformatics.org/ecoinfo/issues/4422002-03-07T22:50:36ZJing Taotao@nceas.ucsb.edu
<p>When we create a data package in Morpho and save it into metacat. But there is <br />no permission in xml_access table for access document itself.</p>
<p>Now we discard a permission rule - if there is no entry in xml_access table <br />for a document, this document will have same permission to data set permission <br />to the user. The rule now we are using is: if the there is no entry in <br />xml_access table for a document, if the user is owner, it has permission. <br />Otherwise, it doesn't have permission.</p>
<p>So we need to create entries for access document itself in xml_access table.</p> Bug #441 (Resolved): Unable to increment data id revision numbershttps://projects.ecoinformatics.org/ecoinfo/issues/4412002-03-05T23:28:31ZDan Higginshiggins@nceas.ucsb.edu
<p>In an attempt to let the Morpho user update a data file (NOT a metadata doc), it<br />was discovered that Metacat returns the following when an attempt is made to<br />insert a revised data document, eg 801.1 --> 801.2</p>
<p>Same code works when a new id is used rather than one with incremented version #.</p>
<p><error><br />ORA-00001: unique constraint (TAO.XML_DOCUMENTS_PK) violated</p> Bug #417 (Resolved): Is sequential numbering of versions needed?https://projects.ecoinformatics.org/ecoinfo/issues/4172002-02-08T17:06:50ZDan Higginshiggins@nceas.ucsb.edu
<p>Currently, version changes of documents must be sequentially numbered. This<br />means that someone working locally in Morpho might make 6 changes to a document<br />and 6 versions must be sent to Metacat in order, even though only the last one<br />is meant to be submitted. Also, if any of the early version is invalid then the<br />whole submission fails. Likewise, a download of any datapackage requires the<br />download of all version, even if only the most recent is needed.</p>
<p>Therefore, I suggest that submission of new versions only require that the new<br />version number be greater than the current one, not exactly one greater.</p> Bug #411 (Resolved): package export featurehttps://projects.ecoinformatics.org/ecoinfo/issues/4112002-02-05T00:57:51ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat needs to be able to produce an exported version of a data package in the<br />same ZIP format that morpho creates data package exports. This involves getting<br />all of the metadata and data files associated with the package, arranging them<br />in the directory correctly, and producing an html summary. The code for this is<br />essentially complete in morpho and should usable in metacat almost directly.</p>
<p>Note that the morpho export dows some funny things, like puts all of the data<br />files inthe metadata directory. We need to fix this as well. I suggest an<br />export structure like this:</p>
<p>package.dir
|
|---- data
| |
| |------d1.1
| |------d2.1
|
|---- metadata
| |
| |------m3.1
| |------m4.1
|
|---- metadata.html</p> Bug #407 (Resolved): ldapweb.cgi confusing wrt 'other' organizationshttps://projects.ecoinformatics.org/ecoinfo/issues/4072002-01-29T16:43:56ZMatt Jonesjones@nceas.ucsb.edu
<p>From Dan Higgins:<br /> I discovered that I need to set the organization to 'unaffiliated' in order<br />to login after creating an account with 'Other' as the organization on the KNB<br />web page! This is likely to be pretty confusing for many potential users.<br />Perhaps the web page should have 'unaffiliated' rather than 'other'?</p>
<p>Comments from Matt Jones:<br />I agree. Will change on web forms.</p> Bug #403 (Resolved): LDAP and LTER personnel password synchronization problemshttps://projects.ecoinformatics.org/ecoinfo/issues/4032002-01-23T17:53:32ZDavid Blankmandblankman@lternet.edu
<p>Discovered that the the random password generator function in the new person entry script (entry <br />into sql server database and LDAP database) is actually being called twice. Need to fix this. <br />Currently the password entered into the database and the one emailed to users don't match.</p> Bug #366 (Resolved): Install & Test LDAP SSL Componenet for o=lter serverhttps://projects.ecoinformatics.org/ecoinfo/issues/3662001-12-03T18:00:38ZDavid Blankmandblankman@lternet.edu
<p>Need to reconfigure o=lter LDAP server to support SSL, also implement Hashed password for <br />password creation.</p> Bug #332 (Resolved): hub replication featurehttps://projects.ecoinformatics.org/ecoinfo/issues/3322001-11-29T22:09:23ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat replication is currently configured such that transfers are not<br />transitive (ie, if A replicates to B, and B replicates to C, the only data that<br />B will replicate to C is its own data). This is meant to prevent people from<br />having to set up extended trust netorks. This is a problem, however, for the<br />centralized access points that we designed for NCEAS/LTER.</p>
<p>At the annual meeting, we agreed that we need a special 'hub' replication<br />feature which enables a few special metacat servers to act as a virtual hub. <br />All data and metadata on one of these special hub nodes will be replicated to<br />the other hub nodes, regardless of its origin.</p>
<p>For example, if NCEAS and LTER metacats are the hub nodes, and NCEAS is<br />receiving replication data from NRS, and LTER is receiving replication data from<br />SEV, then all of the data would be replicated on both NCEAS and LTER hubs. <br />However, if the NRS metacat is getting data from a HAMILTON reserve metacat, the<br />NRS metacat will not replicate that HAMILTON data and metadata to NCEAS. This<br />preserves the trust relationship between NRS and HAMILTON, while allowing us to<br />create a virtual aggregation at the NCEAS/LTER hub. if HAMILTON wants its data<br />to show up on both the NRS and the NCEAS metacats, it will need to establish a<br />peering relationship with them both separately (e.g., HAMILTON -> NRS and<br />HAMILTON -> NCEAS).</p> Bug #331 (Resolved): metacat data replication featurehttps://projects.ecoinformatics.org/ecoinfo/issues/3312001-11-29T22:01:02ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat currently does not replicate data objects. Agreed at the 2001 annual<br />meeting that it should be an option to replicate data just as metadata works. <br />This should be configurable by each metacat administrator, and should be<br />independent of the metadata replication option (ie, metacat admins can choose to<br />replicate nothing, metadata only, or metadata and data.</p>
<p>If data is not replicated between servers, but metadata is, some queries will<br />return packages that refer in the triples to data entities that don't reside on<br />the server that is queried. The queried server has the information it needs to<br />retrieve the data set from the home server (identifier + home server code), and<br />so we need a mechanism to do this in metacat. Thus, if a user requests a<br />download of lter.4.1 from the NCEAS metacat, but the data hasn't been replicated<br />from the lter metacat, then the NCEAS metacat will be able to forward the<br />request to the LTER metacat, get the data object, and then satisfy the original<br />request made by the user. All of this happens without the user knowing that the<br />data object was located on another server.</p>
<p>Note this feature will be influenced by the "hub" concept, described in another bug.</p> Bug #329 (Resolved): groups ACLs do not work against LDAPhttps://projects.ecoinformatics.org/ecoinfo/issues/3292001-11-26T23:28:09ZMatt Jonesjones@nceas.ucsb.edu
<p>The use of a "group" principal does not work when the AuthLdap adapter is<br />working. This was traced to problems in the get Groups() and getUsers() methods<br />of AuthLdap.</p> Bug #328 (Resolved): ldap referrals crash system when one referree is downhttps://projects.ecoinformatics.org/ecoinfo/issues/3282001-11-20T19:59:34ZChad Berkleyberkley@nceas.ucsb.edu
<p>the ldap authentication system crashes metacat if one of the referree servers is down and a referral is called. I do not know what the source of this error is or if it is a catchable exception. it needs to be looked into in more detail.</p> Bug #309 (Resolved): metacat does not follow LDAP referralshttps://projects.ecoinformatics.org/ecoinfo/issues/3092001-10-26T00:45:28ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat can't authenticate against the LTER ldap db because it doesn't need to<br />follow referrals properly. It was never implemented this way. Need to modify<br />the AuthLdap class to do so. This can be done by following the examples for<br />JNDI at ther following url:</p>
<p><a class="external" href="http://java.sun.com/products/jndi/tutorial/ldap/referral/follow.html">http://java.sun.com/products/jndi/tutorial/ldap/referral/follow.html</a></p> Bug #303 (Resolved): replace oracle xslt with xalan xslthttps://projects.ecoinformatics.org/ecoinfo/issues/3032001-10-22T00:12:57ZMatt Jonesjones@nceas.ucsb.edu
<p>Need to upgrade to a more spec-compliant CSLT engine, which looks like it should<br />be Xalan suing TraX at this point in time.</p> Bug #278 (Resolved): Install production o=LTER LDAP Serverhttps://projects.ecoinformatics.org/ecoinfo/issues/2782001-09-04T21:43:51ZDavid Blankmandblankman@lternet.edu
<p>INSERT push from LTER personnel database completed and tested.<br />UPDATE push from LTER personnel database programming logic completed. Code <br />needs to be written and tested.<br />SECURE configuration needs to be implemented.<br />REFERRAL mechanism needs to be tested.<br />TARGET completion date: 10/1/2001</p> Bug #258 (Resolved): upgrade to xerces 1.4.1 and test metacathttps://projects.ecoinformatics.org/ecoinfo/issues/2582001-07-23T16:07:06ZMatt Jonesjones@nceas.ucsb.edu
<p>Need to upgrade our version of the Xerces jar file to 1.4.1 in order to get the<br />bug fixes and advanced schema support of the new version of xerces.</p>