PKP Oslo Sprint Notes Released: Merge Users

The Merge Users summary from the PKP OSLO Sprint, hosted by the University of Oslo in June 2025, is now available.

Sprints involve PKP community members joining diverse groups to work on PKP software and support. The University of Oslo (UiO) hosted eight working groups at the PKP Oslo Sprint in June. This is a summary of one such group’s work.

Abstract

In large-scale OJS installations, duplicate user accounts—often resulting from multiple email addresses used by the same individual—pose operational and privacy challenges for editors, authors, and reviewers. While administrators currently have the capability to merge accounts, the process lacks user authentication and fails to fully comply with GDPR principles. This work explores workflows that shift the responsibility of initiating and confirming account merges to users, thereby enhancing compliance and transparency.

We present two primary use cases: (1) Administrator-initiated merges with user confirmation, where both accounts must verify the merge request via email or in-app interaction, and (2) User-initiated self-service merges, where users can request the consolidation of accounts directly from their profile, triggering a confirmation workflow between both accounts. Additional preventive strategies are discussed, including mechanisms to detect and warn of potential duplicate accounts during user registration and allowing alternate email addresses to flag duplicates preemptively.

Our goal is to improve data integrity and streamline account management while aligning more closely with privacy regulations. The proposed workflows aim to empower users, reduce administrative overhead, and prevent duplication before it occurs. These approaches are currently under exploration in the PKP development roadmap

Working Group members

• Tom Granroth, Federation of Finnish Learned Societies
• Antti-Jussi Nygård, Federation of Finnish Learned Societies
• Beau Grier, Public Knowledge Project
• Ahmed Mohammed, University of Oslo (UiO)
• Ragnar Pareli Pedersen, Norwegian University of Science and Technology
• Jyrki Heinonen, Federation of Finnish Learned Societies
• Kristian Gavran – University Zurich (UZH)

Background

In larger installations it is quite common that a new account has been created for the same user using a different email account. This usually creates problems and confusion with editors, authors and reviewers.

The administrator has the ability to merge accounts in these situations, but it would be better for GDPR reasons that the user would be more involved and there would be a clear way of authenticating the user with the two accounts.

We would require a merge process that relies more on authentication coming from the user and is more GDPR compliant

Also we should consider ways of preventing duplicate accounts before they are created.

Goals

• Discuss different use cases where problems with merge users exist
• Discuss different workflows for solving the problems
• Choose two use cases / workflows and discuss and describe these further
• GitHub issue: https://github.com/pkp/pkp-lib/issues/11442

Results

Initial recognition of use cases and workflows:

1. When administrator is merging accounts get a confirmation for the merge
2. Allow users to merge accounts by themselves
3. Preventing automatically the creation of a new account for the same user
4. When creating a user notify for possible duplicate accounts

Use Case 1 (Confirmed merge): When admin is merging accounts the user needs to accept the merge with both accounts

A user has two individual user accounts and these need to be merged. The administrator gets a request from the user or from an editor to merge the accounts. The administrator needs to authenticate that both accounts are from the same user to ensure GDPR compliance.

New functionality in OJS to send a confirmation to both accounts before merging

Step 1: Administrator request permission to merge accounts:

• New Request to Merge user invitation

Step 2: Select the account that you want to merge to

Step 3: The system sends email to both accounts

Step 4: The merge request is visible in the list of Invites

Step 5: The user needs to accept the merge or can decline

• This can happen by clicking a link in the email OR
• By logging in and clicking a Accept/Decline button in the User Profile

Step 6: If confirmation is done the administrator can finish the merge process

Step 7: A confirmation email is sent to the remaining account

Problems

• One or both email addresses are not functional anymore
  • Would require some other form of authentication, list of questions about the accounts etc.
• The user can not access the account anymore

Use Case 2 (User initiated merge): Allow users to merge accounts by themselves

At the moment a user can not initiate an account merge himself from the profile page.

Definitions

• Target Account: the user account that we want to merge
  • In the beginning, the account status is “open for merge“
• Main Account: the user account that the Target Account will be merged into. After merging, the target account is deleted.
  • In the beginning, the account status is “open for merge“

New workflow

A user can initiate an account merge from the profile page.

Steps to create the user-initiated merged email workflow:

• Logged into the Main account, the user goes to the profile page > identity
• New Section “Merge User” shows email input field “Target User Email”

• The user enters an email
  1. validation steps needed:
     1. Only allow email as input
     2. Target User Email exists in the system. If no Target User Email exists handle error and don’t initiate the merge process
• The user clicks the save button
  1. Main Account & Target account status changes to “merge pending“
• New Section “Merge User” will then be locked out and a message “Email is in the process of merging” is shown
• An Email is sent to Target Account to accept or decline account merge request
  1. User clicks “accept” → merge account
     1. Main Account status changes to “open for merge“
     2. Target account data is merged and the account is deleted
  2. User clicks “decline” → cancel merge process, Main Account & Target account status changes to “open for merge“

1. Merge requests should also automatically be declined after a time delay

Open points

• Should the user-initiated merge be logged somewhere?
• Should only some roles/user be able to initiate merge?
• How do you deal with users merging higher privileged roles?
  • Should it only be allowed for the same roles?

Use case 3: Preventing automatically the creation of a new account for the same user

1. Alternative emails field in user profile
   • Not for communication but will be checked when new accounts are created

Use case 4: When creating a user notify for possible duplicate accounts

1. When new account created it would send an email to the old account
2. Explain how to get accounts merged

Next Steps

Wider discussion in the community on the preferred approach and more use cases

GitHub issue for further discussion: https://github.com/pkp/pkp-lib/issues/11442

Additional technical details

Although mostly for a general scholarly publishing and communications audience, there will likely be people accessing these summaries who will be interested in some of the more technical details – if you’d like, add them here.

Thank you

We once again thank the Sprint host institution and all participants for their valuable contributions to the PKP user community. Special thanks to the University of Oslo for their support.