Maria asked me to update Charles Staver’s ORCID iD in the submission template and on CGSpace, as his name was lower case before, and now he has corrected it
Maria asked me to update Charles Staver’s ORCID iD in the submission template and on CGSpace, as his name was lower case before, and now he has corrected it
<li>Maria asked me to update Charles Staver’s ORCID iD in the submission template and on CGSpace, as his name was lower case before, and now he has corrected it
<ul>
<li>I updated the fifty-eight existing items on CGSpace</li>
</ul>
</li>
<li>Looking into the items Udana had asked about last week that were missing Altmetric donuts:
<li><ahref="https://hdl.handle.net/10568/103225">The first</a> is still missing its DOI, so I added it and <ahref="https://twitter.com/mralanorth/status/1245632619661766657">tweeted its handle</a> (after a few hours there was a donut with score 222)</li>
<li><ahref="https://hdl.handle.net/10568/106899">The second item</a> now has a donut with score 2 since I <ahref="https://twitter.com/mralanorth/status/1243158045540134913">tweeted its handle</a> last week</li>
<li><ahref="https://hdl.handle.net/10568/107258">The third item</a> now has a donut with score 1 since I <ahref="https://twitter.com/mralanorth/status/1243158786392625153">tweeted it</a> last week</li>
</ul>
</li>
<li>On the same note, the <ahref="https://hdl.handle.net/10568/106573">one item</a> Abenet pointed out last week now has a donut with score of 104 after I <ahref="https://twitter.com/mralanorth/status/1243163710241345536">tweeted it</a> last week</li>
<li>Altmetric responded about <ahref="https://hdl.handle.net/10568/101286">one item</a> that had no donut since at least 2019-12 and said they fixed some problems with their bot’s user agent
<ul>
<li>I decided to <ahref="https://twitter.com/mralanorth/status/1245703049445851140">tweet the item</a>, as I can’t remember if I ever did it before</li>
<li>Update PostgreSQL JDBC driver to version 42.2.12</li>
</ul>
<h2id="2020-04-07">2020-04-07</h2>
<ul>
<li>Yesterday Atmire sent me their <ahref="https://github.com/ilri/DSpace/pull/445">pull request for DSpace 6 modules</a></li>
<li>Peter pointed out that some items have his ORCID identifier (<code>cg.creator.id</code>) twice
<ul>
<li>I think this is because my early <code>add-orcid-identifiers.py</code> script was adding identifiers to existing records without properly checking if there was already one present (at first it only checked if there was one with the exact <code>place</code> value)</li>
<li>As a test I dropped all his ORCID identifiers and added them back with the <code>add-orcid-identifiers.py</code> script:</li>
</ul>
</li>
</ul>
<pre><code>$ psql -h localhost -U postgres dspace -c "DELETE FROM metadatavalue WHERE resource_type_id=2 AND metadata_field_id=240 AND text_value LIKE '%Ballantyne%';"
<li>I used this CSV with the script (all records with his name have the name standardized like this):</li>
</ul>
<pre><code>dc.contributor.author,cg.creator.id
"Ballantyne, Peter G.","Peter G. Ballantyne: 0000-0001-9346-2893"
</code></pre><ul>
<li>Then I tried another way, to identify all duplicate ORCID identifiers for a given resource ID and group them so I can see if count is greater than 1:</li>
</ul>
<pre><code>dspace=# \COPY (SELECT DISTINCT(resource_id, text_value) as distinct_orcid, COUNT(*) FROM metadatavalue WHERE resource_type_id = 2 AND metadata_field_id = 240 GROUP BY distinct_orcid ORDER BY count DESC) TO /tmp/2020-04-07-duplicate-orcids.csv WITH CSV HEADER;
COPY 15209
</code></pre><ul>
<li>Of those, about nine authors had duplicate ORCID identifiers over about thirty records, so I created a CSV with all their name variations and ORCID identifiers:</li>
</ul>
<pre><code>dc.contributor.author,cg.creator.id
"Ballantyne, Peter G.","Peter G. Ballantyne: 0000-0001-9346-2893"
<li>Then I deleted <em>all</em> their existing ORCID identifier records:</li>
</ul>
<pre><code>dspace=# DELETE FROM metadatavalue WHERE resource_type_id=2 AND metadata_field_id=240 AND text_value SIMILAR TO '%(0000-0001-6543-0798|0000-0001-9346-2893|0000-0002-6950-4018|0000-0002-7583-3811|0000-0002-8044-583X|0000-0002-8599-7895|0000-0003-0934-1218|0000-0003-2765-7101)%';
DELETE 994
</code></pre><ul>
<li>And then I added them again using the <code>add-orcid-identifiers</code> records:</li>
<li>I started testing the <ahref="https://github.com/ilri/DSpace/pull/445">pull request</a> sent by Atmire yesterday
<ul>
<li>I notice that we now need <code>yarn</code> to build, and I need to bump the Node.js <code>engine</code> version in our Mirage 2 theme in order to get it to build on Node.js 10.x</li>
<li>Font Awesome icons for GitHub etc weren’t loading, and after a bit of troubleshooting I replaced version 4.5.0 with 5.13.0 and to my surprise they now include Mendeley and ORCID so we can get rid of the Academicons dependency</li>
</ul>
</li>
</ul>
<h2id="2020-04-12">2020-04-12</h2>
<ul>
<li>Testing the Atmire DSpace 6.3 code with a clean CGSpace DSpace 5.8 database snapshot
<ul>
<li>One Flyway migration failed so I had to manually remove it (and of course create the pgcrypto extension):</li>
</ul>
</li>
</ul>
<pre><code>dspace63=# DELETE FROM schema_version WHERE version IN ('5.8.2015.12.03.3');
dspace63=# CREATE EXTENSION pgcrypto;
</code></pre><ul>
<li>Then DSpace 6.3 started up OK and I was able to see some statistics in the Content and Usage Analysis (CUA) module, but not on community, collection, or item pages
<ul>
<li>I also noticed at least one of these errors in the DSpace log:</li>
<li>Run system updates on DSpace Test (linode26) and reboot it</li>
<li>More work on the DSpace 6.3 stuff, improving the GDPR consent logic to use <ahref="https://github.com/chiiya/haven">haven</a> instead of cookieconsent
<ul>
<li>It works better by injecting the Google Analytics script after the user clicks agree, and it also has a preferences section that gets automatically injected on the privacy page!</li>
<li>I realized that <code>solr-upgrade-statistics-6x</code> only processes 100,000 records by default so I think we actually need to finish running it for all legacy Solr records before asking Atmire why CUA statlets and detailed statistics aren’t working</li>
<li>For now I am just doing 250,000 records at a time on my local environment:</li>
<li>Despite running the migration for all of my local 1.5 million Solr records, I still see a few hundred thousand like <code>-1</code> and <code>0-unmigrated</code>
<ul>
<li>I will purge them all and try to import only a subset…</li>
<li>After importing again I see there are indeed tens of thousands of these documents with IDs “-1” and “0”</li>
<li>They are all <code>type: 5</code>, which is “SITE” according to <code>Constants.java</code>:</li>
</ul>
</li>
</ul>
<pre><code>/** DSpace site type */
public static final int SITE = 5;
</code></pre><ul>
<li>Even after deleting those documents and re-running <code>solr-upgrade-statistics-6x</code> I still get the UUID errors when using CUA and the statlets</li>
<li>I have sent some feedback and questions to Atmire (including about the  issue with glypicons in the header trail)</li>
<li>In other news, my local Artifactory container stopped working for some reason so I re-created it and it seems some things have changed upstream (port 8082 for web UI?):</li>
<li>A few days ago Peter asked me to update an author’s name on CGSpace and in the controlled vocabularies:</li>
</ul>
<pre><code>dspace=# UPDATE metadatavalue SET text_value='Knight-Jones, Theodore J.D.' WHERE resource_type_id=2 AND metadata_field_id=3 AND text_value='Knight-Jones, T.J.D.';
</code></pre><ul>
<li>I updated his existing records on CGSpace, changed the controlled lists, added his ORCID identifier to the controlled list, and tagged his thirty-nine items with the ORCID iD</li>
<li>The new DSpace 6 stuff that Atmire sent modifies the Mirage 2’s <code>pom.xml</code> to copy the each theme’s resulting <code>node_modules</code> to each theme after building and installing with <code>ant update</code> because they moved some packages from bower to npm and now reference them in <code>page-structure.xsl</code>
<ul>
<li>This is a good idea, because bower is no longer supported, and npm has gotten a lot better, but it causes an extra 200,000 files to get copied!</li>
<li>Most scripts are concatenated into <code>theme.js</code> during build, so we don’t need the <code>node_modules</code> after that, but there are three scripts in <code>page-structure.xsl</code> that are not included there</li>
<li>The scripts are a very old version of modernizr which is not even available on npm, html5shiv, and respond.js</li>
<li>For modernizr I can simply download a static copy and put it in <code>0_CGIAR/scripts</code> and concatenate it into <code>theme.js</code></li>
<li>For the others, I can revert to using them from bower’s <code>vendor</code> directory, which is installed by the parent XMLUI Mirage 2 theme</li>
<li>During this process I also realized that <code>mvn clean</code> doesn’t actually clean everything, and <code>dspace/modules/xmlui-mirage2/target</code> is remaining from previous builds and contains a bunch of shit from previous builds (including all the themes which I was trying to build without!)
<ul>
<li>This must be a DSpace bug, but I should theoretically check on vanilla DSpace and then file a bug…</li>
<li>Atmire responded to some of the issues I raised earlier this week about the DSpace 6 pull request
<ul>
<li>They said they don’t think the glyphicon encoding issue is due to their changes, but I built a new clean version of the vanilla <code>6_x-dev</code> branch from before their pull request and it <em>does not</em> have the encoding issue in the Mirage 2 header trails</li>
<li>Also, they said we need to use something called <code>AtomicStatisticsUpdateCLI</code> to do the Solr legacy integer ID to UUID conversion so I asked for more information about that workflow</li>
