Move confirm/reject to a backend workflow and introduce permissions for ability to confirm / reject specific lists

[obrienad]

Overview

Move confirm/reject to a backend workflow, with the ability to give specific users access to confirm/reject specific lists. This will improve data quality as the OAR team is better positioned to understand when a facility meets the criteria for being matched. The requirement includes that there must be a confirm/reject queue populated with pending facility items. This does not include flagged queue).

Technical Implementation

• Add non-null match_responsibility field to both Contributor and FacilityList models.
  • Choice field: MODERATOR or CONTRIBUTOR
  • The default for both Contributor and FacilityList should be MODERATOR BUT any existing lists at the time of migration should have a default value.
  • A suggested way of handling this is to have a 2-stage migration with the the default faclut of FacilityList.match_responsibility first set to CONTRIBUTOR so that all the existing list values are set appropriately, then modified to be MODERATOR.
• Ensure that this match_responsibility field can be edited for both Contributor and FailityList via the Django admin
• When a FacilityList is created, copy the value of match_responsibility from the Contributor to the FacilityList
• When browsing the list details page, show the confirm/reject buttons based on the user and the value of match_responsibility.
  • If the contributor is viewing the list, show the buttons if match_responsibility is CONTRIBUTOR
  • If any superuser is logged in, show the buttons if match_responsibility is MODERATOR
  • Reference how dashboard access is managed in the client to see how super admins are recognized
  • When browsing the list details page conditionally show an informational messaged value of match_responsibility.
  • If the contributor is viewing the list but the match_responsibility is MODERATOR show a message that the list is awaiting moderation
    • QUESTION Get exact copy from the OS Hub team
• Add pagination to /api/facility-lists
• Add a match_responsibility and status filter parameters to /api/facility-lists
  • status supports a single value, MATCHED and only returns lists where the items are in any of the match status
• Ensure the sort order of /api/facility-lists is oldest list first
• Add pagination UI to the /dashboard/lists page
• Modify the default content of the /dashboard/lists page
  • Fetch lists with match_responsibility=MODERATOR&status=MATCHED
• Add dropdown to change the match_responsibility value

[jwalgran]

@mariel-oar I tagged this client action needed because we need to answer this question.

When we switch confirm/reject to the the responsibility of the moderation team by default, what should we do about any existing lists that are awaiting confirm/reject? Should they stay the responsibility of the contributor or should we reassign them to be the responsibility of the moderation team?

[mariel-oar]

I'm trying to figure out what that would mean in terms of number of facilities...based on this report it looks like there could be up to ~65k facilities in pending confirm / reject status. is that correct?

cc: @vrwOAR

[mariel-oar]

@obrienad @jwalgran, we would like to have these facilities remain in the user's confirm / reject queue so that our team can stay focused on the new data coming in.

[jwalgran]

Thanks, @mariel-oar. We will set the responsibility for any existing lists to CONTRIBUTOR