Repository: learningequality/kolibri

Issue:
remove translations for user kinds on backend
### Observed behavior

In role kinds we use the string "Classroom Assignable Coach": https://github.com/learningequality/kolibri/blob/develop/kolibri/auth/constants/role_kinds.py#L15

This string is not something that should be user-facing

### Expected behavior

implementation details hidden from user

### User-facing consequences

confusing, inconsistent terminology


### Context

https://crowdin.com/translate/kolibri/498/en-es#37506




Discussion:
What does the crowdin comment say? I don't think 'classroom assignable coach' appears anywhere on the UI.

In the server-side code, the 'assignable' piece is important because it signals that the user with that role can be assigned (or not) to a classroom, but is not attached to any Classroom by default.
![image](https://user-images.githubusercontent.com/2367265/40809174-63c0edca-64de-11e8-8a28-01222ef1b6e7.png)

My understanding was that "class coach" was equivalent? If not I don't quite understand what the roles are...

I'm not sure. I think 'class coach' is probably higher-level concept meaning something like

"Class Coach for Class A = User with 'classroom assignable coach' Role in Facility + 
 'coach 'Role in Classroom A"

But a User with only the 'classroom assignable coach' role but no Memberships is ???.

Maybe if we had put in a dash---classroom-assignable coach---the phrase would have been easier to interpret.


~Hmm... I don't actually see the `ASSIGNABLE_COACH` role used anywhere in the code.~ [edit: I do see it used on the front-end - just not on the backend]

My understanding was that...

![types](https://user-images.githubusercontent.com/2367265/40857294-9375add8-658f-11e8-8b52-bdea266b8360.png)




A classroom assignable coach is a role for a user who can be assigned to a coach role. It is *not* a class coach, because they are not assigned to coach a class.
If I understand correctly, any user role can be assigned to coach a class as a `class coach`, right? So why is this `classroom assignable coach` even a role for itself? 😕 
 
I included the [link towards the docs](https://kolibri.readthedocs.io/en/latest/manage.html#coach-type) where the distinction `facility coach` vs. `class coach` is explained, to further the context to translators. If the `class coach` is not the correct term to be used, we need to amend that. 
This role exists because it simplifies the UI flow. At the time of account creation, the admin has the option of making a coach user either a 'facility coach' or a 'class coach' (in the frontend), in the backend this maps either to having the role 'coach' wrt to the facility, or having the 'class assignable coach' role that is not associated with any particular class.

This was done in order to simplify the UI, so as not to have to pop up the list of classes (or potentially have to allow the creation of a new class for this coach), but to still allow them to be demarcated as a 'class coach', rather than just a learner or a facility coach.
Naming things is [hard](http://hilton.org.uk/blog/why-naming-things-is-hard), but I feel like we might be making this harder than it needs to be. Or, I could be completely misunderstanding still...

For sake of argument, let's say that we forget previous names and definitions, and use these instead:

* **Class coach:** a coach who (by default) has no access to classes. Can be assigned to a class to grant access
* **Facility coach:** a coach who has access to all classes. Can be assigned to a class for administrative/book-keeping purposes

If we were to assert that these are the definitions, we could make the user-facing mental model and implementation model the same with some simple renaming e.g. https://github.com/learningequality/kolibri/pull/3745/files



I think me and @ralphiee22 talked about using better names for these roles like in the PR when implementing this, but weren't sure what the implications would be for backwards compatibility and syncing.
I think the main issue is that in the backend we are using a role based permission model to determine what data particular users have access to.

These 'roles' are with respect to particular collections (facilities, classrooms, and groups).

That's why in the backend there is no distinction between a 'facility coach' and a 'class coach' because that is not defined by the kind of the role object, it is defined by the combination of the kind of the role object and the collection that the role object targets.

> * Class coach: a coach who (by default) has no access to classes. Can be assigned to a class to grant access
> * Facility coach: a coach who has access to all classes. Can be assigned to a class for administrative/book-keeping purposes

I think it is perfectly reasonable to describe these kinds of users in the frontend interface, but aside from the backwards compatibility issues that this would cause, it also misses that this information is determined by the combination of the 'kind' of permission they have and the collection that they have this permission for.

Add to this the further complication of the Device Owner user kind being defined by a completely different permission granting system, and we will always need a translation layer between the backend data and the way we present it to the frontend.
Grateful to all for insightful details I was previously very much unaware of! 👍 

Getting back to the Crowdin issue that sparked this exchange, are we envisioning the future deeper role "multiplication" that would render the current naming as simple `Class coach` problematic? Granted this is not high risk, as the `Classroom assignable coach` does not appear in UI, but I would like to simplify the work for the translators, and not present them the full `kind-of-permission-for-specific-collection` reasoning in order to understand the full meaning of "assignable".

How about this distinction?

 * **Class coach**: a user who, when assigned the role, by default has no coach permissions, **until** they are assigned to coach a specific class
 * **Facility coach**: a user who by default has access and coach permissions for all the classes in the facility

  
I think the simple resolution of the specific crowdin issue is to remove these strings from what we translate, as they do not need to be translated.
(precisely because they are dev facing backend constants)
Leave it to you to take 30 seconds to solve the issue I was formulating a solution for much, much longer... 🙂 

Jokes aside, I'd be perfectly fine with this!
It wasn't clear to me why they are translated on the backend?
Updated description and title.

I find the naming confusing ("classroom assignable coach" doesn't sound like a role that connects a user with a collection) but if we can decouple this from the end-user then that's good enough for me


Resolving patch:
diff --git a/kolibri/auth/constants/role_kinds.py b/kolibri/auth/constants/role_kinds.py
--- a/kolibri/auth/constants/role_kinds.py
+++ b/kolibri/auth/constants/role_kinds.py
@@ -3,14 +3,12 @@
 """
 from __future__ import unicode_literals
 
-from django.utils.translation import ugettext_lazy as _
-
 ADMIN = "admin"
 COACH = "coach"
 ASSIGNABLE_COACH = "classroom assignable coach"
 
 choices = (
-    (ADMIN, _("Admin")),
-    (COACH, _("Coach")),
-    (ASSIGNABLE_COACH, _("Classroom Assignable Coach")),
+    (ADMIN, "Admin"),
+    (COACH, "Coach"),
+    (ASSIGNABLE_COACH, "Classroom Assignable Coach"),
 )


Test patch: