cgspace-notes/content/posts/2021-01.md

---
title: "January, 2021"
date: 2021-01-03T10:13:54+02:00
author: "Alan Orth"
categories: ["Notes"]
---

## 2021-01-03

- Peter notified me that some filters on AReS were broken again
  - It's the same issue with the field names getting `.keyword` appended to the end that I already [filed an issue on OpenRXV about last month](https://github.com/ilri/OpenRXV/issues/66)
  - I fixed the broken filters (careful to not edit any others, lest they break too!)
- Fix an issue with start page number for the DSpace REST API and statistics API in OpenRXV
  - The start page had been "1" in the UI, but in the backend they were doing some gymnastics to adjust to the zero-based offset/limit/page of the DSpace REST API and the statistics API
  - I adjusted it to default to 0 and added a note to the admin screen
  - I realized that this issue was actually causing the first page of 100 statistics to be missing...
  - For example, [this item](https://cgspace.cgiar.org/handle/10568/66839) has 51 views on CGSpace, but 0 on AReS

<!--more-->

- Start a re-index on AReS
  - First delete the old Elasticsearch temp index:

```console
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
# start indexing in AReS
```

- Then, the next morning when it's done, check the results of the harvesting, backup the current `openrxv-items` index, and clone the `openrxv-items-temp` index to `openrxv-items`:

```console
$ curl -s 'http://localhost:9200/openrxv-items-temp/_count?q=*&pretty'
{
  "count" : 100278,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}
$ curl -X PUT "localhost:9200/openrxv-items/_settings" -H 'Content-Type: application/json' -d'{"settings": {"index.blocks.write": true}}'
$ curl -s -X POST http://localhost:9200/openrxv-items/_clone/openrxv-items-2021-01-04
$ curl -XDELETE 'http://localhost:9200/openrxv-items'
$ curl -X PUT "localhost:9200/openrxv-items-temp/_settings" -H 'Content-Type: application/json' -d'{"settings": {"index.blocks.write": true}}'
$ curl -s -X POST http://localhost:9200/openrxv-items-temp/_clone/openrxv-items
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
$ curl -XDELETE 'http://localhost:9200/openrxv-items-2021-01-04'
```

## 2021-01-04

- There is one item that appears twice in AReS: [10568/66839](https://cgspace.cgiar.org/handle/10568/66839)
  - If I use the Handle filter I see it twice... whereas other items don't appear twice
  - I filed a bug on OpenRXV: https://github.com/ilri/OpenRXV/issues/67
- Help Peter troubleshoot an issue with Altmetric badges on AReS
  - He generated a report of our repository from Altmetric and noticed that many were missing scores despite having scores on CGSpace item pages
  - AReS harvest Altmetric scores using the Handle prefix (10568) in batch, while CGSpace uses the DOI if it is found, and falls back to using the Handle
  - I think it's due to the fact that some items were never tweeted, so Altmetric never made the link between the DOI and the Handle
  - I did some tweets of five items and within an hour or so the DOI API link registers the associated Handle, and within an hour or so the Handle API link is live with the same score

## 2021-01-05

- A user sent me [feedback about the dspace-statistics-api](https://github.com/ilri/dspace-statistics-api/issues/12)
  - He noticed that the indexer fails if there are unmigrated legacy records in Solr
  - I added a UUID filter to the queries in the indexer
- I generated a CSV of titles and Handles for 2019 and 2020 items for Peter to Tweet
  - We need to make sure that Altmetric has linked them all with their DOIs
  - I wrote a quick and dirty script called [doi-to-handle.py](https://gist.github.com/alanorth/281b7624301049e8fa91742b9b8c51b9) to read the DOIs from a text file, query the database, and save the handles and titles to a CSV

```console
$ ./doi-to-handle.py -db dspace -u dspace -p 'fuuu' -i /tmp/dois.txt -o /tmp/out.csv
```

- Help Udana export IWMI records from AReS
  - He wanted me to give him CSV export permissions on CGSpace, but I told him that this requires super admin so I'm not comfortable with it
- Import one item to CGSpace for Peter

## 2021-01-07

- Import twenty CABI book chapters for Abenet
- Udana and some editors from IWMI are still having problems editing metadata during the workflow step
  - It is the same issue Peter reported last month, that values he edits are not saved when the item gets archived
  - I added myself the the edit and approval steps of [the collection](https://dspacetest.cgiar.org/handle/10568/81589) on DSpace Test and asked Udana to submit an item there for me to test
- Atmire got back to me about the duplicate data in Solr
  - They want to arrange a time for us to do the stats processing so they can monitor it
  - I proposed that I set everything up with a fresh Solr snapshot from CGSpace and then let them start the stats process

## 2021-01-10

- Dominique from IWMI asked about API access to the IWMI collections
  - A partner of theirs called AMCOW is interested in harvesting their publications
  - I told her that they can use the REST API or OAI to get them from the [IWMI Journal Articles collection](https://cgspace.cgiar.org/handle/10568/36185):
    - CGSpace REST API: https://cgspace.cgiar.org/rest/collections/c2618391-184e-4091-8a93-280fdf01238b/items
    - CGSpace OAI API: https://cgspace.cgiar.org/oai/request?verb=ListRecords&metadataPrefix=oai_dc&set=col_10568_36185
- Udana submitted an item to [the collection](https://dspacetest.cgiar.org/handle/10568/81589) on DSpace Test that I discussed last week
  - I was able to take the task, add a new AGROVOC subject, approve the task, and commit it to archive
  - The final item had my new AGROVOC subject, so I don't see the issue
  - Perhaps the issue only occurs when we replace an existing field? Or only on IWMI fields? I don't know...
  - Also there is this warning that occurs in the DSpace log during editing (and many other operations):

```console
2021-01-10 10:03:27,692 WARN  com.atmire.metadataquality.batchedit.BatchEditConsumer @ BatchEditConsumer should not have been given this kind of Subject in an event, skipping: org.dspace.event.Event(eventType=MODIFY, SubjectType=ITEM, SubjectID=1e8fb96c-b994-4fe2-8f0c-0a98ab138be0, ObjectType=(Unknown), ObjectID=null, TimeStamp=1610269383279, dispatcher=1544803905, detail=[null], transactionID="TX35636856957739531161091194485578658698")
```

- I filed [a bug on Atmire's issue tracker](https://tracker.atmire.com/tickets-cgiar-ilri/view-ticket?id=907)
- Peter asked me to move the CGIAR Gender Platform community to the top level of CGSpace, but I get an error when I use the community-filiator command:

```console
$ dspace community-filiator --remove --parent=10568/66598 --child=10568/106605
Loading @mire database changes for module MQM
Changes have been processed
Exception: null
java.lang.UnsupportedOperationException
        at java.util.AbstractList.remove(AbstractList.java:161)
        at java.util.AbstractList$Itr.remove(AbstractList.java:374)
        at java.util.AbstractCollection.remove(AbstractCollection.java:293)
        at org.dspace.administer.CommunityFiliator.defiliate(CommunityFiliator.java:264)
        at org.dspace.administer.CommunityFiliator.main(CommunityFiliator.java:164)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
        at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
```

- There is apparently [a bug](https://jira.lyrasis.org/browse/DS-3914) in DSpace 6.x that makes community-filiator not work
  - There is [a patch](https://github.com/DSpace/DSpace/pull/2178) for the as-of-yet unreleased DSpace 6.4 so I will try that
  - I tested the patch on DSpace Test and it worked, so I will do the same on CGSpace tomorrow
- Udana had asked about exporting IWMI's community on CGSpace, but we don't want to give him super admin permissions to do that
  - I suggested that he use AReS, but there are some fields missing because we don't harvest them all
  - I added a few more fields to the configuration and will start a fresh harvest.
- Start a re-index on AReS
  - First delete the old Elasticsearch temp index:

```console
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
# start indexing in AReS
... after ten hours
$ curl -s 'http://localhost:9200/openrxv-items-temp/_count?q=*&pretty'
{
  "count" : 100411,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}
$ curl -X PUT "localhost:9200/openrxv-items-temp/_settings?pretty" -H 'Content-Type: application/json' -d'{"settings": {"index.blocks.write": true}}'
$ curl -XDELETE 'http://localhost:9200/openrxv-items'
$ curl -s -X POST http://localhost:9200/openrxv-items-temp/_clone/openrxv-items
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
```

- Looking over the last month of Solr stats I see a familiar bot that *should* have been marked as a bot months ago:

> Mozilla/5.0 (compatible; +centuryb.o.t9[at]gmail.com)

- There are 51,961 hits from this bot on 64.62.202.71 and 64.62.202.73
  - Ah! Actually I added the bot pattern to the Tomcat Crawler Session Manager Valve, which mitigated the abuse of Tomcat sessions:

```console
$ cat log/dspace.log.2020-12-2* | grep -E 'session_id=[A-Z0-9]{32}:ip_addr=64.62.202.71' | sort | uniq | wc -l
0
```

- So now I should really add it to the DSpace spider agent list so it doesn't create Solr hits
  - I added it to the "ilri" lists of spider agent patterns 
- I purged the existing hits using my `check-spider-ip-hits.sh` script:

```console
$ ./check-spider-ip-hits.sh -d -f /tmp/ips -s http://localhost:8081/solr -s statistics -p
```

## 2021-01-11

- The AReS indexing finished this morning and I moved the `openrxv-items-temp` core to `openrxv-items` (see above)
  - I sorted the explorer results by Altmetric attention score and I see a few new ones on the top so I think the recent tweeting of Handles by Peter and myself worked
- I deployed the community-filiator fix on CGSpace and moved the Gender Platform community to the top level of CGSpace:

```console
$ dspace community-filiator --remove --parent=10568/66598 --child=10568/106605
```

## 2021-01-12

- IWMI is really pressuring us to have a periodic CSV export of their community
  - I decided to write a systemd timer to use `dspace metadata-export` every week, and made an nginx alias to make it available [publicly](https://cgspace.cgiar.org/iwmi.csv)
  - It is part of the [Ansible infrastructure scripts](https://github.com/ilri/rmg-ansible-public) that I use to provision the servers
- I wrote to Atmire to tell them to try their CUA duplicates processor on DSpace Test whenever they get a chance this week
  - I verified that there were indeed duplicate metadata values in the `userAgent_ngram` and `userAgent_search` fields, even in the first few results I saw in Solr
  - For reference, the UID of the record I saw with duplicate metadata was: 50e52a06-ffb7-4597-8d92-1c608cc71c98

## 2021-01-13

- I filed [an issue on cg-core](https://github.com/AgriculturalSemantics/cg-core/issues/30) asking about how to handle series name / number
  - Currently the values are in format "series name; series number" in the `dc.relation.ispartofseries` field, but Peter wants to be able to separate them
- Start working on CG Core v2 migration for DSpace 6, using [my work](https://alanorth.github.io/cgspace-notes/cgspace-cgcorev2-migration/) from last year on DSpace 5

## 2021-01-14

- More work on the CG Core v2 migration for DSpace 6
- Publish [v1.4.1 of the DSpace Statistics API](https://github.com/ilri/dspace-statistics-api/releases/tag/v1.4.1) based on feedback from the community
  - This includes the fix for limiting the Solr query to UUIDs

## 2021-01-17

- Start a re-index on AReS
  - First delete the old Elasticsearch temp index:

```console
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
# start indexing in AReS
```

- Then, the next morning when it's done, check the results of the harvesting, backup the current `openrxv-items` index, and clone the `openrxv-items-temp` index to `openrxv-items`:

```console
$ curl -s 'http://localhost:9200/openrxv-items-temp/_count?q=*&pretty'
{
  "count" : 100540,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}
$ curl -X PUT "localhost:9200/openrxv-items/_settings" -H 'Content-Type: application/json' -d'{"settings": {"index.blocks.write": true}}'
$ curl -s -X POST http://localhost:9200/openrxv-items/_clone/openrxv-items-2021-01-18
$ curl -XDELETE 'http://localhost:9200/openrxv-items'
$ curl -X PUT "localhost:9200/openrxv-items-temp/_settings" -H 'Content-Type: application/json' -d'{"settings": {"index.blocks.write": true}}'
$ curl -s -X POST http://localhost:9200/openrxv-items-temp/_clone/openrxv-items
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
$ curl -XDELETE 'http://localhost:9200/openrxv-items-2021-01-18'
```

## 2021-01-18

- Finish the indexing on AReS that I started yesterday
- Udana from IWMI emailed me to ask why the iwmi.csv doesn't include items he approved to CGSpace this morning
  - I told him it is generated every Sunday night
  - I regenerated the file manually for him
  - I adjusted the script to run on Monday and Friday
- Meeting with Peter and Abenet about CG Core v2
  - We also need to remove CTA and CPWF subjects from the input form since they are both closed now and no longer submitting items
  - Peter also wants to create new fields on CGSpace for the SDGs and CGIAR Impact Areas
    - I suggested `cg.subject.sdg` and `cg.subject.impactArea`
  - We also agreed to remove the following fields:
    - cg.livestock.agegroup
    - cg.livestock.function
    - cg.message.sms
    - cg.message.voice
  - I removed them from the input form, metadata registry, and deleted all the values in the database:

```
localhost/dspace63= > BEGIN;
localhost/dspace63= > DELETE FROM metadatavalue WHERE metadata_field_id IN (115, 116, 117, 118);
DELETE 27
localhost/dspace63= > COMMIT;
```

- I submitted [an issue](https://github.com/AgriculturalSemantics/cg-core/issues/31) to CG Core v2 to propose standardizing the camel case convention for a few more fields of ours
- I submitted [an issue](https://github.com/AgriculturalSemantics/cg-core/issues/32) to CG Core v2 to propose removing `cg.series` and `cg.pages` in favor of `dcterms.isPartOf` and `dcterms.extent`, respectively
- It looks like we will roll all these changes into a CG Core v2.1 release

## 2021-01-19

- Abenet said that the PDF reports on AReS aren't working
  - I had to install `unoconv` in the backend api container again

```console
$ docker exec -it api /bin/bash
# apt update && apt install unoconv
```

- Help Peter get a list of titles and DOIs for CGSpace items that Altmetric does not have an attention score for
  - He generated a list from their dashboard and I extracted the DOIs in OpenRefine (because it was WINDOWS-1252 and csvcut couldn't do it)
  - Then I looked up the titles and handles using the `doi-to-handle.py` script that I wrote last week
- I created [a pull request](https://github.com/AgriculturalSemantics/cg-core/pull/34) to convert several CG Core v2 fields to consistent "camel case"
  - Marie said we should create a new minor version of CG Core v2 for this so I tagged it with the ["CG Core v2.1" milestone](https://github.com/AgriculturalSemantics/cg-core/milestone/1)
- I created [a pull request](https://github.com/AgriculturalSemantics/cg-core/pull/35) to fix some links in cgcore.html

## 2021-01-21

- File [an issue](https://github.com/ilri/OpenRXV/issues/68) for the OpenRXV backend API container's missing `unoconv`
  - This causes PDF reports to not work, and I always have to go manually re-install it after rebooting the server
- A little bit more work on the CG Core v2 migration in CGSpace
  - I updated the `migrate-fields.sh` script for DSpace 6 and created all the new fields in my test instance

## 2021-01-24

- Abenet mentioned that Alan Duncan could not find one of his items on AReS, but it is on CGSpace
  - The item is: https://hdl.handle.net/10568/110133
  - The handle does not appear on AReS when I try to filter by Handle
  - I suspect it is related to the issue of the missing Livestock CRP community and I added a comment on [the GitHub issue](https://github.com/ilri/OpenRXV/issues/62)
- Import fifteen items to CGSpace for Peter after doing a brief check in OpenRefine and csv-metadata-quality
- Ben Hack asked me why I'm still using the default favicon on CGSpace
  - I used an [SVG version of the CGIAR logo](https://commons.wikimedia.org/wiki/File:CGIAR-logo.svg) with https://realfavicongenerator.net to to make a better favicon setup and it is currently running on DSpace Test
- Start a re-index on AReS
  - First delete the old Elasticsearch temp index:

```console
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
# start indexing in AReS
```

- Then, the next morning when it's done, check the results of the harvesting, backup the current `openrxv-items` index, and clone the `openrxv-items-temp` index to `openrxv-items`:

```console
$ curl -s 'http://localhost:9200/openrxv-items-temp/_count?q=*&pretty'
{
  "count" : 100699,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  }
}
$ curl -X PUT "localhost:9200/openrxv-items/_settings" -H 'Content-Type: application/json' -d'{"settings": {"index.b
locks.write":true}}'
$ curl -s -X POST http://localhost:9200/openrxv-items/_clone/openrxv-items-2021-01-25
$ curl -XDELETE 'http://localhost:9200/openrxv-items'
$ curl -X PUT "localhost:9200/openrxv-items-temp/_settings" -H 'Content-Type: application/json' -d'{"settings": {"index.blocks.write": true}}'
$ curl -s -X POST http://localhost:9200/openrxv-items-temp/_clone/openrxv-items
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
$ curl -XDELETE 'http://localhost:9200/openrxv-items-2021-01-25'
```

- Resume working on CG Core v2, I realized a few things:
  - We are trying to move from `dc.identifier.issn` (and ISBN) to `cg.issn`, but this is currently implemented as a "qualdrop" input in DSpace's submission form, which only works to fill in the qualifier (ie `dc.identier.xxxx`)
    - If we really want to use `cg.issn` and `cg.isbn` we would need to add a new input field for each separately
  - We are trying to move series name/number fro m`dc.relation.ispartofseries` to `dcterms.isPartOf`, but this uses a special "series" input type in DSpace's submission form that joins series name and number with a colon (;)
    - If we really want to do that we need to add two separate input fields for each

## 2021-01-25

- Finish indexing AReS and adjusting the indexes (see above)
- Merged the changes for the favicon in to the `6_x-prod` branch
- Meeting with Peter and Abenet about CG Core v2
  - We agreed to go ahead with it ASAP and share a list of the changes with Macaroni, Fabio, and others and give them a firm timeline
  - We also discussed the CSV export option on DSpace 6 and were surprised to see that it kinda works
  - If you do a free-text search it works properly, but if you try to use the metadata filters it doesn't
  - I changed the default setting to make it available to any logged in user and will deploy it on CGSpace this week

## 2021-01-26

- Email some CIAT users who submitted items with upper case AGROVOC terms
  - I will do another global replace soon after they reply
- Add CGIAR Impact Areas and UN Sustainable Development Goals (SDGs) to the `6x_prod` branch
- Looking into the issue with exporting search results in XMLUI again
  - I notice that there is an HTTP 400 when you try to export search results containing a filter
  - The Tomcat logs show:

```
Jan 26, 2021 10:47:23 AM org.apache.coyote.http11.AbstractHttp11Processor process
INFO: Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target [/discover/search/csv?query=*&scope=~&filters=author:(Alan\%20Orth)]. The valid characters are defined in RFC 7230 and RFC 3986
        at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:213)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1108)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:654)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:317)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:748)
```

- This actually seems to be a simple issue, as I notice DSpace is escaping the space for some reason:
  - The URL that fails is: https://dspacetest.cgiar.org/discover/search/csv?query=*&scope=~&filters=author:(Alan\%20Orth)
  - The URL that works is: https://dspacetest.cgiar.org/discover/search/csv?query=*&scope=~&filters=author:(Alan%20Orth)
- I [filed a bug](https://jira.lyrasis.org/browse/DS-4566) on DSpace's issue tracker (though I accidentally hit Enter and submitted it before I finished, and there is no edit function)
- Looking into Linode report that the load outbound traffic rate was high this morning:

```console
# grep -E '26/Jan/2021:(08|09|10|11|12)' /var/log/nginx/rest.log | goaccess --log-format=COMBINED -
```

- The culprit seems to be the ILRI publications importer, so that's OK
- But I also see an IP in Jordan hitting the REST API 1,100 times today:

```
80.10.12.54 - - [26/Jan/2021:09:43:42 +0100] "GET /rest/rest/bitstreams/98309f17-a831-48ed-8f0a-2d3244cc5a1c/retrieve HTTP/2.0" 302 138 "http://wp.local/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36"
```

- Seems to be someone from CodeObia working on WordPress
  - I told them to please use a bot user agent so it doesn't affect our stats, and to use DSpace Test if possible
- I purged all ~3,000 statistics hits that have the "http://wp.local/" referrer:

```console
$ curl -s "http://localhost:8081/solr/statistics/update?softCommit=true" -H "Content-Type: text/xml" --data-binary "<delete><query>referrer:http\:\/\/wp\.local\/</query></delete>"
```

- Tag version 0.4.3 of the csv-metadata-quality tool on GitHub: https://github.com/ilri/csv-metadata-quality/releases/tag/v0.4.3
  - I just realized that I never submitted this to CGSpace as a Big Data Platform output
  - I used my previous [DSpace Statistics API submission](https://hdl.handle.net/10568/99143) as a reference and submitted it to CGSpace

## 2021-01-27

- Abenet approved my submission to CGSpace for the CSV metadata quality checker: https://hdl.handle.net/10568/110997
- Add SDGs and Impact Areas to the XMLUI item display
- Last week Atmire got back to me about the duplicates in Solr
  - The deduplicator appears to be working, but you need to limit the number of records, for example `-r 100` so it doesn't crash due to memory
  - They pointed to a few records `solr_update_time_stamp:1605635765897` that have hundreds of duplicates which are now gone (still present if you look on the production server)
  - I need to try this again before doing it on CGSpace

## 2021-01-28

- I did some more work on CG Core v2
  - I tested using `cg.number` twice in the submission form: once for journal issue, and once for series number
  - DSpace gets confused and ends up storing the number twice, even if you only enter it in one of the fields
  - I suggested to Marie that we use `cg.issue` for journal issue, since we're already going to use `cg.volume`
  - That would free up `cg.number` for use by series number
- I deployed the SDGs, Impact Areas, and favicon changes to CGSpace and posted a note on Yammer for the editors
  - Also ran all system updates and rebooted the server (linode18)

## 2021-01-31

- AReS Explorer has been down since yesterday for some reason
  - First I ran all updates and rebooted the server (linode20)
  - Then start a re-index, first deleting the old Elasticsearch temp index:

```console
$ curl -XDELETE 'http://localhost:9200/openrxv-items-temp'
# start indexing in AReS
```

- Sent out emails about CG Core v2 to Macaroni Bros, Fabio, Hector at CCAFS, Dani and Tariku
- A bit more minor work on testing the series/report/journal changes for CG Core v2

<!-- vim: set sw=2 ts=2: -->