Closed lowellrex closed 5 years ago
fwiw I'd vote for the "soft delete" approach we follow in HearingDay
with the acts_as_paranoid
gem. It has some drawbacks, but I would enjoy the consistency of it in the codebase.
Idea. If it ever boils down to a manual process where the Board has to notify us of staff leaving then it would be cool to have a ‘admin panel’ similar to ‘team management’ where we add the user/CSS ID.
Adding the user/css ID to the listing would:
The VLJ from there makes the decision on what happens next.
status
column to users tableAdd a status
column to the user's table. When assigning tasks only show "active" users. Add a uses management page to show all users and their status (in different sections or sorted by active/inactive) with the option to mark them inactive (or active again).
status
and status_changed_at
column to the users table with the default status as "active" and add an index on status as we will frequently be requesting only users with a status of "active". Add an enum for all the available user statuses ('active' and 'inactive' to start until design or product indicate we need others?)acts_as_paranoid
The paranoia gem that we use to soft delete HearingDay
s and WorksheetIssue
s would allow us to "delete" a user without removing it from our database. By adding acts_as_paranoid
to the user model, any calls to fetch a user would only return the non "deleted" users.
The implementation would be very similar to the one above
deleted_at
to the users table. Add acts_as_paranoid without_default_scope: true
to the user model.without_deleted
. On task creation, we would still need to validate user.deleted?
as the default scope is to return all users.user.deleted?
to handle both options on the front end. Add endpoint to users_controller (not within organizations/users_controller) to soft delete (user.destroy
) or restore (user.restore
) that user. Add front end page that displays all users and their deleted status. Add button, confirmation, and success alert that hits the delete or restore user endpoint.status
column to allow us to represent other statesFor these reasons we will be moving forward with Solution 1
status_changed_at
column migration and implementation for solution 1.acts_as_paranoid
solutionCompiling a list of places we may want to add an active
scope to or validation that a user is active:
users_to_options
as every place it is used would require active scoped users. If not:
Judge.list_all
users
attorneys
add_user_to_organization
and make_user_admin
?Wow bowing out for the day once I decided to look at organization.users
. Other places I still had yet to glance at:
Other finds:
next_assignee
sNext step is to create engineering tickets that spawn from this tech spec cc: @hschallhorn
Proposed user flow: On Caseflow team management page, team admin searches for user and then marks them inactive.
Rows in Caseflow's
users
table should never be deleted* from the database. This allows us to keep a record of users as long as the application lives. However, this practice of persistingUser
records in perpetuity presents some challenges with tasks. Two salient challenges are 1) people who are no longer working on Caseflow (perhaps because they are no longer employed at the VA or at a VSO) can still be assigned tasks and 2) we have no insight into how many active tasks are assigned to people who will never act on those tasks.These challenges were identified in a related Slack conversation and this ticket exists to explore how we can solve these problems and other problems that stem from the fact that we do not identify inactive Caseflow users.
Acceptance criteria
Estimating this ticket at a 3 because that is our practice for all tickets where the end result is a tech spec.
*On rare occasions we have deleted rows from the
users
table. One example that comes to mind is when we consolidated duplicate rows in that table.