Catalog Entries shows flat line in OMP 3.2.0-3

After upgrading OMP from 3.2.1-1 to 3.2.0-3, the graph “Statistics->Monographs->Catalog Entries” shows a flat line from date of conversion.
Can you please tell me how to fix this?
If I am correct, a query on metrics is done to 1048585.
However, this value is no longer recorded since the transition from 3.2.1-1 to 3.2.0-3.

For statistics in OMP 3.2.0-3 it seems that ASSOC_TYPE_SUBMISSION is converted in ASSOC_TYPE_PUBLICATION. However this new ASSOC_TYPE is never registered in the metrics table and also the old one is not. So the statistics keep on showing a flat line. Can anyone help to solve this problem?

Hi @ugp2,

Can you confirm that this is the change you’re referring to?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

No, it is not the frontend but the backend statistics chart.
image

And it is only the ‘Catalog Entries’, ‘Files’ chart is ok (we had a freeze from 5-10 of January)
image

Regards,
Pia

Hi @ugp2

The upgrade was from 3.1.2 (not 3.2.1) and you are using 3.2.0-3, right?

Hmmm… When you look in the monograph details list below the graph, what do you see, do you see any abstract views/numbers?

And yes, the abstract views should be stored with assoc_type = 1048585 in the DB table metrics. Do you see any of those there since the upgrade?

Could you please also check if there is a new log entry (in the current log file in the folder usageStats/usageEventLogs/ in your files folder) when you go to a monograph page?

For statistics in OMP 3.2.0-3 it seems that ASSOC_TYPE_SUBMISSION is converted in ASSOC_TYPE_PUBLICATION.

This should not be the case. Where do you see it?

In the meantime I will try to install that version and see…

Best,
Bozana

Hi @ugp2

I managed to install that version 3.2.0 and I can see that the monograph abstract views are logged but when the log file is processed they are not stored in the DB table. I’ll take a look and try to fix that…
Then you will need to reprocess the log files again…
And to be sure: you could check if your log files, probably in the folder usageStats/archive/ in your files folder have those abstract entries (…/catalog/book/submissionID).

Best,
Bozana

Hi bozana,

You are right, the upgrade was from 3.1.2-1 to 3.2.0-3.

In the monograph details list below the graph, all Abstract Views are 0
image

There are no ‘assoc_type = 1.48585’ in the metrics table since the upgrade.

When I visit the monograph page there is a new log entry.

The conversion is in the controlled_vocabs table (3.2.0_versioning.xml lines 214-226 )

Regards,
Pia

Hi bozana,

The entries are changed in this version (OMP 3.2.0-3). Before the upgrade the logfile contains numbers as an submissionID, like …/book/55. After the upgrade the submissionID consists of characters, like …/book/HG
Is that where it goes wrong?

Regards,
Pia

Hi @ugp2

Yes, I’ve just realized it now – the log entries are not correct because of a bug :frowning: This line of code: omp/UsageEventPlugin.inc.php at stable-3_2_0 · pkp/omp · GitHub should be:
$submission = $templateMgr->getTemplateVars('publishedSubmission');
Unfortunately, the log files cannot be repaired and that numbers will be missing :frowning:

Note: The bug is also in 3.2.1 release :frowning:

I will post the fix and let you know again…

Best,
Bozana

Hi @ugp2

Here is the GitHub Issue, and the patches: usage event: the book abstract pages are not logged correctly · Issue #6776 · pkp/pkp-lib · GitHub

Best,
Bozana

Hi bozana,

Thank you for fixing this.
You mentioned: ‘Unfortunately, the log files cannot be repaired and that numbers will be missing :frowning:’ Is there no 1:1 relationship between submission and publishedSubmission? In that case I can change the entries and replace the characters for the number it should be.
When there is indeed a 1:1 relationship, where can I find it?

Regards,
Pia

Hi @ugp2

This change from submission to publishedSubmission in the code has nothing to do with the entries in the log files and database – that is just the variable name. Because of that bug the URLs in the log files were wrong and could not be processed/the statistics calculated. Now we do not know what book exactly the user visited, so we cannot repair the wrong URLs in the log files.
(I will discuss with other developers if they see a possibility to guess the right book URL in a case when the next logged URL is a file download, or if this would introduce even more confusion/inaccuracy… and will let you know…)

But, you should definitely apply that fix, so that the URLs in the log files are correct again.

Best,
Bozana

Hi bozana,

Ok, that’s clear. The fix is already applied and it worked well.

Thanks again,
ugp2