Repository: learningequality/kolibri

Issue:
As superuser, users + collections belonging to other Facilities are appearing in facility management workflows
By default, the device owner (i.e. the first superuser) is created and made a Member of the Facility (Facility 1) made during the Setup Wizard.

However, if a second Facility (Facility 2) is created the device owner will see the Facility 2 Users and Collections/Classrooms in various Facility Management and Coach workflows, even though the device owner can only log into Facility 1.

If the device owner tries to modify these Facility 2 users or collections, after logging in under Facility 1, the app will throw a 40x error. (Would probably happen even if SU were logged in under Facility 2, were that possible)

This only happens to superusers; This does not happen for non-SU Admins attached to a single facility. They will see and have permissions to Users/Collections scoped to their facility.

Here, users "jb2" and "jb3" are not part of the Facility I logged into:

![screen shot 2018-04-03 at 12 17 08 pm](https://user-images.githubusercontent.com/10248067/38270666-f5e81418-3738-11e8-8b29-0bd5b594549c.png)





Discussion:
I was thinking about tackling this, but this might require more thought on how it should be designed. 
1. Do we want a superuser only to be able to see the users associated with the facility that they are a part of? If so, then maybe we only need to change the backend permissions.
2. Or do we want a superuser who can be able to scroll through the different facilities on the device and see users associated with each facility? Then maybe we start doing filtered requests which passes the facility ID.

This also relates to the problem of a user downloading all content logs. Depending on the permissions of the user, when would we want them to be able to download logs for all facilities, as opposed to by facility?
@jonboiser @jamalex 
cc: @rtibbles 
>Or do we want a superuser who can be able to scroll through the different facilities on the device and see users associated with each facility? Then maybe we start doing filtered requests which passes the facility ID.

Eventually, this will be what we want, so having a filter (option 2) would be best. Especially since it's not a permissions issue (they're superusers!) but rather a relevance/scoping issue.
Currently, even super users need to log in to a single facility at a time. So another shorter-term way of tackling this would be to save and get the "current facility" from the user's session object, rather than updating all the APIs with a new facility filter.
Only 9 instances of this in the whole code base, so not too hard to change.
(for facility users, will also need to add for classrooms too - but probably not groups). 

Resolving patch:
diff --git a/kolibri/auth/api.py b/kolibri/auth/api.py
--- a/kolibri/auth/api.py
+++ b/kolibri/auth/api.py
@@ -247,6 +247,7 @@ class PublicFacilityViewSet(viewsets.ReadOnlyModelViewSet):
 class ClassroomFilter(FilterSet):
 
     role = CharFilter(method="filter_has_role_for")
+    parent = ModelChoiceFilter(queryset=Facility.objects.all())
 
     def filter_has_role_for(self, queryset, name, value):
         requesting_user = get_user(self.request)
@@ -266,7 +267,7 @@ def filter_has_role_for(self, queryset, name, value):
 
     class Meta:
         model = Classroom
-        fields = ['role', ]
+        fields = ['role', 'parent', ]
 
 
 class ClassroomViewSet(viewsets.ModelViewSet):


Test patch: