Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362016-10-18T19:04:48ZEcoinformatics Redmine
Redmine Bug #7144 (Resolved): MN certificate can't modify the system metadata of an object which's author...https://projects.ecoinformatics.org/ecoinfo/issues/71442016-10-18T19:04:48ZJing Taotao@nceas.ucsb.edu
<p>Details see this ticket <a class="external" href="https://redmine.dataone.org/issues/7915">https://redmine.dataone.org/issues/7915</a></p> Story #7142 (Closed): Upgrade Solr to 3.6 to fix searching issuehttps://projects.ecoinformatics.org/ecoinfo/issues/71422016-10-13T23:42:56ZLauren Walkerwalker@nceas.ucsb.edu
<p>It looks like Solr has trouble with using wildcards and case insensitive searching for fields - so when we search for originText:*Ashjian* we get 0 results, but with originText:*ashjian* we get 116. It looks like it was fixed in Solr 3.6: <br /><a class="external" href="https://issues.apache.org/jira/browse/SOLR-2438">https://issues.apache.org/jira/browse/SOLR-2438</a></p>
<p>On Slack, Matt, Chris, and I agreed that at some point soon we should upgrade Solr in Metacat.</p> Bug #7141 (Closed): Modify Metacat code according to the change of dataone library migrating from...https://projects.ecoinformatics.org/ecoinfo/issues/71412016-10-13T21:16:18ZJing Taotao@nceas.ucsb.edu
<p>We need to change the code to make Metacat compile.</p> Task #7095 (Closed): Improve error message for: User tried to update an access module when they d...https://projects.ecoinformatics.org/ecoinfo/issues/70952016-08-26T23:14:49ZBryce Mecummecum@nceas.ucsb.edu
<p>We get this error all the time when doing various (apparently illegal) operations:</p>
<blockquote>
<p>User tried to update an access module when they dont have ‘ALL’ permission!"</p>
</blockquote>
<p>Is there an easy way for this error message to become more useful? It's a message that gets leaked out to non-developer users and I would argue that it's a confusing error message that doesn't give enough information for the user to fix it.</p>
<p>It could be improved if it said which access module was the culprit and which object(s) was trying to assert access over.</p> Bug #7094 (Closed): Metacat is not expanding groups in the rightsHolder field during authorizationhttps://projects.ecoinformatics.org/ecoinfo/issues/70942016-08-26T17:24:30ZChris Jonescjones@nceas.ucsb.edu
<p>With a <code>SystemMetadata</code> document like:<br /><pre>
<?xml version="1.0" encoding="UTF-8"?>
<d1_v2.0:systemMetadata xmlns:d1_v2.0="http://ns.dataone.org/service/types/v2.0" xmlns:d1="http://ns.dataone.org/service/types/v1">
<serialVersion>0</serialVersion>
<identifier>urn:uuid:a0f68bc4-1b67-4376-964f-70df0b58376c</identifier>
<formatId>image/jpeg</formatId>
<size>223220</size>
<checksum algorithm="SHA256">60be2e67512b6f444be407a9cb87018b12e5bbf214deab3248c8d1834db8cb38</checksum>
<submitter>CN=Bryce Mecum A27576,O=Google,C=US,DC=cilogon,DC=org</submitter>
<rightsHolder>CN=arctic-data-admins,DC=dataone,DC=org</rightsHolder>
<accessPolicy>
<allow>
<subject>public</subject>
<permission>read</permission>
</allow>
<allow>
<subject>CN=Bryce Mecum A27576,O=Google,C=US,DC=cilogon,DC=org</subject>
<permission>write</permission>
</allow>
<allow>
<subject>CN=Bryce Mecum A27576,O=Google,C=US,DC=cilogon,DC=org</subject>
<permission>read</permission>
<permission>write</permission>
<permission>changePermission</permission>
</allow>
</accessPolicy>
<replicationPolicy replicationAllowed="true" numberReplicas="3"/>
<archived>false</archived>
<dateUploaded>2016-03-17T19:25:16.840+00:00</dateUploaded>
<dateSysMetadataModified>2016-08-26T17:15:07.506+00:00</dateSysMetadataModified>
<originMemberNode>urn:node:ARCTIC</originMemberNode>
<authoritativeMemberNode>urn:node:ARCTIC</authoritativeMemberNode>
<fileName>20090413_200904130059.noaa-18.4km_vis_ch1.jpeg</fileName>
</d1_v2.0:systemMetadata>
</pre></p>
<p>we would expect that anyone in the <code>CN=arctic-data-admins,DC=dataone,DC=org</code> group would have <code>read/write/changePermission</code> permissions. Updates to objects with access control like this by members of the group other than <code>CN=Bryce Mecum A27576,O=Google,C=US,DC=cilogon,DC=org</code> fail.</p>
<p>To get around this issue, I'm processing all 502K+ objects in the arcticdata.io Metacat to include:</p>
<pre>
<allow>
<subject>CN=arctic-data-admins,DC=dataone,DC=org</subject>
<permission>read</permission>
<permission>write</permission>
<permission>changePermission</permission>
</allow>
</pre>
<p>So, this isn't super critical, but it affects all Metacat systems, including the CNs.</p>