Hi,
We recently updated our OJS from 3.2.1.1 to version 3.4.0.4.
Now editorial activity statistics look weird:
Regards,
Tarcisio Pereira
We may have just found some discrepencies in our data, too. Do some of your counter reports have no activity since 2024-01-01?
We’re using 3.4.0.5 and have noticed inconsistencies in the Editorial Activity stats, too. Note the stats in the Total column. We declined more submissions than we received and the declined and accepted totals don’t add up to the total submissions.
If there’s an explanation of the stats logic that I need to give my editors in order for them to use this feature, I’m happy to do so, but it’s not clear that the figures themselves are accurate, so it’s hard to explain. Any help would be very much appreciated!
Hi all,
I will try to help.
I found a bug in the number of Submissions In Progress, s. Wrong numbers for Submissions In Progress on the Editorial Activity page · Issue #9813 · pkp/pkp-lib · GitHub.
But this does not seem to be relevant for your questions.
@mreedks, Would it be possible for you to see how many submissions are in your DB table submissions? You could get the number by, for example, executing this SQL in your DB:
SELECT COUNT(*) FROM submissions;
Actually the Submissions Received Total (268) + Imported Submissions Total (255) should be the total number of your submissions (that you should get after executing that SQL) = 523. From that count, there are 274 declined submissions.
I do not quite understand how an imported submission can be declined… but… lets dig deeper 
Imported Submissions are those where the date_submitted is later than date_published. Do you know those cases, could it somehow be in your case?
@Tarcisio_Pereira, “Imported Submissions” are those where the date_submitted is later than date_published. Could this be for your submissions and how?
Thanks!
Bozana
Thank you, @bozana! We will ask our system administrator to take a look at the Submissions in the DB table.
Re: Declined Imported Submissions:
I am just hypothesizing, but I wonder if this use case would generate the declined imported submissions:
Suppose we added back issues (with older publication dates) to the journal, but some were accidentally added twice, for a variety of possible reasons. One submission is published, and the duplicate has to be deleted. Since there is no longer a way to delete directly from the All Active queue, those submissions that are going to be deleted have to have an editor assigned and be declined, then deleted from the Archived queue.
The editor confirms that the Editorial Activity used to be fairly accurate in 3.3.0.8, so it’s a change in the way that 3.4.0.5 handles these metrics from the way that 3.3.0.8 handled these metrics. (Though I’m not sure that the variety of metrics in the Editorial Activity menu was the same between the two versions.)
Hi @bozana
It appears that all submissions in the system are being counted as imported.
select s.date_submitted, p.date_published, * from submissions s
join publications p on (s.current_publication_id = p.publication_id)
where 1=1
and s.context_id = 94
and s.date_submitted >= ‘2024-01-01’
order by s.date_submitted asc;
Total 50 records in result set
In /stats/editorial/editorial:
Regards,
Tarcisio Pereira
Per our sysadmin who looked at the DB table, the count was 494 from the query.
In the UI Editorial Workflow page, when we add submissions received (268) + other submissions (225) = 493
One complexity of our setup is that we have multiple journals running on one installation of OJS, so info for one journal has to be extracted from the totals.
Hi @mreedks,
Oh, yes, that looks good – my addition (out of my head) above was wrong 
– so yes, 493 submissions in total = submissions received (268) + imported submissions (255).
Submissions In Progress are already counted under Submissions Received, and in your case = 0.
Other Submissions = Submissions In Progress + Imported Submissions.
And your explanation about the declined submissions sounds reasonable. I will test such a case locally, just to be sure.
I can also take a look what everything has changed between 3.3.0.8 and 3.4.0.5. I know about a few improvements, but those have definitely lead to more correct statistics. I will let you know…
Hmmm… That is a little bit strange – I see in your screenshot that at least one submission has date_submitted < date_published…
Could you double check if you have this change in your code, in lib/pkp/classes/services/queryBuilders/PKPStatsEditorialQueryBuilder.php: pkp/pkp-lib#9132 fix SQL datetime and date comparison for editorial s… · pkp/pkp-lib@07907d1 · GitHub ?
Thanks!
Bozana
Hi @bozana
Yes, we have that change in our code.
Our setup have multiple journals running on one installation too. 203 journals in total.
Another thing that also indicates that something is wrong is the totals above the table. All showing 0:
For testing purposes, I even commented on this change you sent to see what would happen.
There was only a change in the Other Submissions count and everything else remained at zero.
I forgot to mention when opening this post, and sorry about that, here we use PostgreSQL, currently in version 15.6.
There is probably some difference in the way databases respond to these queries.
Regards,
Tarcisio Pereira
Here’s an example from another journal. This particular journal is a new journal that started last year (i.e. no back content loaded), had some submissions in 2023, some in 2024.
The total numbers seem to be OK, but those for the date range are not. Note that there were 8 submissions, with 5 declined and 4 accepted, but the Acceptance and Rejection Rates for that time period show 100% rejection and no acceptances.
Since this journal didn’t start until 2023, the totals for the date range January 2023-March, 2024 should be the same as the Total column.
Hi @mreedks
Regarding the different numbers for the date range and total, although the date range is the total date range for the journal:
Could you please execute this SQL in your DB:
SELECT MIN(date_submitted) FROM submissions where context_id = X
where X is the journal ID from your last example?
Else, I found out why the average is not calculated correctly – the way how the accepted submissions are get is here different form the way they are get for “Submissions Accepted”. This is a bug, and I added it to the list in this issue Improve Editorial Activity calculations · Issue #9813 · pkp/pkp-lib · GitHub (the last point).
@bozana Here are the results of that query:
MariaDB [ojs]> select min(date_submitted) from submissions where context_id = 34;
±--------------------+
| min(date_submitted) |
±--------------------+
| 2019-05-13 14:44:14 |
±--------------------+
1 row in set (0.001 sec)
Thanks a lot @mreedks!
Could you now try to enter this date (2019-05-13) as the start date for the editorial activity stats? How are the numbers then?
Hi @mreedks, that then looks much better, right?
EDIT: regarding your concern about the different numbers for the date range and total…
For the acceptance and rejection rate I found a bug that I will fix within this GitHub Issue: Improve Editorial Activity calculations · Issue #9813 · pkp/pkp-lib · GitHub, as I said above… but the other numbers (also except Submissions In Progress for which I also found a bug) look good now, no?
Yes, I see the same problem as you do when using PostgreSQL. I will try to find out the reason/fix…
Thanks!
Bozana
