Is your feature request related to a problem? Please describe.
The Script UpdateCrisMetricsWithExternalSource is setting a metadata field on item level indicating the latest update of this item for a metrics service (for example cris.lastimport.scopus for scopus metrics). This metadata field is important to remember the last metrics import run and to avoid duplicate metrics import harvesting. But it has a pretty relevant downside: the last modified date for the item will be set and so other scripts will consider the item to be modified, although it was just a rather 'internal' modification. For instance, neither the OAI-PMH server should consider such items to be really modified, nor should the subscription script.
This behaviour is not really a bug, as it's been implemented intentionally, but this implementation has very strong side effects, which I consider to be a kind of a bug.
Describe the solution you'd like
The update-metrics script should not set the internal information with the timestamp of the last modification into a normal metadata field or the modification should not affect the last_modified timestamp of the item.
Describe alternatives or workarounds you've considered
First workaround for this problem is certainly not to use external metrics import. But the problem with that approach is, that you won't have external metrics in this case.
I was going to add a function not to set the last_modified date, when an internal metadata field like cris.lastimport.scopus has been changed. The problem with that is, that I was not able to find out, which metadata field was modified after all. So I was not able to implement something ion this direction.
Is your feature request related to a problem? Please describe. The Script
UpdateCrisMetricsWithExternalSourceis setting a metadata field on item level indicating the latest update of this item for a metrics service (for examplecris.lastimport.scopusfor scopus metrics). This metadata field is important to remember the last metrics import run and to avoid duplicate metrics import harvesting. But it has a pretty relevant downside: the last modified date for the item will be set and so other scripts will consider the item to be modified, although it was just a rather 'internal' modification. For instance, neither the OAI-PMH server should consider such items to be really modified, nor should the subscription script.This behaviour is not really a bug, as it's been implemented intentionally, but this implementation has very strong side effects, which I consider to be a kind of a bug.
Describe the solution you'd like The
update-metricsscript should not set the internal information with the timestamp of the last modification into a normal metadata field or the modification should not affect the last_modified timestamp of the item.Describe alternatives or workarounds you've considered First workaround for this problem is certainly not to use external metrics import. But the problem with that approach is, that you won't have external metrics in this case. I was going to add a function not to set the last_modified date, when an internal metadata field like
cris.lastimport.scopushas been changed. The problem with that is, that I was not able to find out, which metadata field was modified after all. So I was not able to implement something ion this direction.Additional context