Convert GP permissions to WP roles about glotpress

[javorszky]

Working on this :)

[bradt]

@javorszky How far along are you? Can you open a PR so we can see it?

[javorszky]

Okay, this is a LOT harder than I initially expected. I'd like a bit of help with this with regards to the internal workings of it. Here are my thoughts so far:

1. Using WordPress roles is not a good idea.

The current permission system resembles capability-based checks. If we use Roles, we essentially lock people in to that specific role. Because in WP a user can only have one role at a time (imposed by the User profile edit screen, not because of the WP_User object), once a Validator is designated a Validator, that person cannot be merely a translator on another locale. For example: Bob speaks three languages. Bob is a validator on the Spanish locale, but only a translator on the Italian one. If we're using roles, this won't be possible. (And when I say "won't be possible", I mean implementing it anyways is way too much of a hassle).

2. If we're to replace the current permission system with user_can() and current_user_can() implementations, a LOT of the code needs changing.

The easier bit is assigning capabilities on registering / validator approval, and when checking against those when the user makes a request.

The harder bit is getting the list of users who have special permissions by project. This is one bit where I'm stuck: short of looping over all users and checking for permissions individually, or making full text regex queries against the _usermeta table, the only other way to store these permissions os to store the data in two places, keyed by the project id. Which is the current implementation.

I've been mulling over what and how to do with these, but I could use some help.

I'll have a branch up shortly after I cleaned up my code (removed debug-related stops, etc).

[toolstack]

I think roles are the way to go, but perhaps a little differently than above.

We would create one role per project, locale & slug (so if had a project "test", with an Aribic "ar" locale and a slug of "default", the role would be something like "GP_test_ar_default" and assign it to a user when we add the user via the permissions page.

The role would have one capability "GP_test_ar_default" which could be used in user_can() to get write access to the locale.

A user would then be assigned as many roles as required to be a vaidator on whatever projects/locales/slugs they need.

This makes it easy to use user_can() to check permissions but still be able to get a list of users with the roles.

[javorszky]

Hm, checking for user_can is the easy part.

If we assign user roles, we need to replace whatever role WordPress gave the user, so if it was admin, we need to fetch all caps of an admin, and migrate it over to their new role. As soon as a user clicks "Update" on their profile page, their latter role is going to be wiped which is a limitation with roles.

This also doesn't solve query by role. Say I have a 1000 users, and I want to get all users who have the permission to approve strings on test project in arabic.

[toolstack]

We don't have to replace the role the user has, we can add roles. A user can have multiple roles at the same time.

The WP interface doesn't let you do this, but we can use the permissions page in GP to do the work for us.

If the admin updates the user role in WP, it doesn't wipe out any additional roles the user has, it just removes the role they had and adds the new one.

[ocean90]

Funny enough, that's the same issue we currently have on translate.w.org. The latest ticket is https://meta.trac.wordpress.org/ticket/1240 and a related discussion is https://wordpress.slack.com/archives/meta-i18n/p1443790349000116.

A user can have multiple roles, you just have to do it right. ;)
The plugin we're using is on meta.trac and one of the important functions is restore_translation_editor_role which is hooked into set_user_role.

[javorszky]

Heh... I personally think that in this instance the way GlotPress is handling permissions is the more correct way of doing things. To the point where I feel WordPress's handling of user permissions should be extracted to its own table.

I doubt GlotPress is the only plugin / functionality that faces this exact same issue.

@toolstack: an admin saving the profile page of a user with multiple roles WILL wipe all but the first roles. Tested this by having a user, adding a role to it, making sure it comes up in the user object, then clicking "Update" on the user's profile with the admin, and displaying the user object again.

[toolstack]

As @ocean90 said, we can hook the set_user_role and make sure that doesn't happen.

Though I have to admit, I kind of agree with you that the more you look at what it takes to implement the WP permissions system in to GP, the worse it looks.

We could just avoid the whole issue by leaving the GP permissions as they are...

[javorszky]

We could just avoid the whole issue by leaving the GP permissions as they are...

At this point I am leaning towards this. There are a number of really hard problems to solve. The WP_User and the GP_Permissions are linked together by GP_Permission's user_id column anyways.

[A5hleyRich]

My gripe with the current implementation is that the data isn't normalised, but, if it's going to be too much work I'm happy to leave it as is.

Maybe changing the permissions system is too ambitious for the 1.0 milestone? If it is something we want to implement, can we not do it a later date?

[toolstack]

If we're going to do it, now's the time. Don't want to have to write conversion routines later if we don't have to.

Having said that, the WP Roles/Capabilities model isn't the best fit for GP.

Could we normalize the current model and resolve any other definicenes we think it might have, would that work just as well if not better for GPs requirements?

[rmccue]

The role would have one capability "GP_test_ar_default" which could be used in user_can() to get write access to the locale.

A user would then be assigned as many roles as required to be a vaidator on whatever projects/locales/slugs they need.

I don't think this is a great route. Meta-caps are the best way to handle this IMO, so we'd have roles like gp_validator, gp_administrator, etc.

gp_validator would give you the capability gp_validate_languages or something (gp_administrator would give you gp_validate_all_languages), which you'd check via current_user_can( 'gp_validate_language', $project ); this is similar to edit_posts/edit_others_posts with the 'edit_post', $id meta-cap.

We don't want to shoehorn this all into singular/dynamic roles and capabilities, if you try that, you'll run into the classic (HERE BE DRAGONS 🐉) issues. Is there any reason we can't use meta caps?

[toolstack]

@rmccue there are a few issues with that, using and assigning a single role to a user for gp_validator or gp_administrator means that user could only be a gp user and not a WP user as well (or we'd have to creat a gp_validator_[wp role] for each role and let's not even talk about plugins that might add roles) . For example if you wanted to assign two users as gp_administrators but give one subscriber permissions and the other editor permissions, that would be a problem.

The other issue, as @javorszky mentioned is you cannot get a list of users by their capabilities (without some nasty hacks at least). As we have to be able to assign capabilities per project/locale/slug that means we need ot have one capability per project/locale/slug combination and it makes sense to be able to get a list of users who can edit a given project/locale/slug, the only way i know of to do it in WP is by using Roles, not meta-caps.

The 'HERE BE DRAGONS' problem may very well be why using WP's Role/Caps system isn't a good idea and it might be better to stick to GP's permissions system.

[rmccue]

using and assigning a single role to a user

I'd definitely do this with multiple roles, which are definitely possible as @ocean90; I've not found this terribly hard in the past.

it makes sense to be able to get a list of users who can edit a given project/locale/slug

Do we actually need this? I suspect YAGNI.

[toolstack]

it makes sense to be able to get a list of users who can edit a given project/locale/slug

Do we actually need this? I suspect YAGNI.

I'd say ever admin is going to need to be able to see who has access to a given translation, so yes, it's definitely a need. That would be like saying in WP you don't need to see who's an editor or a subscriber or an author.

[javorszky]

Do we actually need this? I suspect YAGNI.

Email from customer: "Hey, when is plugin X going to be available in language Y?"

You go to the backend, all translations are done for language Y. They need to be approved.

You open up the email client, and write an email kindly asking the validator of the language to please take a look. Now, who should you make the email out to?

That's one example I'd find it handy to know.

[rmccue]

I'd say ever admin is going to need to be able to see who has access to a given translation, so yes, it's definitely a need. That would be like saying in WP you don't need to see who's an editor or a subscriber or an author.

In WP, you can't see who can edit specific posts, but you can infer it from what you know. The post author can probably edit their own post, plus editors and above, but that's a mental process. That can also change if the post is then published. The same applies here.

Also the approach I mentioned above splits the data:

• The user has the capability gp_validate_languages, but that does nothing by itself.
• The language has a list of users added to it. (These users have to have the gp_validate_languages cap to be added.)

The meta cap 'gp_validate_language', $language combines the two pieces of data, which is the key. Rather than storing the full capability, we're essentially splitting it. This means we're kind of not storing the full capability on the user, if that helps.

Querying then looks like this:

• Who can validate $language? $language->get_validators()
• Can $user validate $language? $user->user_can( 'gp_validate_language', $language )
• What languages can $user validate? Get languages where $user->ID IN option_value

Actions look like this:

• Give $user ability to validate $language: $user->add_cap( 'gp_validate_languages' ) (or role) + $language->add_validator( $user )
• Revoke $user's ability to validate any languages: $user->remove_cap( 'gp_validate_languages' )

[javorszky]

The language has a list of users added to it. (These users have to have the gp_validate_languages cap to be added.)

The current database setup does not allow for this, unless we put this into the gp_meta table.

From my understanding, the point of this issue is to eliminate the need for the gp_permission table, but using the above approach we're moving some of the data into the WP tables, and some into a table that's currently not used, and by doing that we're not reducing complexity, but increasing it.

Comparison with the WP permissions is also not great, because the roles (subscriber, contributor, editor, admin) are hierarchical. Every role can do the things on their level and below. This is not the case when it comes to GP. Not all validators should be able to validate all languages across all projects. Seeing that a user has gp_validator role you won't actually get closer to knowing which project / locale that person's responsible for. On the other hand, looking at the user stored against the project / language, you'll know precisely who that person is. Which the current implementation provides.

[rmccue]

(Discussing in Slack.)

[toolstack]

As per the discussion in slack, moved this to an enhancement instead of a bug and assigned to @ocean90.

[toolstack]

I've updated by POC branch 19-toolstack-poc-capabilities to support listing and deleting capabilities.

[ocean90]

As per todays meeting we're closing this as a wontfix.