Grant implicit Manager access to Adminstrators

[asmecher]

...as we did for OJS 2.4. This will help e.g. our hosting environment, where we want to be admins but not show up actively in the system. Otherwise we need to self-register as Managers, which implies editorial presence and will see us notified in situations where it's not appropriate.

[bozana]

@asmecher when a press is created, admin gets the Press Manager role/group, s.
https://github.com/pkp/omp/blob/master/controllers/grid/admin/press/form/PressSiteSettingsForm.inc.php#L91
https://github.com/pkp/pkp-lib/blob/master/controllers/grid/admin/context/form/ContextSiteSettingsForm.inc.php#l102-L115

Do you maybe think that admin should also get the other managerial roles/groups i.e. Press Editor and Production Editor?

[asmecher]

I'm nervous about making assumptions about roles and user groups, because these can be customized and if there are several suitable roles we'll have to pick one.

If we made Manager access implicit for Admins, we would be able to remove the current user group assignment. That would decrease ambiguity but would probably lead users to continue operating as Administrator when they actually did want to be a Manager (e.g. meaning that they would be able to self-assign in the participants grid). So I'd suggest we remove the current automatic role assignment, and consider leading the user through self-assigning roles or user groups as part of the setup wizard.

[bozana]

Hi @asmecher, 100 years later... :-) I do understand to remove the automatically assignment of a journal/press manager role to the admin user. But, where and how to allow/enable the role self-assignment for the admin? At the end of the settings wizard there is the users management page. Should there be just an info for the admin, that he/she can edit his/her user and assign himself/herself further roles? Or should there be, for example, one more tab "User Roles" where he/she would do that? Or something/somehow else? THANKS!!!

[asmecher]

I suggest leaving the automatic assignment as it currently stands, for informational reasons (normally it's the way people want things). But we also need to adjust the policy set so that Site Administrators implicitly have access to anything the Editor does, without needing a role assignment. That'll be valuable e.g. for institutional hosts to explore the installation, without needing to assign a role that might end up in an informational spot by accident.

[bozana]

Hmmm... I am not sure if I understand it correctly :-\
So, we will leave the automatic manager assignment to the admin user, as till now, right?
As far as I could see, the admin user is able to access all workflow stages, but I surely don't have a complete overview :-\ The admin user can probably access all this because it automatically has the manger role -- manager role seems to be considered 'everywhere', in 'every' policy? So now I am not sure what should we do :-\ Shall we do the same for the admin role, as for the manager role? Or what do you mean?

[asmecher]

For most installations, it's OK for the admin to be assigned as a manager. That's currently working well. However -- in cases like our own hosting operations, we'll want to have a site admin role as well, but not to require a manager role to be explicitly assigned. For example, consider two site admin accounts: "clientadmin" and "hostadmin" -- one that the client uses to create/delete journals etc., which has both site admin and manager roles (the current behavior). The hostadmin user would ONLY have a site admin assignment, and would be used by the host provider to provide tech support. This second account would not have manager role assignments, but should be able to access everything anyway.

[bozana]

Aaaaaaaaaa... I was thinking only on one admin. So would the solution be to consider the admin role similar the manager role is considered in those access and workflow stages policies?

[bozana]

Hmmm... I think I am a little bit lost with this problem :-(
The ROLE_ID_MANAGER is considered everywhere. So it seems the ROLE_ID_SITE_ADMIN should be in the same/similar way considered everywhere :-P
I don't see a good possibility to appropriately assign ROLE_ID_MANAGER to the admin, at the appropriate place/call in the system, depending where we are/what to do.
I think, that it always is looked/checked if the roleId is ROLE_ID_MANAGER and not something like < ROLE_ID_MANAGER :-)
We cannot merge those two roles i.e. we do need them both, I believe.
I am also not sure if there is one or at least a few places to easily grant all rights to the admin, e.g. PKPHandler::authorize, and if this would be the right solution.
:-(

[asmecher]

Maybe we could consider some other approaches that would suit hosting providers... The "log in as" feature comes to mind. That would permit a Site Admin to easily get into press/journal content without needing to have a Manager role. Could you double-check that Site Admins always have access to that feature? I don't recall OTOH.

[asmecher]

Deferring to OJS 3.0.

[bozana]

@asmecher, I see the issue is deferred, but just to write what I've figured out: if an user is only admin and not also manager, the user does not have access to the "log in as" feature. It also doesn't have access to the "Settings wizard" feature in the presses grid. Thus, maybe to have "User Management" feature also somewhere else (e.g. instead of "Setting wizard" feature), granted for the admin role, for this case?

[asmecher]

Yes, I think that's a perfect solution.

[bozana]

@asmecher, one more question: I see that in the new version there is extra "Users & Roles" menu item for journal managers in the left sidebar navigation. Should I thus enable this menu item to appear also for the users having just admin (and not also journal manager) roles, or would it be better to add "Users" row action to the admin context grid (Administration > Hosted Journals)?

[asmecher]

Hmm, I think it would probably make sense to turn the Administration menu into a container for a couple of sub-elements:

• Administration
  • Hosted Journals
  • Users
  • Administrative Functions

...with the inner three presented as tabs in a tabset, for consistency with the manager's interface.

However, I'm not sure it'll be easy to give the Administrator one of the features they require in the Users area, which is the ability to grant roles to users. That interface is currently designed to operate within a particular context.

[bozana]

Hmmm... Yes, maybe it would be then better to have it as a row action for each journal listed in the context grid (hosted journals)?

[bozana]

Hmmm... I've just seen that administration page is always in a context, thus eventually the Users tab could work (and be for that context only). However, because all the journals, are listed in the context grid, maybe it is good to have the journal/context functions there -- they are meant to be just for a journal/context.

[bozana]

@asmecher, I've also just realized, that the whole users grid is designed to work in a context, thus a new users grid would be needed if we want to enable it to function without a context: listing all users from each context, with a possibility to filter by a context, and considering all roles from each context (because each context could also have defined different roles).
I am somehow not sure, if this is so useful and clear, because usually admins do work with users in a context, but maybe I am just used to it, how it was till now.
What do you think? Is this context comprehensive user management a required/wished/good to have feature? Or is it sufficient and more clear to be in/choose the appropriate context in order to manage its users?
This would be like a new feature for admins vs. enabling a journal manager feature also for admins.
Actually, why would such admins need to manage users -- the only feature they need is "Log In As" in order to help -- the user management is a context task.
For admins that have journal manager rights, the "Users & Roles" navigation item is displayed only if they are in a context. Maybe to solve this in a similar way for the admins that don't have JM role?
Also for the site wide languages: they have to be managed on their own, in order to define the set of all languages, but actually you have to go to a context to define them there too. Differently to the languages, the users are not necessarily needed to be managed side wide, because they always exists (i.e. have a function/role) within a context. Thus, having a side wide user management for admins would only enable a view on all users of the installation (which could also be unclear), but they will have to be created in and assigned to a context.
Also, maybe with the time we will realized that maybe also other context (management) functions/features would be good to be enabled for admins, and then we will have to write them differently too, for them to be side wide too?
This is just a brain storming. It could look like I am not for the side wide user management, but this is not so i.e. doesn't matter -- just to consider everything possible i.e. to be sure we do the right thing especially if we decide to do that bigger change :-)
If we decide to write a new feature for admins I agree that we could solve it as a tab in a administration area, as you suggested.
If we decide to enable the current user management feature for admins, maybe we can ask Nate how he would solve that, where to position it, etc.?

[bozana]

@asmecher, this is because the whole Users&Roles management is currently context specific. S. this comment above: #440 (comment). If we would like to have it context insensitive a new grids / Users&Roles management functionality should be implemented... It seems to be what we want, right?

[asmecher]

Yes, having those tools behave in a context-insensitive manner would be best. Another option (though not as good IMO) would be to add a row action on the "Hosted Journals" grid entries allowing the admin to get into a journal-specific admin area -- but I think that would be unnecessarily confusing.

[bozana]

PR:
pkp-lib master: #2810

[bozana]

@asmecher, there was already the action Administration > Hosted Journals > Settings wizard > Users. It just needed the permission for the admin user. Thus the PR above can however be merged, I think. Right?
Then, is a new Users grid, that is context-insensitive, needed? -- just to be 100% sure :-)

[NateWr]

If creating a new grid, consider implementing a ListPanel instead. :) That will push forward the /_users API endpoint and the UI code refactor. We could talk through what would be required if you want. Or just go ahead with the grid if you're aiming to get this in for 3.1.

[bozana]

OK, I would gladly do that -- I am just not sure if I would manage it for 3.1. So maybe we should make a decision if such a grid is needed for 3.1...

[asmecher]

We do need an expedient fix for the 3.1 release -- a ListPanel would be a nice addition, but I suspect it's out of reach for 3.1.

[bozana]

@asmecher and @NateWr, I would have some conceptual i.e. UI questions: what information should the new site wide users grid contain? -- The same columns as now or additionally also journals/contexts the user belongs to? Or maybe to have this information only in the "Edit User" form?
On the "Edit User" form we have to display the "User Roles" grid per journal/context i.e. to somehow integrate the journal/context information into that grid. @NateWr, any idea how would it be best to have that in the UI?
Also, there should probably be a search after/filter by journal/context for the new grid.
What about roles grid -- does it also have to be implemented for admins i.e. side wide?
Hmmm... I will have to see ho to best implement all this, then I will maybe have additional questions... but that's it for now :-) THANKS!!!

[NateWr]

What's the use case this grid is fulfilling? My comments below are based on the presumption that this grid is catering to a specific need and won't be frequently used.

what information should the new site wide users grid contain?

I'd say mimic the existing users grid. No need to add anything. A list of contexts could get very long on large installations.

On the "Edit User" form we have to display the "User Roles" grid per journal/context i.e. to somehow integrate the journal/context information into that grid.

Hmm, yeah that could get very messy in installations with lots of journals. Is it necessary? Would it be possible to just exclude this part, and require someone to go to a context-specific user grid to set the roles? Or would that undermine the use-case we're trying to serve?

If it can't be excluded, I'd be tempted to just ditch the ListBuilder implementation and instead list each role in each journal, with checkboxes selected for each one assigned. The same could be done with the context-specific form. This might be more intuitive than the whole ListBuilder apparatus.

I'll defer to Alec for the others.

[bozana]

For simplicity reason maybe to leave the user grid columns as they are for now. -- The same grid will be used in journal/press context as well as in the site context.
Concerning the filter options for the site wide context: maybe to first just provide the journals/presses list as a filter (and no user groups/roles list). When a journal/press is selected and the button "Search" pressed i.e. the users filtered by the journal/press, then provide the user groups/roles list as the filter option.

[bozana]

@NateWr, thanks! My page was not reloaded when I wrote my last comment, so I first now see your comment, but no conflicts however... :-)

[asmecher]

Going back to use cases:

• It's possible for an admin to get dumped into the site-wide administration area, and have no idea how to access journal-specific administration areas. Admins get confused and post on the forum, and then I answer their questions.
• Site admins want a quick way to get in and solve user problems, most commonly to reset passwords, grant roles, etc.
• Site admins (who may only be service providers) will want a quick way to "Log In As" other users (commonly Journal Managers) to go in and investigate problems they've been asked about.

[NateWr]

It's possible for an admin to get dumped into the site-wide administration area, and have no idea how to access journal-specific administration areas. Admins get confused and post on the forum, and then I answer their questions.

This sounds like the primary problem. What if the site-wide admin nav menu just included a list of every context, with links to Users and Settings for each one? Would that solve the problem or would admins not know which context to find a user in?

[asmecher]

What if the site-wide admin nav menu just included a list of every context, with links to Users and Settings for each one?

That's pretty much what I was suggesting here, and it's the most expedient fix. Longer term, I think it makes sense to make user management a proper part of the site administration interface, especially because user accounts are site-wide and that design choice would be made more apparent to users this way.

[NateWr]

Ok, yeah, I suppose whatever works for 3.1 is fine. Good to keep in mind for when we get to refactor the user grids into ListPanels.

[bozana]

Do I understand it correctly, that it would be enough for 3.1 to have an action link in the hosted journals grid? Adapting the current Users Grid to be usable site-wide is more work but would be possible for 3.1 as well. What would you suggest I should do? :-) -- Sorry, I am sometimes so bad in making decisions :-\

[asmecher]

For now, let's just stick with the new new row action. With more time, this could be adapted to a ListPanel -- no sense investing a lot of time in grid-based functionality for now.

[bozana]

PRs:
pkp-lib master: #2851

[bozana]

@asmecher, could you take a look at this PR: #2851 ? Thanks!!!

[asmecher]

Merged, thanks!

[bozana]

A new issue for users ListPanel opened, here everything merged, thus closing...