Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362011-08-30T01:28:18ZEcoinformatics Redmine
Redmine VegBank - Bug #5478 (New): after querying plants, communities, or plots, link back to searchhttps://projects.ecoinformatics.org/ecoinfo/issues/54782011-08-30T01:28:18ZMichael Leemlee@nceas.ucsb.edu
<p>When searching for something, web sites often want you to be able to modify your search terms easily and search again. We should do that. Now, you have to use the back button.</p>
<p>Seems like we could include part of the search page (fancy option) or at least offer a backlink to it, with the form filled out, ideally.</p> VegBank - Bug #4497 (New): Allow remote query from NVCRS and return useful data (not just view)https://projects.ecoinformatics.org/ecoinfo/issues/44972009-10-22T19:16:32ZMichael Leemlee@nceas.ucsb.edu
<p>This is not too challenging, provided the format for returning data is specified. It should probably be VEGX format, which we need to implement anyway. Should have a limit on returned plots, but indicate that there are more plots available. Otherwise it will be too slow. This should then be cached on the NVCRS side so that if a user wants to download plot data, they can (p77,43). Limitations of plot use enforced (of course)!</p>
<p>Source is section 2.1.4 number 26 of requirements document, page 20</p> InfoVeg - Bug #3800 (New): 1/28/2009 CONTAINER bughttps://projects.ecoinformatics.org/ecoinfo/issues/38002009-01-29T21:47:50ZMichael Leemlee@nceas.ucsb.edu
<p>This bug contains all related topics from the 1/28/2009 meeting with Forbes, Bob, Caroline, and Michael.</p> InfoVeg - Bug #3798 (New): Allow plot annotation from ANY databasehttps://projects.ecoinformatics.org/ecoinfo/issues/37982009-01-29T20:46:08ZMichael Leemlee@nceas.ucsb.edu
<p>The viewer will rarely connect to the copy of record archive database. So, if we want to change the archive database, it would be wise to create functionality where users looking at our data can create an update file of some sort to send us.</p>
<p>Functions:<br />*interpret a species-occurrence to a new plant concept<br />*interpret a plot to one or more communities<br />*add a note<br />*correct a data value<br />*bulk edit values - generate a template sheet for them to edit with the original values which they can update.</p> InfoVeg - Bug #3006 (New): Add LSID+GUID to data rowshttps://projects.ecoinformatics.org/ecoinfo/issues/30062007-11-16T19:04:43ZMichael Leemlee@nceas.ucsb.edu
<p>The best way of tracking duplicates is unfortunately not our current system, but rather a GUID that is an LSID that has a GUID in it:<br />format: urn:lsid:cvs.bio.unc.edu:[tableName]:PK-[GUID]<br />length should be at least 150, probably go to full 255.</p>
<p>This would have to be override-able as sometimes newly created entities should map onto existing ones. This would enable each client entry tool to create unique IDs for data- without the need to update each client after adding to archive db.</p>
<p>This is far better than our current PK+bln_new flag. It would be a new series of fields (or one table?) that would create GUIDs and assign them to entities.</p> InfoVeg - Bug #2924 (New): Add "use defaults on this plot" for parties and place namehttps://projects.ecoinformatics.org/ecoinfo/issues/29242007-09-01T19:11:58ZMichael Leemlee@nceas.ucsb.edu
<p>There is an option to use default for parties and place names, but a message appears saying you can't do that yet.</p> InfoVeg - Bug #2904 (New): Allow editing of default stratum method and cover methodhttps://projects.ecoinformatics.org/ecoinfo/issues/29042007-08-10T23:13:48ZMichael Leemlee@nceas.ucsb.edu
<p>These values are currently stored in X_otherOptions as names "stratumMethodAccessionCode" and "coverMethodAccessionCode". The accession codes could be changed to switch to a different method. But each would require types/indexes that have only a single character for the cover forms to work properly, and the default strata.</p> InfoVeg - Bug #2760 (New): add Quick fix for common errorshttps://projects.ecoinformatics.org/ecoinfo/issues/27602007-02-05T23:50:35ZMichael Leemlee@nceas.ucsb.edu
<p>need a quick fix for longitude is positive<br />also for filling in default of 10cm for minimum stem size.</p> InfoVeg - Bug #2663 (New): 2 errs left: + duplicates flagged: Project 73 (Mountain Bogs): 64 plotshttps://projects.ecoinformatics.org/ecoinfo/issues/26632006-11-13T17:46:29ZMichael Leemlee@nceas.ucsb.edu
<p>this data needs to be processed and added to the (v2006) central archive</p> VegBank - Bug #2164 (New): allow southern hemisphere UTM conversions.https://projects.ecoinformatics.org/ecoinfo/issues/21642005-08-01T23:16:30ZMichael Leemlee@nceas.ucsb.edu
<p>Needs to be added in options so that if someone is entering UTM's in Southern<br />Hemisphere, it will to the math right.</p> VegBank - Bug #1968 (New): Allow uploading of binary files to VegBank that "relate" to plots, pro...https://projects.ecoinformatics.org/ecoinfo/issues/19682005-02-10T21:04:13ZMichael Leemlee@nceas.ucsb.eduVegBank - Bug #1073 (New): Allow Users to edit Entities that they ownhttps://projects.ecoinformatics.org/ecoinfo/issues/10732003-05-22T18:11:31ZMichael Leemlee@nceas.ucsb.edu
<p>Allow users to edit party records that they are the owner of, i.e. they (the<br />user) are the same as the party (link via user database that identifies which<br />party.party_ID they are) that owns this record (party.owner).</p>
<p>all changes should be added to the revisions table.</p>
<p>Furthermore, split from bug 852:<br />------------------(bug 852, comment 4)---------<br />from Bob:</p>
<blockquote>
<p>1. There is the problem that there are party attributes that a user needs<br />to be able to update and which are not on the profile page that the user <br />edits. This should be added.</p>
</blockquote>
<p>That is, the party table has attributes not on the "edit profile" form. We need<br />to either add these fields to that form, or we need to make a new form for<br />people to edit any party that they are the owner of.</p>
<p>------------------(bug 852, comment 6)---------<br />We need some business rules here. Ownership is by a registered user. We <br />currently track registered users as unique by email address. We do not <br />require email for a party (we do not always know an email). How do we link <br />registered users with parties? And, how do we affect the transfer of <br />ownership from a second-party creator to a registered user who wants to take <br />over his own party?</p>
<p>I suggest:</p>
<p>1. We move to primary key as the unique identifier for a registered user so <br />that email is no longer the unique identifier. Upon logging in the registered <br />user should be able to edit his/her email address, just like other user <br />attributes.</p>
<p>[MTL - I like the idea of allowing users to change their email, provided the<br />email address they specify is not already on the system. Email would still be<br />the logon]</p>
<p>2. A new user when registering will create a new party by default. That user <br />can then send an email to the system manager requesting that one or more <br />extant parties be synonymized with the new party just created. This would <br />require that the manager reset part[y]:currentName_ID to point at the user’s <br />party record. This also suggests a new function needed in the management <br />interface.</p>
<p>3. We remove or minimize the redundancy between the user registration table <br />and the party table. We don’t want name, organization, address, etc stored in <br />both places.</p> VegBank - Bug #919 (New): Advanced IP system, user-specific filtering of datahttps://projects.ecoinformatics.org/ecoinfo/issues/9192002-11-27T21:31:14ZMichael Leemlee@nceas.ucsb.edu
<p>Confidential plots (that is plot with plot.ConfidentialityStatus = 6) must not<br />be viewable in the system. Also not downloadable or queryable. They stay hidden.</p>
<p>The following are the rules for confientiality:<br />values valueDescription<br />0 Public <br />1 1 km radius<br />2 10 km radius<br />3 100 km radius<br />4 Location embargo<br />5 Public embargo on data<br />6 Full embargo on data</p>
<p>0 means that anyone can access all data belonging to the plot.<br />1-3 mean that latitude and longitude are "fuzzed" to some degree so that the<br />user doesn't know exactly where the plot is.<br />4 means that users can't access data from the place table for that plot, as well<br />as the lat/long. LocationNarrative and authorE, authorN, authorLocation in the<br />plot table should also be hidden.<br />5 and 6 mean that users can't access the plot at all - no attributes on any<br />tables.</p>
<p>RealLatitude and RealLongitude should ALWAYS be hidden from the user. Use<br />latitude and longitude instead.</p> VegBank - Bug #750 (New): Allow users to write plug-ins for third party data formats, export and ...https://projects.ecoinformatics.org/ecoinfo/issues/7502002-11-13T21:49:22ZMichael Leemlee@nceas.ucsb.edu
<p>Would be nice, as time allows; till then VegBranch</p> VegBank - Bug #713 (New): Add intermediate levels to plantStatus, between standard levels.https://projects.ecoinformatics.org/ecoinfo/issues/7132002-11-13T21:45:13ZMichael Leemlee@nceas.ucsb.edu
<ul>
<li>In 2003 we should add a type of level that is interemediate between two<br />levels, so as to accommodate the needs of the cladist community [for<br />conceptstatus, nameestatus, plantconvergence,plantsystem]</li>
</ul>