The use of the Inter-Journal Resource Sharing (IJRS) feature does not merge member publications People databases into one common database. A certain set of fields are synchronized, and each user record receives a system-generated Global User ID, which is the same across all the IJRS-connected sites. Individual member sites continue to maintain publication-specific People data (e.g., people notes, Role names, Role powers, Role designations).
When a user registers or logs into a site that is part of a People-Sharing Group, the fields shown below are propagated (if the user is not already registered on all sites in the group) or synchronized (if the user already has a user record on all sites in the group). Custom People Fields (created by the publication and associated with People records) are not synchronized from one publication to another.
|
PEOPLE FIELDS |
|
|---|---|
|
Title |
ResearcherID |
|
First Name |
Username |
|
Middle Name |
Password |
|
Last Name |
Classifications [where exact match on number and description] |
|
Degree |
People Record Last Update Date |
|
Nickname (Preferred Name) |
Proxy Registered [yes or no] |
|
ISNI |
Registration Date |
|
ORCID |
Global User ID |
|
PubMed Author ID |
Timestamp of Most Recent Synchronization |
|
ADDRESS FIELDS |
|
| Person Inactivated [yes or no] | ISO Country Code |
| Position | Telephone Number |
| Institution | Secondary Telephone |
| Department | Secondary Telephone Type (Home, Work, etc.) |
| Address 1 | Fax Number |
| Address 2 | Email Address |
| Address 3 | Preferred Method of Contact |
| Address 4 | Address Type (Home, Work, etc.) |
| City | Date Address Last Updated |
| State | Date Alternate Address Activated |
| ZIP or Postal Code | Date Alternate Address Inactivated |
| Country or Region | |
| SECONDARY FIELDS | |
| Secondary First Name | Secondary Address 1 |
| Secondary Last Name | Secondary Address 2 |
| Secondary Institution | Secondary Address 3 |
| Secondary Degree | Secondary Address 4 |
| Secondary Position | Secondary City |
| Secondary Department | Secondary State |
In addition to the user information above, IJRS-group members may opt to share Classifications.
Each publication's Classification list may or may not match those of other publications in the IJRS group. If publications do share a common Classification list (code numbers and text descriptions must be exactly the same), then users Personal Classification can be synchronized across publications.
During username and contact information synchronization from one publication to another (in the IJRS group), if an exact Classification match exists between an individual's Personal Classifications and the publication's Classification list (i.e., code numbers and text description are the same), then the matching Classifications will carry over to the second publication at the time of a new registration. If the individual was already registered on the second publication (and is logging in for a return visit), matching Classifications are updated. Personal Classifications that do not match will not synchronize.
Publications in a group may have non-identical Classification schema; maintaining a master list of Classifications across publications in a group is not required. If individual publications want to add local variants to the Classification schema, they can do so; these do not copy to other publications (since there are no matching codes and descriptions).
Note: Synchronizing may remove a user's shared Classification in another publication. For example, if a user deselects a Personal Classification on Journal A, then the exactly matching Classification is deselected for that user on other publications in the group. Non-matching Classifications are not deleted.
No system configuration is required.
If IJRS-group members choose to maintain totally synchronized schema across all publications in the group, this must be set up manually by establishing and sharing codes and text descriptions for Classifications.
See the related article on Defining classifications.
If a new registrant tries to sign up with a username that is already in the system for another user, then the system automatically offers the registrant a new username. The registrant may take the new username or go back and enter a different username.
The first time an already-registered user logs into a publication that is part of an IJRS group (the first time the user has logged-in since the publication joined the group), the user's data is propagated to all other publications in the group. If this person's username is already taken by someone else in another publication, then the system automatically offers a new username.
ActionManager triggers an event called Forced Username Change when a user registers or logs into a publication that is part of an IJRS group. (This event does not require any configuration in the Document Status section of ActionManager, as it has no effect on the status of a submission.)
Each journal should create a new letter for the Forced Username Change event to be sent to the person whose username has been changed. To create the new letter, go to PolicyManager > Email and Letter Policies > Edit Letters, and click the Add New Letter button. Enter the following:
Click the Continue button to proceed to the Add Letter page, fill out applicable fields, and click Save.
After creating the letter, go to ActionManager > Author Letters > Registration > Forced Username Change, and select the new Forced Username Change letter in the drop-down list. Click Submit.
Note: This letter should only be set up in the Author Letters section of ActionManager, so that only the individual user receives the letter. The Author role is the generic user role that everyone shares, and it is therefore the place that any letters not associated with a submission should be configured.
Each individual publication in an IJRS group has the option of flagging a person's contact information on its particular site as protected contact information, so that the information is never overwritten by other publications in the group. (For example, a person who serves as an Editor for Journal A and as a Reviewer for Journal B may use his office address and email for Journal A, and his home address and email for Journal B.) In the absence of this explicit indication, contact information is synchronized across all publications in the group.
If the protect contact information option is enabled, username and password can still be changed.
Editorial staff with Search People permission can set this preference. Search for the user's name and click on it to go to the user's Search People – Update Information page. Check the box net to the option: "Do not allow this contact information to be overwritten during synchronization with other journals in the group." Click the Submit button.
It is recommended that all publications in a People-Sharing Group restrict the use of duplicate email addresses for People records to prevent synching issues. (This restriction applies to Editors entering duplicate email addresses for users during proxy registration and updates to people information.)
For information, see Prevent Duplicate Email Address Entry.
Not restricting the use of duplicate email addresses may prevent record synchronization:
Go to PolicyManager > Registration and Login Policies > Set Duplicate Email Address Policy. Select the "Yes" option by clicking the radio buttons in both sections of the page and click Submit.
To check the policy status for all publications in the IJRS group, go to AdminManager > Share People > View Duplicate Email Policies.
To enable users to log in easily to any publications within your IJRS group, a drop-down list of the publications can be added to the login page. Users can select the desired publication from the list as they sign in.
Go to PolicyManager > Registration and Login Policies > Configure Login Page. Select the radio button next to "Login with Publication Selection" and click Submit.
The Detailed People Notes feature allows multiple notes to be added on a person's record. The individual notes are timestamped along with the name of the user who made the note and publication on which the note was entered.
These notes cannot be edited, but they can be removed. Editors with appropriate permissions can remove notes created by others (e.g., they may want to remove a note with incorrect information and replace it with a new note containing updated information.) Authorized Editors can also add Detailed People Notes to a record during proxy registration.
Detailed People Notes can be shared across publications in an IJRS group. A publication in the group may elect to share these Detailed People Notes with one or more other publications in the group.
Detailed People Notes can also be used as a search criterion on Search People, Search for Authors, and Search for Reviewers (by Editors with appropriate permissions).
Go to AdminManager > Share People > Set Detailed People Notes Sharing Policy. Check the box to enable sharing notes with other publications and click Submit. This setting enables sharing notes to and from any publications in the group that have also checked this setting.
Then go to RoleManager > Editor Role. Select the appropriate Editor role and click Edit. On the Edit Role Definition page, go to Viewing and Editing People Data. Separate permissions must be granted (check the box next to the permission), depending on the level of access.
An additional permission enables the Editor to use the notes in Reviewer searches. Go to the Reviewer Search Criterion section and check the box next to Detailed People Notes.
When finished, click Submit.
See also:
Configure Group User Inactivation and Merging Policies (IJRS)
To return to previous page click ALT + left arrow