Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362017-10-05T00:43:02ZEcoinformatics Redmine
Redmine Bug #7213 (New): Document the EZID landing page template propertyhttps://projects.ecoinformatics.org/ecoinfo/issues/72132017-10-05T00:43:02ZChris Jonescjones@nceas.ucsb.edu
<p>Mike Frenock pointed out some issues with the <code>guid.ezid.uritemplate.metadata</code> property. We need to add this to the documentation. Also, consider if we should make this configurable to an external server instad of the local Metacat server.</p> Bug #7203 (In Progress): Improve D1NodeService.isAuthorized() performancehttps://projects.ecoinformatics.org/ecoinfo/issues/72032017-07-22T23:14:48ZChris Jonescjones@nceas.ucsb.edu
<p>We're seeing poor performance in calls to <code>D1NodeService.isAuthorized()</code> on <a class="external" href="https://arcticdata.io">https://arcticdata.io</a>. When the system Metacat is under light load (< 10 requests per second), calls to <code>isAuthorized()</code> are taking up to 35 seconds to return either an <code>HTTP 200</code> response or a <code>HTTP 403</code> exception.</p>
<p>Change <code>isAuthorized()</code> to prioritize user-based authorization first, and then CN or MN authorization last. This should increase performance for end users, whereas MN to MN replication calls and CN-administrative calls will be slightly less prioritized.</p>
<p>Note that calls to <code>userHasPermission()</code> involve token verification using the <code>PortalCertificateManager</code> and the <code>TokenGenerator</code>. These calls may be repeatedly making a call to the CN to get the SSL certificate for verification if it is not cached. If this change doesn't significantly improve performance, look into refactoring those classes in <code>d1_portal</code> to cache and use the certificate, unless there is a verification exception, in which case we make the call to <code>fetchCertificate()</code> again, re-cache it, and attempt to re-verify the token. If it still fails, throw <code>NotAuthorized</code>.</p> Bug #7178 (New): MNodeService.getPackage() takes too long for large packageshttps://projects.ecoinformatics.org/ecoinfo/issues/71782017-03-29T14:22:46ZChris Jonescjones@nceas.ucsb.edu
<p>When users click on the <code>Download All</code> button in MetacatUI, we call <code>MN.getPackage()</code> to zip up the members, create HTML and PDF metadata, etc. For very large packages, the packaging time is far too long for a decent user experience. To address this, we may need to provide some sort of progress API call that allows the client to get estimated packaging time and provide a progress bar for the user. Also, <code>getPackage()</code> uses <code>File.createTempFile()</code> to copy contents into a single directory tree for zipping (really BagIt bagging). This doesn't scale well for large packages (GBs). We can explore a few strategies to mitigate this. One that comes to mind is using hard symbolic links to the original data files in the directory tree rather than copying them. This needs some thought, but ultimately we need to speed up the packaging process for large packages.</p> Bug #4573 (New): LDAP and Register CGIs reference skin-specific templates in the common areahttps://projects.ecoinformatics.org/ecoinfo/issues/45732009-11-23T18:00:28ZChris Jonescjones@nceas.ucsb.edu
<p>This is a minor issue were the register-dataset.cgi and ldapweb.cgi scripts use a common tempatesDir pointing to the location of the common Template Toolkit files, but NCEAS and PARC-specific skin templates are also located in that common directory. The CGIs need to be changed to separate the common vs skin specific templates.Once changed, the NCEAS and PARC properties files should reflect the change.</p> Bug #3396 (In Progress): Enable event notification featurehttps://projects.ecoinformatics.org/ecoinfo/issues/33962008-06-14T17:34:35ZChris Jonescjones@nceas.ucsb.edu
<p>We would like to propose some changes to Metacat's event logging <br />feature to extend the functionality and provide a notification feature <br />that alerts data set owners and/or interested parties of downloads and <br />other events. We plan on prototyping the changes, and would like <br />input and suggestions from other metacat developers on the features <br />and implementation.</p>
<p>For an email notification system (or other, such as RSS) to work, it <br />would require a mechanism for the end user to 'subscribe' to <br />notifications based on events. In brainstorming this, we thought that <br />the subscription could be based on, perhaps, a hand chosen <br />notification list of packageIds by data set or data set group (e.g. <br />'notify me about events on: PISCO intertidal/subtidal/physical ocean/ <br />data packages' ...). Expressing these groupings might be done via a <br />pathquery document or a cached query that produces a packageId list. <br />Suggestions are welcome on the best method to associate a data package <br />docid list and an email address of a person to be notified.</p>
<p>The information that's logged in metacat's access_log table is <br />sufficient for general reporting:</p>
<p>- registered user LDAP DN<br /> user name<br /> affiliated organization name<br />- event date/time stamp<br />- event type<br />- docid<br />(However, in building an email [or an RSS feed], the data package <br />title would be a more friendly way of displaying which package was <br />downloaded, etc.)</p>
<p>The changes to metacat would also likely a include mechanism to <br />register an event listener that monitors changes to the model backed <br />by the access_log table. For instance, a researcher might post the <br />following to metacat:</p>
<p>action=monitor&\<br />username=uid=rcore,o=PISCO,dc=ecoinformatics,dc=org&\<br />qformat=email&\<br />event=read&\<br />query=< the pathquery document that produces a package list ></p>
<p>By doing so, this action would register the listener, and the listener <br />would provide a callback used to handle the event notification. At <br />the moment, only metacat administrators have access to the logging <br />information via the getlog action.</p>
<p>Once someone is registered to monitor events, metacat would have to <br />then provide notification over specific protocols. The notification <br />process may be easiest if metacat includes an SMTP send-only server, <br />such as Aspirin, an embeddable SMTP server.</p>
<p><a class="external" href="https://aspirin.dev.java.net/">https://aspirin.dev.java.net/</a></p>
<p>There are other push mechanisms that could be used (like RSS), but the <br />researchers we work with specifically asked for email-based <br />notification.</p>
<p>We'll enter a placeholder bugzilla report to keep track of this <br />feature, but thought that people would have suggestions on both the <br />design and implementation before we get started.</p>
<p>Please let us know what you think.</p>
<p>Rex, Chris, Mike, Jordan</p> Bug #2313 (New): Metacat Skins: Skins should not be installed by defaulthttps://projects.ecoinformatics.org/ecoinfo/issues/23132005-12-08T18:50:45ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>Not all skins should be installed when metacat is installed. Hence it should be <br />configurable in build.properties which skins should be installed. And bu <br />default, only default skin should be installed.</p>
<p>Also skins like esa should not be part of the shipped release.</p> Bug #1324 (New): A Commit or Save Work button that wrote intermediate results to the metadatahttps://projects.ecoinformatics.org/ecoinfo/issues/13242004-02-06T03:38:14ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>From Ricks comments:<br />Entering metadata using the Data Repository screen can take 10 to 30 minutes or <br />longer; sometimes Internet connections can fail or browsers crash, which leads <br />to loss of data. It would be reassuring and productivity-enhancing if the <br />screen had a ‘Commit’ or ‘Save Work’ button that wrote intermediate results to <br />the metadata. I realize that this can be done by saving and then re-opening the <br />(existing) data package for further entry; but a ‘one-button’ solution would be <br />even better.</p>