Ensure that Managers can control enrolments within their journal

[asmecher]

Describe the problem you would like to solve
Managers are currently prevented from editing user accounts that are active in other journals (presses, servers) that the manager does not manage. This prevents them from performing some operations that they should have access to, in particular managing their enrollment in user groups in the manager's journal.

Describe the solution you'd like
Managers should be able to modify the user groups in their journal, even if the user is active in other journals.

Who is asking for this feature?
Scielo, PKP|PS, and other hosts who manage many journals in one installation

[NateWr]

This should be straightforward in a case where a user already is assigned to a role in the journal. For example, a journal manager can assign the section editor role to a user who already has the author role in their journal.

However, some care will need to be taken in cases where the user does not have a pre-existing role in the journal, in order to comply with privacy legislation such as GDPR. For example, a journal manager who wants to assign the section editor role to a user who has a role in another journal but not theirs, should not have access to this user.

For such cases, the journal manager will need to be able to invite a user to adopt a role. This feature is filed at #3022.

[librariam]

• 1 from a PKP|PS client with a multi-site install

[asmecher]

Some context on the history of this issue: For an installation that has one journal, or where the journal manager is also an administrator, there is no problem.

However, in some installations there are multiple journals with different sets of managers. These journals might have nothing in common, except that they are hosted on the same OJS installation.

Sometimes a single user account will be active in different journals on the same installation, e.g. as an author in one or a reviewer in the other. Because user accounts are site-wide, i.e. a change to the user's profile impacts both journals, it's important to protect a user's account so that a manager of journal A can't substantively modify a user account that is also active in journal B. The current protection is implemented in Validation::canAdminister. The logic is as follows:

• A user can always administer their own account.
• A site administrator is not allowed to administrate another administrator's user account.
• Otherwise, a site administrator is allowed to administer any user account.
• If a manager is trying to administer another user account, they must be enrolled as a manager in every journal the user is enrolled in.
• If none of the above rules apply, management of the other account is not allowed.

In general this has been an acceptable compromise, but in some cases it's applied too broadly. For example:

• Editing a user to change their roles in the current journal
• Removing a user from a journal

A journal manager should always be able to perform these tasks on users enrolled in their journal, regardless of their other enrollments.

[touhidurabir]

@asmecher please review the PRs
pkp-lib --> #8283
ojs --> pkp/ojs#3550

[Devika008]

So this is what I propose. The user information which we want to keep uneditable, we will playback them on the grey patch to clearly distinguish what the editor can change and what they cannot. I believe a mechanism like this can be extensively used to playback all sorts of information in different journeys and can create a great mental model for the user and reduce the load of remembering and figuring things out through clicks.

The form fields here is what is usually easier to read and Ive sued as placeholders but please feel free to use the ones that are already there as that is something we can tackle later.

The current add more details button can be used instead of the one I have put here however, this is the placement I propose.

[alexxxmendonca]

I really like this approach, @Devika008

[touhidurabir]

@Devika008 thanks for providing the UX guidance and I also like it very much . I have followed your UX guidance but with our current design, it's not possible to fully implement the UI design.

@asmecher Updated PRs

pkp-lib --> #8283
ojs --> pkp/ojs#3550

So basically we will present few of user basic details as read only and only allow user group to edit/update . I think these much match with our current requirement .

[asmecher]

it's not possible to fully implement the UI design.

@Devika008, just for context on this: a portion of OJS uses the current "UI library" design library that Nate developed a few years back, and is e.g. backed by the API. This represents the current "modern" OJS UI. Other parts still use older toolsets, and would need to be adapted to the modern design library before it's worth investing UI effort on them. This is one of the areas that still uses the older toolset.

[asmecher]

Closing! Thanks, @touhidurabir, this will make users of larger sites very happy.

[touhidurabir]

@asmecher patch PRs to review
pkp-lib --> #8396
ojs --> pkp/ojs#3600

[asmecher]

Merged, thanks!