Author sequence in returned API JSON incorrect

[jnugent]

Update 2025-04-04

PRs:

stable-3_3_0

• pkp-lib: pkp/pkp-lib#7844 Author sequence in returned API JSON incorrect #11230
• ojs: pkp/pkp-lib#7844 Author sequence in returned API JSON incorrect ojs#4811
• omp: pkp/pkp-lib#7844 Author sequence in returned API JSON incorrect omp#1939
• ops: pkp/pkp-lib#7844 Author sequence in returned API JSON incorrect ops#943

Describe the bug
The returned JSON when fetching a publication with an API call of the type:

https://journal.org/index.php/path/api/v1/submissions/xxxxx/publications/xxxxx

Includes the wrong sequence for authors. It sets the seq attribute of all of the authors to the sequence the publication has in the issue. Here is a relevant database record showing the sequence of the publication:

And here is the JSON for some of the authors. The author sequence is circled:

I've dumped variables and it seems that this is set this way already, here:

pkp-lib/classes/services/PKPPublicationService.inc.php

Line 171 in 3ffbbe1

$publication->getData('authors')

Sequence is correctly set in the authors table for the record, and the author string is also correct.

Seen in 3.3.0.8

[jnugent]

I've done some more digging in this and I suspect the reason for this is that the QueryBuillder for authors selects * here:

pkp-lib/classes/services/queryBuilders/PKPAuthorQueryBuilder.inc.php

Line 123 in 3ffbbe1

$this->columns = ['*', 's.locale AS submission_locale'];

And joins on the publications table. Doesn't this potentially create two seq columns in the result? I think it does, and the JSON is including the publication one, rather than the author one.

This query is also used when fetching authors for other purposes like when building the author string but the sort clause is table specific:

pkp-lib/classes/services/queryBuilders/PKPAuthorQueryBuilder.inc.php

Line 169 in 3ffbbe1

$q->orderBy('a.seq', 'ASC');

which is why sorting for authors is fine. It's just when you look at the JSON that there's a problem.

[JakobRing]

I also have a similar but not quite the same problem.

I'm currently building a plugin for OJS 3.3 and when I use $submission = $submissionDao->getById($submissionId); the authors included into the publication included into the submission-object all have the seq from the publication.

Why am I writing this? Because I think (but not sure currently) with this call fetching the data does go another route. So fixing this may be not only a problem of one function but of (some) more?

I think it goes something like this:

SubmissionDao->getById() as it inherits from SchemaDAO

pkp-lib/classes/db/SchemaDAO.inc.php

Line 55 in c77c859

return $row?$this->_fromRow($row):null;

pkp-lib/classes/submission/PKPSubmissionDAO.inc.php

Line 93 in c77c859

Services::get('publication')->getMany(['submissionIds' => $submission->getId()])

pkp-lib/classes/services/PKPPublicationService.inc.php

Line 78 in c77c859

$queryResults = new DAOResultFactory($result, $publicationDao, '_fromRow');

pkp-lib/classes/publication/PKPPublicationDAO.inc.php

Line 62 in c77c859

Services::get('author')->getMany(['publicationIds' => $publication->getId()])

pkp-lib/classes/services/PKPAuthorService.inc.php

Line 67 in c77c859

$queryResults = new DAOResultFactory($result, $authorDao, '_fromRow');

The $queryResults over here already have the faulty data in them. If I print the first object of the $queryResults->toIterator() its the seq from the publication and not from the author.

EDIT: I dug some more and found that it also goes into the PKPAuthorQueryBuilder::getQuery().
And as @jnugent suggested, I also think that

pkp-lib/classes/services/queryBuilders/PKPAuthorQueryBuilder.inc.php

Line 123 in 3ffbbe1

$this->columns = ['*', 's.locale AS submission_locale'];

is the problem.

For this case changing the * to a.* does fix the problem for me and the correct seq are included into the author-objects (and nothing else is changed inside the whole submission object). BUT: I don't know if this change does affect some other methods so that these don't work correctly anymore but I don't think so. I hope that this comment was helpful to fix the problem.

[ewhanson]

Thanks for sharing the additional info and your fix, @JakobRing. Will get this updated.