/
2026-08-10 eUsage subgroup

2026-08-10 eUsage subgroup

Calendar file:

You can request a calendar invitation from @Stefan Dombek by e-mail

Zoom link: https://openlibraryfoundation.zoom.us/j/87822401037?pwd=aajKWPM0kaAGlXG6nq0OZg03plmPjt.1

Time: 10 a.m. ET

Recording of the meeting: https://recordings.openlibraryfoundation.org/folio

Item

Notes

Item

Notes

New members?

Introduce yourself!

Please add “eUsage” to “Focus of Work” in the table ERM SIG (ERM SIG Home - Members).

WOLFcon 2026

Short session: “eUsage: From feedback to features”

https://site.pheedloop.com/event/wolfcon2026/sessions/SESXRUYJIJRR8AL2K

Critical Service Patch (CSP): Registry_URL

Currently, issues may arise when harvesting reports using version 5.1. The FOLIO releases Sunflower and Trillium are affected. The reason is that, starting with version 5.1, the Counter standard includes a registry URL. This URL differs in version 5.1 of the standard from that in version 5.1.1. Technically, such versioning represents revisions without major changes. Counter assumed that changing the URL would have no impact. Unfortunately, the clients (e.g., eUsage) check this URL. Therefore, if a provider is still using version 5.1 instead of 5.1.1, the report is rejected. We have been in contact with Mr. Oberknapp. Counter intends to allow both versions of the URL (old and new) in version 5.1.2. However, the release date for 5.1.2 is not expected until early next year. The dev team Leipzig has agreed to preempt the release of the 5.1.2 standard and allow both variants effective immediately. We would deliver this via a Critical Service Patch (CSP). Otherwise, eUsage would no longer be able to harvest certain reports from specific providers.

Critical Service Patch (CSP): HTTP redirects

Harvesting COUNTER 5.1 reports from providers that respond with an HTTP redirect fails in version 5.1.1. JSTOR is a confirmed case: the harvester requests the SUSHI report path /reports/tr (no trailing slash), JSTOR responds with 301 to /reports/tr/ (trailing slash, with the full query string preserved), and the harvester does not follow the redirect.

Counter exceptions from the endpoint with HTTP status code 200 that, according to the standard, require a different HTTP status code.

  • Up to and including Counter 5.0, we processed such combinations in eUsage. Starting with Counter 5.1, this is no longer the case.

  • See: https://cop5.countermetrics.org/en/5.1.1/appendices/d-handling-errors-and-exceptions.html

  • Example:

    • 1. You receive the Counter Exception from the endpoint {"Code":1000,"Message":"Service Not Available","Data":""}

    • 2. HTTP status code 200 instead of 503

    • 3. eUsage flags the report as an error, but the report information displays the following:

      com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "Code" (class org.openapitools.counter51.model.TR), not marked as ignorable (2 known properties: "Report_Header", "Report_Items"]) at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 13] (through reference chain: org.openapitools.counter51.model.TR["Code"])

    • Result: Should be possible again with Umbrellaleaf

Remove harvester function for COUNTER 4

So far, only service types have been added to eUsage; none have been removed. For this reason, a fallback solution and a migration process must be integrated into eUsage for existing UDP records in case a service type is deleted.

https://folio-org.atlassian.net/browse/UIEUS-529

Settings: Combine the “Start Harvester” and “Periodic harvesting” settings into a single section in the Settings app

  • https://folio-org.atlassian.net/browse/UXPROD-5957

  • We need to consult with the UI designer at FOLIO. We may need to adjust the form's display so that it remains visible at all times. The checkbox selection will then be the deciding factor.

  • Note: The option to start the harvester for all providers should be available later in the provider list, but with permission.

Validation of identifiers in Counter Reports

There is currently a discussion about whether to allow identifiers that may be incorrect, but to flag them. At the moment, reports are rejected due to invalid validation. This is an issue that keeps coming up. On the one hand, we need valid identifiers because the data is reused (e.g., eUsage reports). On the other hand, we can’t simply reject reports just because the identifier is incorrect. Providers will never be able to get this 100% right.

See: https://github.com/Project-Counter/cop5/blob/planned/api-specification/COUNTER_API.json (starting at line 16465)

Discussion:

  • We need to determine how eUsage Reports should import data from eUsage. Charlotte will be invited to the next meeting.

  • One idea might be to mark the IDs in such a way that it's clear they aren't valid according to the standard counter.

  • Another idea: eUsage Reports could use the data and try to use it by normalizing it.

Feel free to add points to the list