Journals should be notified when a user answer an invitation to a role

Describe the problem you would like to solve
This feature was first discribed as a bug on PKP forum: Can editors be not notified when a user respond to an invitation to a role?

Describe the solution you’d like
At minimum, a notification should be sent by email to the journal main contact mentioning that an invited user responded to the invitation.

Who is asking for this feature?
Librarian hosting a journal service. Some journals we host have expressed concern with the new OJS 3.5 users invitation refactoring and the management of invitations roles.

The first description was not detailled enough. The proposed improvments of this feature request tend to find solutions to some limits in the current implementation of the new invite to a role feature that was introduced in OJS 3.5 and that I already documented on PKP forum ( https://forum.pkp.sfu.ca/t/inviting-to-a-role-propositions-to-improve-this-feature-especially-for-reviewers/98157; in this post, I try to tackle essentially the first problem described 1) The invitation to role users’ responses are not logged anywhere in OJS.).

I will first be summing up the way Invite to a role is working and then propose 2 different ways that can improve this feature.

Describe the problem you would like to solve

Since OJS 3.5, adding a user or adding a role to an existing user is subject to the user approval. All invitations are listed in a specific new table in the User & Role page containing the following information :

To invite someone to a role, the editor must send an invitation email. The user receiving the email can:

  • Accept the invitation: this is a 3-step process in OJS (control and confirm information; create username and password and confirm)
  • Decline the invitation: one step process
  • or do nothing.

In the latter case (do nothing), the user will be removed from the invitation list automatically after a delay that needs to be configured (expiration_days). The default value is 3 days.

When a user either accepts or declines the invitation, the user disappears from the invitation table.

The main problem with the invitation right now is that editors are not notified when a user has answered and they do not have, in the UI, a simple way to know why a user disappeared from the list: has the delay expired? Has the user approved or refused the invitation?

The 2 propositions below try to solve the problem. I tend to see the second proposition as “Logging information in the Invitation to a role table or dashboard” as a priority.

Describe the solution you’d like

Proposition 1: email notification

When a user responds to an invitation, an email is sent to the journal email address to inform journal editorial team what was the answer of the user.

This would require creating a new template. If possible, one template would be better. An alternative would be 2, one for acceptance and another for decline.

Recipient: journal Principal Contact email

The email should contain:

  • The user decision.
  • The email of the user and if provided the name and given name.
  • The role he/she was invited to.
  • If the invitation was for a brand-new user (first time invitation) or a new role for an existing user.

Email is sent when user accept the invitation (button Accept and Continue to OJS) or decline it (button Confirm Decline Invitation), as illustrate d below:

Acceptance

Decline

Proposition 2: logging information in the Invitation to a role table or dashboard

When a user answers an invitation to a role, the answer is logged in the invitation table. The editor can remove the user manually. An invitation that has been answered may disappear after a certain period (i.e. 10 days).

The invitation table has already five columns:

  • Name: given name and name
  • Email: user email address
  • Invitation: the role the user has been invited to
  • Status: the date when the invitation was sent.
  • Affiliation: the institution the user is affi liated with.

The Status column is a good candidate to log the answer provided. 2 additional values should be added:

  1. Accepted
  2. Declined

When accepted, the user will be removed from the table the delay that is configured (this delay settings already exist as described above), or manually by the editors.

When declined, the user can be removed manually by the editors. It may be relevant not to remove the user automatically.

Manually removing is a new option in t he contextual menu.

Table below provides examples (new f unction are in blue)