Skip to content

pkp/pkp-lib#11025 Include issue info on submission API data #4779

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 27, 2025

Conversation

taslangraham
Copy link
Contributor

@@ -41,6 +44,9 @@

class Schema extends \PKP\submission\maps\Schema
{
/** Issues associated with submissions. Keyed by submission ID. */
Copy link
Contributor

@jonasraoni jonasraoni Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/** Issues associated with submissions. Keyed by submission ID. */
/** @var Enumerable<int, Issue[]> Issues associated with submissions. Keyed by submission ID. **/


/**
* Get issues associated with submissions. Results are keyed by submission ID.
*
Copy link
Contributor

@jonasraoni jonasraoni Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's keyed by submission ID 🙃

Suggested change
*
* @param Enumerable<int, Submission> $submissions Submissions, keyed by submission ID.
*

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not required to be keyed by submission ID

Comment on lines +186 to +190
$submissionIds = $submissions->map(fn (Submission $submission) => $submission->getId())->all();
$publications = Repo::publication()->getCollector()->filterBySubmissionIds($submissionIds)->getMany();
$issueIds = $publications->map(fn (Publication $publication) => $publication->getData('issueId'))
->unique()
->all();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the Submission object is supposed to have data in the getData('publications'), which will be a list of publications, then the $submissionIds can be removed and the $publications can be optimized.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I guess this is the class where the publications is populated, so I'm not sure if the data is available yet, if not, so ignore my comment 🤔


return $submissions->mapWithKeys(function ($submission) use (&$issues, $publications, $issueIdsGroupedBySubmission) {
$submissionIssueIds = $issueIdsGroupedBySubmission->get($submission->getId())->all();
return [$submission->getId() => $issues->filter(fn ($issue) => in_array($issue->getId(), $submissionIssueIds))];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the $issues is keyed by issueId, then instead of filtering through all issues, followed by an in_array(), you can just collect the right ones.

I mean something like [$submission->getId() => $submissionIssueIds->map(fn (int $issueId) => $issues->get($issueId))

$issueIdsGroupedBySubmission = $publications->groupBy(fn (Publication $publication) => $publication->getData('submissionId'))
->map(fn ($entry) => $entry->map(fn (Publication $publication) => $publication->getData('issueId')));

return $submissions->mapWithKeys(function ($submission) use (&$issues, $publications, $issueIdsGroupedBySubmission) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reference is not needed, the variable isn't updated inside the callback

Suggested change
return $submissions->mapWithKeys(function ($submission) use (&$issues, $publications, $issueIdsGroupedBySubmission) {
return $submissions->mapWithKeys(function ($submission) use ($issues, $publications, $issueIdsGroupedBySubmission) {

}

/**
* Get details about the issue a submission will be published in.
Copy link
Contributor

@jonasraoni jonasraoni Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Get details about the issue a submission will be published in.
* Get details about the issue a submission will be published in.
* @param Enumerable<int, Publication> $publications Publications, keyed by publication ID.

Comment on lines 236 to 238
if (empty($this->submissionsIssues)) {
$this->submissionsIssues = $this->getSubmissionsIssues($submissions);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (empty($this->submissionsIssues)) {
$this->submissionsIssues = $this->getSubmissionsIssues($submissions);
}
$this->submissionsIssues ??= $this->getSubmissionsIssues($submissions);

{
/** @var Publication $latestScheduledPublication */
$latestScheduledPublication = $publications
->filter(fn ($publication) => $publication->getData('status') === Submission::STATUS_SCHEDULED)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you just need the publications which are going to be published in the future, right? Otherwise, I think the STATUS_PUBLISHED should be included.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are only interested in the scheduled publications

->sortByDesc(fn (Publication $publication) => $publication->getData('version'))
->first();

if ($latestScheduledPublication) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this type of early return is better to read

Suggested change
if ($latestScheduledPublication) {
if (!$latestScheduledPublication) {
return null;
}

}

/**
* Populate class properties specific to OJS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Populate class properties specific to OJS.
* Populate class properties specific to OJS.
* @param Enumerable<int, Submission> $submissions Submissions, keyed by submission ID.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$submissions won't necessarily be keyed by ID, example when this method is called from map method in schema, like: $this->addAppSpecificData(collect([$item]));, that won't be keyed by submission ID

if ($latestScheduledPublication) {
$submissionId = $latestScheduledPublication->getData('submissionId');
$issueId = $latestScheduledPublication->getData('issueId');
$issue = $this->submissionsIssues->get($submissionId, collect())->get($issueId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps:

Suggested change
$issue = $this->submissionsIssues->get($submissionId, collect())->get($issueId);
$issue = $this->submissionsIssues->get($submissionId)?->get($issueId);

Copy link
Contributor

@jonasraoni jonasraoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a reader it's not clear for me that the $this->submissionsIssues will be filled implicitly, some time before the getPropertyIssueToBePublished() is called, so I decided to watch better this Schema class...


I see the purpose of most of the code in this PR, and also the PR for the pkp-lib, is mostly to pre-load the list of issues, which is good, but I think there's a simpler alternative.

Looks like $this->collection will be filled whenever a list of submissions is going to be mapped, so you can probably drop most of the code, and use a generic Issue loader on the getPropertyIssueToBePublished(), e.g.:

    private function getIssue(int $issueId): ?Issue
    {
        if ($this->cachedIssues === null) {
            if (!$this->collection) {
                $this->cachedIssues = collect([$issueId => Repo::issue()->get($issueId)]);
            } else {
                //code from the `getSubmissionsIssues()`
                $this->cachedIssues = ...;
            }
        }
        
        return $this->cachedIssues->get($issueId);
    }

@taslangraham
Copy link
Contributor Author

As a reader it's not clear for me that the $this->submissionsIssues will be filled implicitly, some time before the getPropertyIssueToBePublished() is called, so I decided to watch better this Schema class...

I see the purpose of most of the code in this PR, and also the PR for the pkp-lib, is mostly to pre-load the list of issues, which is good, but I think there's a simpler alternative.

Looks like $this->collection will be filled whenever a list of submissions is going to be mapped, so you can probably drop most of the code, and use a generic Issue loader on the getPropertyIssueToBePublished(), e.g.:

    private function getIssue(int $issueId): ?Issue
    {
        if ($this->cachedIssues === null) {
            if (!$this->collection) {
                $this->cachedIssues = collect([$issueId => Repo::issue()->get($issueId)]);
            } else {
                //code from the `getSubmissionsIssues()`
                $this->cachedIssues = ...;
            }
        }
        
        return $this->cachedIssues->get($issueId);
    }

I think the suggested code kind of drifts away from the existing pattern of how data is being pre-loaded before being used in a getPropertyXYZ method throughout the schema. Best if this PR keeps consistent with how things are already being done.

@taslangraham taslangraham requested a review from jonasraoni March 25, 2025 16:28
@taslangraham taslangraham merged commit 90c9fcd into pkp:main Mar 27, 2025
7 of 8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants