Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362007-03-10T01:06:08ZEcoinformatics Redmine
Redmine Bug #2796 (Resolved): ESA registry gets locked into searching KNBhttps://projects.ecoinformatics.org/ecoinfo/issues/27962007-03-10T01:06:08ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>The ESA registry webpage gets stuck into always searching the KNB for queries after an initial search across the entire KNB. To reproduce this bug:<br />1) select "search ALL of KNB" and enter a search term<br />2) look at those results<br />3) use the back button on the browser<br />4) then select "search only ESA"</p>
<p>At this point, even though the controls say only to search within ESA, the search query gets sent to knb.ecoinformatics.org, rather than the ESA metacat</p> Bug #2647 (Resolved): ESA registry doesn't have LTER in login dropdown menuhttps://projects.ecoinformatics.org/ecoinfo/issues/26472006-11-07T23:11:54ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>The ESA data registry login page <a class="external" href="http://data.esa.org/cgi-bin/register-dataset.cgi?cfg=esa">http://data.esa.org/cgi-bin/register-dataset.cgi?cfg=esa</a><br />does not include LTER in the drop down menu for organizations. This will prevent users with LTER accounts from loggin into the ESA data registry. LTER needs to be added to this menu.</p> Task #2635 (Closed): Look up for forgotten KNB account nameshttps://projects.ecoinformatics.org/ecoinfo/issues/26352006-10-31T22:12:52ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>There should be an easy way for users to submit their email on a form on the KNB website, and have an email sent to them listing the account names affiliated with that email. This would prevent users from having to submit requests for lost or forgotten KNB account names to knb-help.</p> Bug #2501 (New): Add links to FGDC-tranformed version of EML documentshttps://projects.ecoinformatics.org/ecoinfo/issues/25012006-07-27T16:51:32ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>When viewing EML documents, the user should be provided with a link (under "Metadata Downloads") that gives the EML-to-FGDC transformed version of the metadata.</p> Bug #2229 (New): Allowing web registry pull-down menu for "Station Name" to select multiple stat...https://projects.ecoinformatics.org/ecoinfo/issues/22292005-10-11T23:07:08ZWill Tyburczytyburczy@nceas.ucsb.eduBug #2228 (New): Use method other than metadata string filters for determining the organizations ...https://projects.ecoinformatics.org/ecoinfo/issues/22282005-10-11T23:04:46ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>Right now when data is registered through an organization's skin, the metadata<br />for the entry is made to include a specific string, such as "UC Natural Reserve<br />System". When listing all the data packages from that organization, the current<br />method is to use that string as a filter. Unfortunately, if a data package<br />affiliated with an organization (such as the NRS) is submitted via a different<br />registry (such as ESA), the data package won't show up in the list of that<br />organization's data. Thus, a different approach is needed.</p>
<p>From Matt's email:</p>
<p>"The right way to do this would be to decouple the metadata entry from <br />the filter that controls whether a given entry shows up in the registry. <br /> We've been experimenting with some ways to do this through 'semantic <br />annotations' that are maintained separately from the rest of the <br />metadata. This would allow us to retroactively label data packages with <br />annotations that could control which skin they show up in. It still <br />doesn't solve the maintenance problem (for each new registry skin that <br />we create, we need to annotate all past data packages that we want to <br />show up in the skin). I'm still not sure how to deal with that issue."</p> Bug #2227 (Resolved): Data associated with an organization should show uphttps://projects.ecoinformatics.org/ecoinfo/issues/22272005-10-11T22:54:16ZWill Tyburczytyburczy@nceas.ucsb.edu
<p>"The right way to do this would be to decouple the metadata entry from <br />the filter that controls whether a given entry shows up in the registry. <br /> We've been experimenting with some ways to do this through 'semantic <br />annotations' that are maintained separately from the rest of the <br />metadata. This would allow us to retroactively label data packages with <br />annotations that could control which skin they show up in. It still <br />doesn't solve the maintenance problem (for each new registry skin that <br />we create, we need to annotate all past data packages that we want to <br />show up in the skin). I'm still not sure how to deal with that issue."</p>