Q4.2024 Release

Clients who use the Prohibited Person List feature can screen author names at submission, screen editor and reviewer accounts, and send alerts to EICs and staff editors if weak or strong matches occur which are configurable values. Previously, the functionality was only available for Authors and was named PAL “Prohibited Authors List”.

The functionality is an integration with ScholarOne Manuscripts to pull in a Prohibited Person List (PPL) via API (using Amazon Web Services S3). ScholarOne warns the client’s staff members on the Manuscript Details screen when any Person on a submission is on the client’s list. The functionality is not available by default.

Clients need the ability to Create, Read, Update, and Delete records. CRUD represents the basic operations that can be performed on data in a database or information system. These four operations form the foundation of how data is managed and manipulated in applications.

• Create: This operation allows the addition of new data or records into a system or database.
• Read: This refers to retrieving or fetching data from a system. It allows users or applications to view or display existing data without making any changes to it.
• Update: This operation involves modifying or editing existing data in the system.
• Delete: This action removes data from the system or database.

The Prohibited Person List database includes the category of “Prohibited Role”.  The list of data consists of the following categories:

First Name: Text field
Last Name: Text field
Affiliation: Text field
Email Address: Text field
Prohibited Role (New): Drop down list to indicate “Author” “Editor” “Reviewer”
Start Date: Calendar date selection
End Date: Calendar date selection

*In cases where an individual has been prohibited from more than one role, the client needs to enter a separate database entry for each role.

Role types supported for PPL in ScholarOne Manuscripts:

Journal staff see warning alerts if an Author in a submission is on the PPL. This alert will allow users to access a detailed match report.

When the submitting author is a strong match and submits a manuscript on an existing site with PPL enabled a red background alert is shown.

The alert includes a “View Matches” button, placed under the links to files and above the Unusual Activity Detection alert. This alert appears on all Manuscript Submission Details tabs, including Select Reviewers, Manuscript Information, and Audit Trail.

View Matches Details:

View Matches Button:

• Appears on both strong and weak match alerts.
• Clicking the button opens the match report for PPL matches.

Last Name: Displays the PPL last name. In weak matches, both the label and value are red.
First Name: Displays the PPL first name. In weak matches, both the label and value are red.
Email: Displays the PPL email. In strong matches, both the label and value are red.
Affiliation: Displays the PPL affiliation.
Start Date: Displays the PPL start date.
End Date: Displays the PPL end date.

Results Area:

• Strong Matches — Exact match on email address.
• Weak Matches — First initial and last name match.
• Instruction Text: Input is configurable.

Similarly, if the submitting author is a weak match and a co-author is a strong match, the same red alert is displayed.

If the submitting author is a weak match, the alert is displayed with a yellow background, accompanied by the “View Matches” button.

Audit trail

If one or more Authors on a manuscript match the Prohibited Author List, an Audit Trail entry is created. It displays:

• That the report was run in the standard audit trail format (MS ID, Date, etc.)
• # of Strong matches
• # of Weak matches

Notifications

Notification is created for the event that an Author matches the Prohibited Author List. It consists of:

• messageUUID

1. Description: Global unique identifier of the message.
2. Type: String
3. Possible Values: System generated
4. Example or Default Value: 9d7e3773-32ea-481e-a647-944bbe9c24a9

• notificationServiceVersion

1. Description: The version of Notifications Services the endpoint is configured to receive
2. Type: String
3. Possible Values: V1
4. Example or Default Value: V1

• siteName

1. Description: Site short name. The short name is the abbreviated or truncated name of the journal, society, publisher, or family.
2. Type: String
3. Possible Values: Short name of the Site
4. Example or Default Value: test

• journalName

1. Description: The long name associated with the journal as defined during issue creation.
2. Type: String
3. Possible Values:
4. Example or Default Value: Test Journal

• eventDate

1. Description: The date and time in UTC the event occurred.
2. Type: Date
3. Possible Values:
4. Example or Default Value: 2014-11-05T10:34:02Z

• subscriptionId

1. Description: System generated ID for each Subscription
2. Type: Number (Integer)
3. Possible Values: System generated
4. Example or Default Value: 80

• subscriptionName

1. Description: The name of the subscription that triggered the message.
2. Type: String
3. Possible Values: User entered in Configuration
4. Example or Default Value: Withdrawn Manuscript

• subscriptionType

1. Description: The system label for the type of subscription. Available subscription types are Decision, Task Status Change, and System Event.
2. Type: String
3. Possible Values: DECISION, TASK_STATUS_CHANGE, SYSTEM_EVENT
4. Example or Default Value: DECISION

• documentId

1. Description: Unique identifier of the document. Unique identifier for each Manuscript Revision in the ScholarOne Manuscripts system. Internally to ScholarOne, this is a numeric value.
2. Type: Number (Integer)
3. Possible Values: System generated
4. Example or Default Value: 16346023

E-mail Template and e-mail TAG

E-mail template name: Prohibited Author List (PAL) Matches

E-mail template is available at Emails > System E-mails > Misc. Event Driven E-mails

The email(s) will be sent when:

• PPL feature is configured
• There is a match with the PPL

Tooltip: This email is triggered when one or more Authors have a strong or weak match with the Prohibited Authors List.

Email Tag  ##PAL_SUMMARY##: This is a summary of Authors matching the Prohibited Authors List (PAL). No names are displayed within the tag for privacy reasons.

Resolved copy:

• Strong Matches #
• Weak Matches #
• View Report: Clicking on this button will display the report of matches with the PAL

Reviewer Search

• When performing a reviewer search, which can be initiated through Quick Search, Related Papers Search, Auto-Suggest, or Advanced Search, the system will process the results according to the PPL database, which contains records of prohibited users (PPL).

If the search results include a hard match, based on both the email address and the role of the reviewer from the PPL data, the system will display a visual warning on the reviewer’s record.

This warning is accompanied by a short message informing the user that the reviewer is on the PPL list. In such cases, the reviewer cannot be added to the document, and the checkbox for adding them will be disabled. Additionally, a tooltip will appear over the disabled checkbox, indicating that the reviewer may not be added.

If the person details popup is opened for a reviewer record with a hard match, the system will not display the “Add to List” button, reinforcing that this individual cannot be added to the document.

In instances where a soft match is found—based on name and role rather than email—the system will still show a visual warning and display a message stating that the reviewer is on the PPL list.

• When interacting with the Review Locator section in a document, if the system suggests a reviewer and detects a hard match (email and role) from the PPL data, the suggested reviewer’s record will also display a visual warning with a message indicating their presence on the PPL list. Like the earlier case, the suggested reviewer cannot be added to the document, and the “Add” button will be absent.

For soft matches based on name and role, the system will still display a visual warning along with the message about the reviewer being on the PPL list.

• In the ScholarOne Reviewer Recommender system, when a reviewer search is performed, a soft match based on the name and role from the PPL data will trigger a visual warning and a message that the reviewer is on the PPL list. For hard matches, the suggested reviewer will be flagged in the same manner, with the system prohibiting their addition to the document and removing the “Add” button from the interface. Similarly, if the details popup is opened for the reviewer, the system will not display the “Add to List” button, ensuring compliance with PPL restrictions. The display is the same as for the Reviewer Locator search results.

Associated Editor

Search AND the assignment from the dropdown list

• In the case of an Associate Editor (AE) search, once again using search methods such as Quick Search, Related Papers Search, Auto-Suggest, or Advanced Search, if a hard match based on email and role is detected, the editor’s record will show a visual warning with a corresponding message that the editor is on the PPL list. The editor will not be allowed to be added to the document, and the “Add” button will not be present.

If the search results return a soft match based on name and role, the system will display the same type of warning as described previously, alongside a message informing the user that the editor is on the PPL list.

• If the system is configured to strong>allow users to add editors by selecting them from a dropdown on the document, a hard match based on email and role will lead to a disabled selection for that editor. A visual warning and message will indicate the editor’s presence on the PPL list as a strong match.

In cases of soft matches from the dropdown selection, the editor record will also display a warning, and a tooltip will indicate that the editor is on the PPL list for a weak match.

• When both a hard and soft match are found in the search results, the system will prioritize the hard match (based on the email address), ensuring that this record takes precedence over any soft matches (based on name). As a result, the editor or reviewer cannot be added to the document.

API’s

1. Read

GET request:https://mc-beta-api.manuscriptcentral.com/api/s1m/v3/pal/read?site_name=TEST&clientGUID=1_11111111&roleName=Reviewer

2. Create

POST request:https://mc-beta-api.manuscriptcentral.com/api/s1m/v3/pal/create?site_name=TEST

Request body:

1. {
2. “input”: {
3. “clientGUID”: “1_111111111”,
4. “firstName”: “Paladin8”,
5. “lastName”: “test”,
6. “startDate”: “2022-08-07”,
7. “endDate”: “2024-01-19”,
8. “configId”: “4801”,
9. “createToken”: “xik_wufhoksc8ocX5AgsyprDiEqZHN69nx4bWptFknCEwcKyz5kwQw2Q3dpyqaNsLDBm45Cav9k”,
10. “emailAddress”: “user@strongaffiliation.com”,
11. “affiliation”: “NASA”,
12. “roleType”: “REPORT_VIEWER”
13. }
14. }

3. Update

POST request:https://mc-beta-api.manuscriptcentral.com/api/s1m/v3/pal/update?site_name=TEST

Request body:

1. {
2. “input”: {
3. “clientGUID”: “1_111111111”,
4. “firstName”: “Paladin8”,
5. “lastName”: “test”,
6. “startDate”: “2022-08-07”,
7. “endDate”: “2024-01-19”,
8. “configId”: “4801”,
9. “updateToken”: “xik_wufhoksc8ocX5Agsy”,
10. “emailAddress”: “user@strongaffiliation.com”,
11. “affiliation”: “NASA”,
12. “roleType”: “REPORT_VIEWER”
13. }
14. }

4. Delete

POST request:
https://mc-beta-api.manuscriptcentral.com/api/s1m/v3/pal/delete?site_name=TEST

Request body:

1. {
2. “input”: {
3. “clientGUID”: “1_111111111”,
4. “configId”: “1234567”,
5. }
6. }

• Send a ReadPAL GET request to our system- it has to contain the clientGUID (this is a value clients define, it can be anything but it has to be unique on that site – i.e. user_cc_2234355 ), the site shortname and the role type.
• The response will provide you with the createToken. If the clientGUID already exists, then you’ll get an updateToken. It will not provide the configID. We can provide that value to clients for testing.
• Then you can use the information gained to make a POST call to either create the record (if the clientGUID does not exist) or to update it (if it already exists).

If a deletion request for a PPL record is made via the API, any hard or soft match reports for a will be deleted from the system. Subsequent searches will allow the reviewer or editor to be added to documents without any restrictions, as the disabling conditions will no longer apply.

Error list with error codes

1. roleName
   • error code: “WVLD-11289” roleType is too long
   • error code: “WVLD-11288” Entered role type does not exist.
2. Found multiple prohibited role types by provided criteria. Specify which prohibited roleType to update/delete. – with error code “WVLD-11373“