Content visibility group: IFRC + NS

[tovari]

We need to introduce a new content visibility level besides the currently available Public, RCRC Movement and IFRC Secretariat. The new group will include IFRC users and specific NS (one or more NSs - e.g.: IFRC + AUS RC + Hungarian RC). The assigned NS depends on the content type:

• FR, Emergency - NS of the country
• PER - NS of the country
• 3W - NS of the host and donor countries
• DREF request - NS of the requester country

NS visibility would be assigned automatically when IFRC + NS visibility is selected, no additional UI component required.

Visibility label: "National Society and IFRC"

[nanometrenat]

Hi @tovari how will you define which users fall into that particular NS? A business process needs to be set up to ensure that users are assigned the NS(s) that you want them to have. Things you'll need to consider here include (but aren't limited to):

1. currently not all NS users have a structured NS assigned
2. currently there is no process to maintain user properties - e.g. when a user changes NS affiliation - and no authorisation step by the receiving NS
3. under the proposal above, how do delegates count? e.g. if a New Zealand Red Cross delegate is on mission to work with Fiji Red Cross (either surge mission seconded via IFRC or longer term/bilateral mission), which NS's data are you expecting them to see?

[tovari]

hi @nanometrenat, we are considering to introduce regional/country user admin roles. They would maintain the user permissions, validate the registrations (where no NS domain available). My notes on your point 1. currently not all NS users have a structured NS assigned - True, they will need to set their NS on the account page. 2. currently there is no process to maintain user properties - e.g. when a user changes NS affiliation - and no authorisation step by the receiving NS - Regional/country admins could do this, and email verification would be required when changing email. 3. under the proposal above, how do delegates count? e.g. if a New Zealand Red Cross delegate is on mission to work with Fiji Red Cross (either surge mission seconded via IFRC or longer term/bilateral mission), which NS's data are you expecting them to see? - At the beginning only one NS could be assigned to a user, so it depends on, which is assigned on the account page. We will need to extend the option to register more organizations per user to cover such use cases.

[nanometrenat]

3. under the proposal above, how do delegates count? e.g. if a New Zealand Red Cross delegate is on mission to work with Fiji Red Cross (either surge mission seconded via IFRC or longer term/bilateral mission), which NS's data are you expecting them to see? - At the beginning only one NS could be assigned to a user, so it depends on, which is assigned on the account page. We will need to extend the option to register more organizations per user to cover such use cases.

This is a very usual use case (NOT a corner case) so it's important it's taken into account in the design phase!

Will also need to make a way for users to easily know who the focal point is that they should contact if they have GO permission issues, as if they can't see in the system who the admin is then they won't know who to speak to. Thanks

[batpad]

Rough proposal:

• Create a table to create a Many 2 Many relation between User <-> Country, with user, country and role, to allow users to be part of different national societies with different possible roles.
• For field report: Add another visibility option for IFRC + NS or so. In this case, we check whether user has permission for the country of the field report.
• For projects, similar: add a visibility option, and then check whether the user has permissions on either reporting_ns or project_country
• ... once DREF is merged, do the same for DREF.

We'd need to do these permission checks by over-riding the appropriate methods in the View / Viewset - @thenav56 would you have any example code where you're doing some custom permission checks inside DRF Views / Viewsets ? I think it can be a bit confusing knowing where exactly to add custom permission check logic and any examples / pointers would be helpful.

cc @vdeak @tovari @szabozoltan69

[thenav56]

We'd need to do these permission checks by over-riding the appropriate methods in the View / Viewset - @thenav56 would you have any example code where you're doing some custom permission checks inside DRF Views / Viewsets ? I think it can be a bit confusing knowing where exactly to add custom permission check logic and any examples / pointers would be helpful.

For the current case, modifying get_queryset should work. We will need to update the visibility mixin https://github.com/IFRCGo/go-api/blob/develop/api/visibility_class.py to include a filtered queryset. I would recommend calling.get_for function in each module which accepts the current user and then define the filtering logic there.

eg:

models.py

class Project(..):
    ....

    @classmethod
    def get_for(cls, user, queryset=None):
        _queryset = queryset
        if queryset is None:
            _queryset = cls.objects
        return _queryset.filter(reporting_ns__member=user)

visibility_class.py

class ReadOnlyVisibilityViewsetMixin():
    def get_visibility_queryset(self, queryset):
        ....
        if self.request.user.is_authenticated:
            if is_user_ifrc(self.request.user):
                return queryset
            return queryset.model\
                .get_for(self.request.user, queryset=queryset)\
                .exclude(visibility=choices.IFRC)
        return queryset.filter(visibility=choices.PUBLIC)
    ....

[nanometrenat]

Also, if you are expecting non-superusers to do the user admin (in terms of changing country mappings and roles etc.) then you may have a problem if the user doing the admin doesn't have access to the whole user set. E.g. if someone from NS-X in AP is needing to get access to NS-Y in Europe, will it need a global-level GO admin to do that admin? Please make sure all the business processes are mapped out (and support arrangements in place and clearly communicated to the relevant users, with information on-page for people to know who to contact) before making any tech changes to introduce restrictions. Don't want to get into a situation like FedNet, where if an NS is having problems registering with FedNet they get directed to submit a ticket at: https://itservicedesk.ifrc.org/, but people without an IFRC login can't access that system to submit a ticket. Need to be sure that there's clear signposting from the outside as to exactly who users should contact if they're an ordinary National Society person trying to use GO to best effect. Cheers