pkp/pkp-lib#12035 (3.4.0) Fix issue where recommend-only users cannot add a new review round

[salmanm2003]

This is for: #12035

[jonasraoni]

I think all these ifs can be simplified into:

Suggested change

	} elseif ($stageAssignment->getRecommendOnly()) {
	if ($decisionType->getDecision() === Decision::NEW_EXTERNAL_ROUND) {
	$isAllowed = true;
	}
	$decision = $decisionType->getDecision();
	if (!$stageAssignment->getRecommendOnly() ||
	$decision === Decision::NEW_EXTERNAL_ROUND ||
	Repo::decision()->isRecommendation($decision)) {
	$isAllowed = true;
	break;
	}

[jonasraoni]

In fact, after checking the other nearby lines, I think a lot of improvements should be added here:

• The only purpose of the foreach loop seems to perhaps set the $isAllowed to true, therefore, a break can be added once the value is set to true...
• On the lines 62 and 66: the else isn't needed and can be removed, a decreased indentation simplifies reading code.
• Looks like the block ranging from line 84 until 96 has no dependency with the inner variables of the foreach loop, therefore, it doesn't need to be called many times (there's a query involved and this is expensive) and should be cached... (e.g. $cached ??= (function (){...})(); or using an extra private method)

[asmecher]

I'm ambivalent about this change -- if you were asking me about whether recommend-only users should be able to start a new round, I'd probably say no (not that I'm particularly informed about this aspect of workflow); however, this is a regression from 3.3.0, probably an accidental one made during refactor of editorial decisions. So I'm OK either way.

However, we probably should stay consistent in this decision between internal and external reviews (for OMP).

[jonasraoni]

I've never touched this piece of code, but I've left a couple of suggestions, which I think are good to handle while there's someone touching this.

[salmanm2003]

@asmecher Since this is working fine in 3.4, could you please apply it to 3.4 for now and consider further improvements in later versions? I’ve just simplified the if statements as @jonasraoni suggested, while the remaining enhancements can be addressed for 3.5 and beyond.

[asmecher]

@salmanm2003, I'll leave that decision to @Vitaliy-1 as the workflow lead.

[Vitaliy-1]

@salmanm2003, I'm ok with this change. For consistency, this also should be applied for the 3.5 and main branch. Can you make necessary PRs? Also, I see some additional changes in this PRs which refer to another issue. Should they be here?

[salmanm2003]

@Vitaliy-1 The PR for 3.4 is now ready to be merged, and I have removed the additional commits that were not related to this issue.
While testing 3.5 and main, I found that both contain a bug that allows a recommend-only editor to add a new review round when editing editor details.
To reproduce: assign a new editor and set them as recommend-only. Then log in as that editor, go to Participants, click the three dots, and choose Edit. This changes the permissions and allows the editor to add a new review round.
I believe this issue should be fixed in 3.5 and main before enabling recommend-only editors to add new rounds. Therefore, could you please merge the stable-3_4_0 changes for now? We can address 3.5 and main later when it’s more convenient and after further discussion.

[salmanm2003]

@Vitaliy-1 Would it be possible to merge this into 3.4 soon please? I can then look into the bug separately for 3.5 and main.

[Vitaliy-1]

Thanks, @salmanm2003.
As per Alec's comment, I think we need one more minor change

[Vitaliy-1]

Can we treat OMP specific internal review the same way? See NEW_INTERNAL_ROUND.

[salmanm2003]

Hi @Vitaliy-1 , The changes have been added for OMP as well.
Here is the PR for OMP: pkp/omp#2312
Could you review it please and let me know if any issues?