Morpho: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362009-05-19T17:17:51ZEcoinformatics Redmine
Redmine Bug #4084 (Resolved): Change access rule to be "allowFirst" as the default orderTypehttps://projects.ecoinformatics.org/ecoinfo/issues/40842009-05-19T17:17:51ZJing Taotao@nceas.ucsb.edu
<p>[4:36pm] matt: i just caught up on your earlier irc chat<br />[4:36pm] matt: wanted to chime in<br />[4:36pm] matt: chris said:<br />[4:36pm] matt: chris: right - it seems like an odd case. I think that<br />the vast majority of cases, people will want to deny public access,<br />and puch through access for other groups or individuals<br />[4:36pm] matt: and also:<br />[4:37pm] matt: you said:<br />[4:37pm] matt: daigle: the only real exception that I see is allowing<br />access to the whole, but denying it to individuals/groups<br />[4:37pm] matt: [2:44pm] daigle: that does not seem like a large use case<br />[4:37pm] matt: i actually think that is the only use case for using denyFirst<br />[4:37pm] matt: sorry , i actually think that is the only use case for<br />using <strong>deny</strong> at all<br />[4:38pm] daigle: right<br />[4:38pm] daigle: only one I could think of<br />[4:38pm] matt: the default, in the absence of a public=read rule, is to deny<br />[4:38pm] matt: so, most of the time, someone will positively add some<br />allow rules<br />[4:39pm] matt: and then they may want to exclude some people from that group<br />[4:39pm] matt: ie, grant kruger-tpc=read, but deny regetz<br />[4:39pm] matt: for that you would want allowFirst<br />[4:39pm] matt: if all you are doing is granting permissions to people,<br />you can leave the defaults and just add in an allow rule<br />[4:39pm] matt: make sense?<br />[4:40pm] daigle: uh<br />[4:40pm] daigle: default deny then add then deny<br />[4:40pm] matt: its a bit convulted to add deny public=read and then<br />allow kruger-tpc=read, because the deny public was implicit even<br />without the rule<br />[4:41pm] matt: i.e., if you want to deny public access, simply remove<br />the public=read rule and you're done<br />[4:43pm] daigle: okay<br />[4:43pm] matt: the only good reasons I can see to deny someone are to<br />1) efficiency: grant access to a big group but excise a few people, in<br />which case you want default rules to be allowFirst<br />[4:44pm] daigle: right<br />[4:44pm] matt: and 2) guarantee that a particular user doesn't have<br />access (indirectly via a group), in which case you still want<br />allowFirst<br />[4:45pm] matt: so thanks for hearing me out -- I just wanted to be<br />clear that Morpho's default allowFirst rule is the right rule in my<br />opinion</p>
<p>This is not just change from "denyFirst" to "allowFirst", we may do this for both top and entity level access rules:</p>
<p>If the user selects "No" (i.e., don't allow public read) and does nothing else, then an explicit public <deny> rule is inserted. This is required to override the<br />top-level access rules.</p>
<p>But if the user selects "No" <strong>and</strong> adds at least one special access rule (for a user/group), then the special access rule(s) is/are inserted, and the public <deny><br />rule is omitted because it is now superfluous. I think allowFirst will be fine this way.</p> Bug #4059 (Resolved): Using the new Morpho Guide to repalce onehttps://projects.ecoinformatics.org/ecoinfo/issues/40592009-05-11T21:08:50ZJing Taotao@nceas.ucsb.edu
<blockquote><blockquote><blockquote>
<p>Hi Jing,</p>
<p>I wanted to mention that you should include Kirsten's new Morpho User<br />Guide in the Morpho release, as it is both more accurate and more<br />readable that the original guide. �This may cause some issues with the<br />help system, and you'll need a way to display it as a pdf file.<br />Kepler has a way of opening PDF files from within Java, so we should<br />be able to do it in Morpho. �Any thoughts on what impact this might<br />have on the help system?</p>
<p>Thanks<br />Matt</p>
</blockquote></blockquote></blockquote>
<p>Ben pointed out we may use Jpedal library to display the pdf file. Jpedal has a version of GPL. However, the GPL version only has the source file and no build tool. I will put the source file into the lib dir and write a target in morpho build.xml to build a jar file.</p> Bug #4032 (Resolved): Backup .morpho directory before installing a new version of morphohttps://projects.ecoinformatics.org/ecoinfo/issues/40322009-04-29T01:25:41ZJing Taotao@nceas.ucsb.edu
<p>In morpho 1.7.0 release, there is some non-backward compatibility issues. 1.7.0 release will create eml210 document, but morpho 1.6.1 couldn't search it and read it. So if 1.7.0 doesn't work well, it is hard to switch back to morpho 1.6.1. If we backup the .morpho dir during the installation, it will be easy for user to switch back. The backup file may look like .morpho-1.7.0-beta1.tar.gz.<br />The issue is if we accumulate too many files, the disk space may run out.</p> Bug #4030 (Resolved): Support SSL in morphohttps://projects.ecoinformatics.org/ecoinfo/issues/40302009-04-27T23:36:44ZJing Taotao@nceas.ucsb.edu
<p>The SSL was support in morpho. However, now we only use plaint connection. We need to restore it.</p> Bug #4007 (Resolved): KNBRegistry thesaurus in keyword page doesn' workhttps://projects.ecoinformatics.org/ecoinfo/issues/40072009-04-21T18:55:19ZJing Taotao@nceas.ucsb.edu
<p>I got an email from Kirsten:</p>
<p>Could you point me to more information about the KNBRegistry thesaurus?<br />On my windows machine, when I try to select it, I get the following error:<br /> "parsing config file threw: java.net.MalformedURLException. And then I get<br /> a message "Could not load selected vocabulary".</p>
<p>This is windows installer (RC1). But this feature works on my linux development box.</p> Bug #3987 (Resolved): Obscured window when adding keyword from predefined list in OS Xhttps://projects.ecoinformatics.org/ecoinfo/issues/39872009-04-16T00:56:20ZJim Regetzregetz@nceas.ucsb.edu
<p>This arises during the Keywords step (step 3) of the New Data Package Wizard. Here are the steps to reproduce:</p>
<p>1. Click "Add". This opens a Define Keyword Set window.<br />2. Choose "These keywords are chosen from a predefined list", select either KNBRegistry or nbii, then click "Add". This opens a new window for keyword selection, e.g. Thesaurus Lookup.</p>
<p>The problem is that this second Lookup window opens "behind" the Define Keyword Set window. If you click on the Define Keyword Set window, the Lookup window pops forward, but as soon as you click on the Lookup window, it drops back again.</p>
<p>A workaround is to make sure your windows aren't overlapping :)</p>
<p>This problem only seems to happen during the New DP Wizard, <strong>not</strong> when adding keywords to existing DPs using the Documentation -> Keywords... option.</p> Bug #3834 (Resolved): After importing new Data Table, File/Save to Network failshttps://projects.ecoinformatics.org/ecoinfo/issues/38342009-02-23T23:58:39ZRick Reevesreeves@nceas.ucsb.edu
<p>Testing both on Macintosh and Windows XP platforms.</p>
<p>I searched for and found an existing Data Package (nceas:953:1),<br />and used the Data Table Wizard to import and create column<br />metadata for a tab-delimited ASCII file. I completed the Wizard,<br />clicked the hyperlink 'click here to import..', and the new<br />table appears in the Morpho spreadsheet display.</p>
<p>(What I dont get is confirmation that the table has been saved, <br />it just turns up in the spreadsheet. A message would be nice.)</p>
<p>Then, I want to update the network version of the package <br />(nceas:953:1) to contain the newly imported table. Or at least, <br />store a version of it with a related 'nceas:xx:yy' accession number. <br />So, I choose File/Save, and check both 'locally' and 'to the network'<br />boxes. The local copy is saved, but NOT the network copy is not updated.</p>
<p>The only way that I can save the uploaded table to the data package on <br />the network, is to use File/Synchronize. When I do this, a new copy of<br />the package is created with a new accession number: 'reeves:56:1'.</p>
<p>Seems like File/Save to Network should update the existing data package<br />on the network with the new table, or AT Least, create a copy with a <br />derived accession number (e.g.,nceas:953:12). This has confused one of<br />the EBM data managers trying to register their data sets.</p>
<p>Rick R</p> Bug #3831 (Resolved): change "precision" from required to optional in new package wizardhttps://projects.ecoinformatics.org/ecoinfo/issues/38312009-02-19T01:01:51ZJing Taotao@nceas.ucsb.edu
<p>Precision element in eml 201 and eml 210 is optional in tnterval and ratio measurement. However, in morpho it is required. We need to change it to optional.</p> Bug #3808 (Resolved): Export to zip file doesn't workhttps://projects.ecoinformatics.org/ecoinfo/issues/38082009-02-04T17:46:02ZShaun Walbridgewalbridge@nceas.ucsb.edu
<p>When trying to use the 'Export: Export to a zip file...' feature fails. It first reports that it successfully exported, but then throws an error:</p>
<p>Exception in exporting to zip file (AbstractDataPackage)</p>
<p>A zip file is created, but is corrupt.</p> Bug #3702 (Resolved): Change morpho uploading data filehttps://projects.ecoinformatics.org/ecoinfo/issues/37022008-12-15T19:41:02ZJing Taotao@nceas.ucsb.edu
<p>Currently when morpho upload a data file, it is used the file name under profile dir. This will end up that metacat will save the file name, e.g. 3.1, 4.3, as docname in xml_documents. It cause issue for metacat download data file name display (see bug 2566). We should use object name to replace the file name in profile.</p> Bug #3678 (Resolved): Incorporate FIRST features for generalized vocabulary lookuphttps://projects.ecoinformatics.org/ecoinfo/issues/36782008-11-19T02:18:50Zben leinfelderleinfelder@nceas.ucsb.edu
<p>While you can currently specify a "thesaurus" from which your keywordSet is derived, there is no way of actually selecting values from this [possibly nonexistent] vocabulary list.<br />The FIRST project is addressing this shortcoming with some enhancements. Those should be added directly to Morpho so that they can be used by both applications.</p> Bug #3601 (Resolved): Transform demo eml document from eml 2.0.1 to eml 2.1.0https://projects.ecoinformatics.org/ecoinfo/issues/36012008-11-06T23:44:18ZJing Taotao@nceas.ucsb.edu
<p>Currently, the demo eml document of morpho (jscientist.7.2) is eml 2.0.1. We need to transform it to eml 2.1.0.</p> Bug #3587 (Resolved): Create IzPack installer for morphohttps://projects.ecoinformatics.org/ecoinfo/issues/35872008-10-31T17:08:33ZJing Taotao@nceas.ucsb.edu
<p>We decided to use IzPack to generate morpho installer. We can learn it from kepler.</p> Bug #3459 (Resolved): Support EML 2.1.0 in Morphohttps://projects.ecoinformatics.org/ecoinfo/issues/34592008-07-25T15:28:46ZJing Taotao@nceas.ucsb.edu
<p>EML 2.1.0 release is coming. It is will be good if this release can support this new version of EML. Here are something we need to do:<br />1. The new generated eml documents will have EML 2.0.1 namespace.<br />2. Will give user an option to transfer EML 2.0.1 (2.0.0) to EML 2.1.0 documents when user open the old version eml documents(?)<br />3. Add EML 2.1.0 namespace into return document types in the path query.</p> Bug #3454 (Resolved): Fixing docid conflicts in metacat or local filehttps://projects.ecoinformatics.org/ecoinfo/issues/34542008-07-16T22:51:12ZCallie Bowdishbowdish@nceas.ucsb.edu
<p>Having Morpho profiles information loaded on different computers can cause file conflicts. One way to prevent this is by having each profile have a different identifier prefix. This does not require that a user have a different network account or even different profile name. However the part that should be unique is the Identifier prefix which is used as the scope for the document id. The following text can be added to the Data Package Identification part of creating a profile. It is stored in the profile under the scope element.</p>
<p>Text to replace the current text:</p>
<p>Enter a short identifier prefix. All data packages you create under this profile will bear this prefix. To prevent data package name conflicts it is recommended that you create a different prefix for each computer you load Morpho on.</p>
<hr />
<p>Please note that if the naming conventions, such as global lisd names, for data packages change the use of this to prevent file conflicts may become obsolete.</p>
<hr />
<p>Currently bug 3120 describes a section of the profile creation form that is not displaying correctly. It may be convenient to fix both of these as the same time.</p>