user.states.incident incorrect, causing Spinner of Death

[aarontitus]

Description

Somehow, user_users.states->incident is getting set to an incident to which the user's organization does not have access. It should happen to admins and phone volunteers. I think this is happening when phone volunteers answer calls, and then don't log in for months, then lose access to the incident. I've confirmed 260 instances of users with a mismatched user state.
I logged in as user 75, organization 130 (voad@aa...), and the login never completes, getting stuck in the endless spinner of death.

Expected Behavior

Get user_users.states->>incident

1. If the user is an admin, then allow it to load.
2. If the user is a phone volunteer AND the incident is more than 2 months old, AND the user's organization does not have access, then then it should revert to the most recent incident to which the organization DOES have access.
3. If the user is not a phone volunteer or admin AND the organization does not have access to the user states incident, then it should revert to the most recent incident to which the organization DOES have access.

Current Behavior

Unfortunately, this particular bug is not solvable by the user. Logging in via an incognito browser does not work. Clearing states would work, but that requires the user to be able to log in. It currently requires a manual database update.

Screenshots

Spinner of death on https://www.crisiscleanup.org/dashboard

Steps to Reproduce

User 75 belongs to organization 130, which does NOT have access to incident 385.

1. Log in as User 75 (voad@aa...)
2. Manually update the user's states in the database: UPDATE user_users SET states = '{"incident": 385}' WHERE id = 75;
3. Without refreshing, visit https://www.crisiscleanup.org/dashboard
4. Note: This will not work with admin accounts, since they have defacto access to all incidents.

Tasks

• Find out why this is happening
• Aaron to add this to housekeeping();
• Fix expected behavior.

[aarontitus]

Superseded by #687