getAuthorString no longer respects browse inclusion in some places

[jnugent]

Describe the bug
In OJS 3.1.2 the getAuthorString() method used to pass a boolean true to getAuthors which respected the $includeInBrowse flag. This was useful when displaying an author string on a front end template, like an issue's table of contents. That can be seen here:

https://github.com/pkp/pkp-lib/blob/stable-3_1_2/classes/submission/Submission.inc.php#L257

With the refactor to Publications beginning in 3.2, the getAuthorString() method in the PKPSubmission class just hands off that call to the Publication object, here:

https://github.com/pkp/pkp-lib/blob/stable-3_2_1/classes/submission/PKPSubmission.inc.php#L382

But the Publication object now just fetches the authors property:

https://github.com/pkp/pkp-lib/blob/stable-3_2_1/classes/publication/PKPPublication.inc.php#L137

I'm not quite sure if it's still possible to filter by $includeInBrowse, at least on the front end. This seems like a potentially complicated refactor, but perhaps the templates can iterate over the authors instead of calling this method?

We had a hosted client use the Quick Submit plugin to populate an issue in 3.2 and noticed this behaviour.

What application are you using?
OJS 3.2.1-4 (probably also in 3.3)

[NateWr]

Thanks @jnugent. The refactor is designed to take the fetching from the database out of the DataObject, since that can lead to lots of duplicate lookups. But we do need to get this back in. I think the data should be there in the authors array, so we should be able to filter that alright.

[librariam]

+1 from PKP|PS on this one and I can confirm it's still an issue in 3.3.0.8

[asmecher]

As @NateWr suggested, it's available in the author array, so this is actually a pretty quick fix.

PRs:

• pkp/pkp-lib#7016 Restore check for author include in browse list #7619
• pkp/pkp-lib#7016 Restore check for author include in browse list ojs#3273 (tests only)

@NateWr, assuming these pass, could you have a quick look? It's a one-liner.

PRs are against stable-3_3_0 -- this will need cherry-picking forward.

[NateWr]

Publication::getAuthorString() is used in several places, not just in browse lists. I think some care would need to be taken to ensure that this didn't have a negative impact on a stable branch. Here are all the places I find it used in OJS stable-3_3_0:

classes/search/ArticleSearch.inc.php
  80,29: $orderKey = $submission->getAuthorString();

classes/submission/Submission.inc.php
  57,64: $fieldValue = array($context->getPrimaryLocale() => $this->getAuthorString());

lib/pkp/classes/components/forms/publication/PKPPublicationLicenseForm.inc.php
  44,29: $copyright = $publication->getAuthorString($userGroups);

lib/pkp/classes/mail/SubmissionMailTemplate.inc.php
  57,45: 'authorString' => strip_tags($submission->getAuthorString()),

lib/pkp/classes/services/PKPPublicationService.inc.php
  179,36: $values[$prop] = $publication->getAuthorString($args['userGroups']);

lib/pkp/classes/submission/PKPSubmission.inc.php
  405,22: return $publication->getAuthorString($userGroups);

lib/pkp/controllers/modals/editorDecision/form/EditorDecisionWithEmailForm.inc.php
  73,31: 'authorName' => $submission->getAuthorString(),
  87,31: 'authorName' => $submission->getAuthorString(),
  322,32: 'authorName' => $submission->getAuthorString(),
  348,42: 'authorName' => strip_tags($submission->getAuthorString()),

lib/pkp/controllers/modals/editorDecision/form/SendReviewsForm.inc.php
  81,32: 'authorName' => $submission->getAuthorString(),

lib/pkp/controllers/modals/submission/ViewSubmissionMetadataHandler.inc.php
  50,48: $templateMgr->assign('authors', $publication->getAuthorString($userGroups));

plugins/generic/webFeed/templates/rss2.tpl
  67,27: <dc:creator>{$article->getAuthorString(false)|escape:"html"}</dc:creator>

plugins/themes/pragma/templates/frontend/objects/article_summary.tpl
  31,33: <p class="metadata">{$article->getAuthorString()|escape}</p>

templates/frontend/objects/article_summary.tpl
  56,13: {$article->getAuthorString()|escape}

Of those, the use in the license (APP\submission\Submission::57) is probably the biggest risk. But maybe also in the EditorDecisionWithEmailForm and SendReviewsForm.

In the main branch, this has been addressed by adding a flag to getAuthorString(). See here. But it doesn't look like it's been applied in all of the right places. I think the right places would be article_summary.tpl and rss2.tpl. But there may be some other uses that qualify (ArticleSearch?).