Support more detailed user role permissions/capabilities

[jmacgreg]

Adapt something like Wordpress' "capabilities" feature for OJS' roles: journal managers can map specific capabilities (such as allowing image uploads; allowing editorial decisions vs. recommendations; allowing participant management; etc.). Some possible capabilities (please add/modify):

General user stuff:

• HTML/TinyMCE access
• upload image via TinyMCE
• maybe some sort of advanced access control (for pasting javascript, etc.?)

Submission stuff:

• add participants to submission
• remove participants from submission
• make editorial recommendation on stage
• make editorial action/decision on stage
• access all submissions
• access all discussions
• access issue management

Journal management stuff:

• access settings
• access administration
• access stats & reports
• access import/export
• access user management

Note: I'm retiring #2128 in favour of this issue. I also think that editorial "recommendations" could be made via the discussions function, so maybe all we need to do is allow conditional access to decision stuff.

[asmecher]

See also #2540.

I favour "less is more" -- making this too fine-grained would be a mistake, if we can focus on real user requirements and make sensible choices rather than offering too many permutations. (Semi-facetious) example: "[ ] Users should be able to upload images via TinyMCE" is a bad idea -- we would be better served finding out why people want to upload images/files, then catering to that. (Example: there's no way to include images in static pages. Suggestion: Add an image upload tool to that control, for managers only.)

[NateWr]

I'll just outline how this works in WordPress from my experience there. I'm not wedded to the idea but I have seen the benefits of having a system that's pretty flexible.

I don't think we'd need to build a complex UI for managing permissions right off the bat. I see the value more in having a hooked architecture that allows journals to customise their permissions sets with a little bit of code -- primarily for use by our better-resourced adopters and PKP Services.

Psuedo-code:

// Define role permissions
$rolePermissions = array(
	ADMIN_ROLE_ID => array(
		'manageUsers',
		'readOthersSubmissions',
		'viewSubmissionParticipants',
		'addSubmissionParticipants',
		'deleteSubmissionParticipants',
	),
	CUSTOM_ROLE_ID => array(
		...
	),
);

// Allow third-party manipulation of role permissions
HookRegistry::call('RolePermissions', &$rolePermissions);

// Check permissions
if (UserService::currentUserCan('manageUsers')) {
	// ...display user grid...
}

// Check permissions against a specific object
if (UserService::currentUserCan('viewSubmissionParticipants', $submissionId)) {
	// ...display participants grid...
}

Pros (as I see it):

• Centralised location for defining permissions
• Very flexible for third-party customisations
• Descriptive permissions makes code a bit more readable
• Decouples auth from pre-defined roles

Cons:

• Introduces layer of abstraction
• Not as easy to grasp as role system
• Requires refactor work

I'm of the opinion that this is something that could be introduced bit-by-bit over time, rather than trying to refactor every role check all at once.

[asmecher]

There are a few existing systems that this might need to interact with:

• Auth framework (obviously)
  • One approach I was thinking about for allowing external systems to alter auth policies is to optionally assign symbolic names to policies. That way a plugin could e.g. look for a policy called ENSURE_THIS_OR_THAT and augment/alter it. (Currently there would need to be hard-coded knowledge about the policy structure and painfully spaghetti-ish traversal/modification.)
• Helper classes. See e.g. QueriesAccessHelper.inc.php -- this is potentially a close mapping to the proposed structure here.
• ...?

[NateWr]

I like that QueriesAccessHelper.inc.php. Is that a pattern new to the Queries or is it in use elsewhere? Maybe I've just been looking at the wrong thing in the past, but this seems a lot easier to interpret then other authorization code I've looked at.

For instance, I can search getCanOpenClose in the codebase and immediately pull up how it's used and the code which controls the permission.

How would you feel about centralizing some of it in a service class of some kind? I'm thinking something like:

Authorization::currentUserCan(QUERIES_OPEN_CLOSE, $queryId);

I think that's pretty close to the approach you described in bullet point 1.1. But even if Authorization::currentUserCan(QUERIES_OPEN_CLOSE) just maps to the query access helper under-the-hood, I think it will make the API a little bit easier to use.

I think I've been a bit confused in the past because it seems like every UI handler kind of as it's own authorization tools. That's probably not true, but I've never quite been able to pick apart the underlying structure. Exposing it in a singular API access point like this might make it easier to work with.

[asmecher]

In a lot of cases we don't have the luxury of coding up a class like QueriesAccessHelper to dole out arbitrary answers to access inquiries because authorization questions have bigger coding consequences. (The reviewer and author views are coded completely separate of the editorial views, for example, so building up a policy class that answers "yes" or "no" to access questions related to those won't behave well if the coding implications don't match the policy questions.)

In the case of discussions/queries, it's the same view for all users, so we can set policies in a more unified way.

This approach isn't broadly used, but I do like it. I'm not sure about centralizing them into a single class -- currently I like having that class "live" alongside the various grid classes etc. But we can revisit that if we get a few more bits and pieces that look similarly, or perhaps consider a class hierarchy with some helper tools e.g. to support a capabilities toolset.

[marcbria]

Don't know if is the right place to post... but I got petitions from different publication services to lock access to certain areas (ie: plugin management, certain plugin usage, journal configuration) to journal managers.

There are a lot of situations where a publishing service would like to lock the access of journal managers to an specific plugin settings/usage (for example: CrossRef, User Import, googleAnalytics, orcid...) to avoid journals harm their own publications and right now there is no way to do this.

When I say "locking" I mean "not authorized to reach" but in certain scenarios would be nice to have a "see but unable to modify" feature (for instance in the journal settings).

[NateWr]

Related issues: #5504 and #7417