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>
