lookit / lookit/lookit-api

Align Admin app functionality with model definitions and usage

Open
#575 0 comments 0 reactions 1 assignee View on GitHub

@kimberscott is already working on this.

Since Sep 13, 2020.

Small Staff
Dominant language
Python
Stars
12
Forks
21
Avg merge
5d 19h
Merged PRs (30d)
5

Description

**TL;DR**: Clean up which fields we use to look up and display records in the Admin app so it's more practical to use.

**Narrative**
As a staff member, I want to be able to provide technical support to participants or researchers using the Admin app, but often run into difficulty (a) finding the relevant records or (b) making appropriate edits.

Example use cases for the Admin app:
- Someone doesn't see a consent video show up on the consent manager. Is it there in the database, but not flagged as consent footage? Or is it not there?
- A participant asks to be "taken off the email list" and we do it for them instead of walking them through logging in and doing it themselves, because we don't want to be jerks.
- A researcher asks for their 2FA to be reset and we want to check first what studies they have any access to, because if they have access to participant data we need to actually confirm the request via Zoom etc., but if not we can just do it.
- A participant asks to merge one account with another, and we need to find out what children, responses, and demographic data are associated with the account, choose one account & set of children to keep, and have all responses point to appropriate children & demographic data
- A participant or researcher asks for a particular video to be deleted

**Acceptance Criteria**

Children
- [ ] Allow searching by _user_ email address and UUID if possible, OR display Children on the User detail page. (Currently we find children associated with a user by finding the user, clicking "delete," and viewing the list of objects that would be deleted...)
- [ ] Allow filtering by deleted (makes it easy to manually delete if no participation) - can alternately just wait on #712

User
- [ ] Don't require FamilyName, timezone, or locale (at least for non-researchers) so that we can make a change (e.g. fixing an email address, making active/inactive) without filling in default values for these
- [ ] Display username in list view (so after searching we can select the appropriate person)
- [ ] Ideally: under "Groups" field for groups the user is in, make the "Group" display string something that reflects the CURRENT name of the study and/or lab of the study - this is helpful for finding out if the researcher has access to actual participant data yet for 2FA requests. (Even better would be to show a list of studies they have any access to, but I don't think that fits in well with how Admin works by default.)

Response
- [ ] Allow searching by UUID (so we can actually find the response using the UUID from Admin; otherwise we have to first find the pk, e.g. using the API)
- [ ] Allow exp_data, global_event_timings to be empty (in line with model) so that we can edit Response data if needed without filling in a default value (e.g., when merging accounts and having a Response point to a different duplicate child)

Message
- [ ] Allow searching by email or UUID of recipient (important to find all past correspondence through Lookit if participant emails Lookit for help)
- [ ] Allow filtering on announcement vs. other email (useful if just want to see all emails that have been personally sent, e.g. for a given study)

Labs
- [ ] If possible, restrict users/requested users to researchers (otherwise we're loading dropdowns for all users and it takes a long time)

DemographicData
- [ ] Allow searching by username and/or user ID so we can find demographic data for a given user
- [ ] Enter "previous" via PK, in line with other foreign key fields, rather than dropdown of all other demographic data (to enable merging accounts more naturally, and avoid loading a huge list of all demographic data)

Consent rulings
- [ ] If possible, allow filtering by the study's lab so we can e.g. see how consent coding is going for a given lab, if people are interpreting "valid" differently, etc.
- [ ] Allow filtering by action (mostly to find 'rejected' ones)
- [ ] Don't show all options for study & arbiter (there are too many) - enter these by ID
- [ ] Show comment in the list view

Videos
- [ ] Allow searching by response UUID (note: this might already be the case because the response UUID is part of the video filename which is a search field - just confirm)

Studies
- [ ] Display lab instead of creator in list view
- [ ] Ideally: allow searching by lab name or PI in addition to study name (because otherwise workflow to get a lab's studies is to search on the page for the lab name and click the filter link)

Study logs
- [ ] Display comment in list view
- [ ] Allow filtering by action (submitted, rejected, etc.)

General
- [ ] Basic tests for Admin app (access/rendering) only
- [ ] QA on staging for workflows listed in issue summary

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.