-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deactivate adopters/fosterers #773
Comments
Dibs! |
The description talks about adding this functionality for both adopters and fosterers, but the implementation suggestion mainly refers to only fosterers. Is this because we actually only want to add the deactivate functionality for fosterers, or am I meant to replicate those steps for adopters as well? @mononoken Update: This has been answered on the PR |
The goal of this ticket was to add the ability for staff to deactivate ‘fosterer’ accounts just like how ‘staff’ accounts can already be deactivated. A migration was generated to add ‘deactivated_at’ to the ‘adopter_foster_account’ table. Since this functionality was going to be repeated in multiple places I decided to refactor. I pulled out the ’staff/staff/_deactivate_toggle.html.erb’ partial and put it in ‘app/views/partials’ so it was more accessible. I then refactored this to be more generic so multiple roles could use it. Related files were added/edited to make this work. For example, ‘update.turbo_stream.erb’ was added to the ‘staff/fosterers’ directory, and the one within ‘staff/staff’ was edited to fit the refactor. I’m not sure if there is potential to refactor these turbo files to keep the code even more DRY. Also, ‘deactivate’, ‘activate’, ‘update_activation’, and ‘set_fosterer’ were all added to the ‘fosterers_controller.rb’ to facilitate the new behavior. ‘set_fosterer’ involved authentication with ‘Action Policy’. Shoutout to @jmilljr24 for hardcore carrying me on the back half of this PR with all things related to the policies and routes. I’ve yet to add tests for this, but the behavior is functioning. Extra tidbit: Added a new gem to the gem file called "binding_of_caller" that enables the REPL and local/instance variable inspection when an error blows up the website.
The goal of this ticket was to add the ability for staff to deactivate ‘fosterer’ accounts just like how ‘staff’ accounts can already be deactivated. A migration was generated to add ‘deactivated_at’ to the ‘adopter_foster_account’ table. Since this functionality was going to be repeated in multiple places I decided to refactor. I pulled out the ’staff/staff/_deactivate_toggle.html.erb’ partial and put it in ‘app/views/partials’ so it was more accessible. I then refactored this to be more generic so multiple roles could use it. Related files were added/edited to make this work. For example, ‘update.turbo_stream.erb’ was added to the ‘staff/fosterers’ directory, and the one within ‘staff/staff’ was edited to fit the refactor. I’m not sure if there is potential to refactor these turbo files to keep the code even more DRY. Also, ‘deactivate’, ‘activate’, ‘update_activation’, and ‘set_fosterer’ were all added to the ‘fosterers_controller.rb’ to facilitate the new behavior. ‘set_fosterer’ involved authentication with ‘Action Policy’. Shoutout to @jmilljr24 for hardcore carrying me on the back half of this PR with all things related to the policies and routes. I’ve yet to add tests for this, but the behavior is functioning. Extra tidbit: Added a new gem to the gem file called "binding_of_caller" that enables the REPL and local/instance variable inspection when an error blows up the website.
The goal of this ticket was to add the ability for staff to deactivate ‘fosterer’ accounts just like how ‘staff’ accounts can already be deactivated. A migration was generated to add ‘deactivated_at’ to the ‘adopter_foster_account’ table. Since this functionality was going to be repeated in multiple places I decided to refactor. I pulled out the ’staff/staff/_deactivate_toggle.html.erb’ partial and put it in ‘app/views/partials’ so it was more accessible. I then refactored this to be more generic so multiple roles could use it. Related files were added/edited to make this work. For example, ‘update.turbo_stream.erb’ was added to the ‘staff/fosterers’ directory, and the one within ‘staff/staff’ was edited to fit the refactor. I’m not sure if there is potential to refactor these turbo files to keep the code even more DRY. Also, ‘deactivate’, ‘activate’, ‘update_activation’, and ‘set_fosterer’ were all added to the ‘fosterers_controller.rb’ to facilitate the new behavior. ‘set_fosterer’ involved authentication with ‘Action Policy’. Shoutout to @jmilljr24 for hardcore carrying me on the back half of this PR with all things related to the policies and routes. I’ve yet to add tests for this, but the behavior is functioning. Extra tidbit: Added a new gem to the gem file called "binding_of_caller" that enables the REPL and local/instance variable inspection when an error blows up the website.
The goal of this ticket was to add the ability for staff to deactivate ‘fosterer’ accounts just like how ‘staff’ accounts can already be deactivated. A migration was generated to add ‘deactivated_at’ to the ‘adopter_foster_account’ table. Since this functionality was going to be repeated in multiple places I decided to refactor. I pulled out the ’staff/staff/_deactivate_toggle.html.erb’ partial and put it in ‘app/views/partials’ so it was more accessible. I then refactored this to be more generic so multiple roles could use it. Related files were added/edited to make this work. For example, ‘update.turbo_stream.erb’ was added to the ‘staff/fosterers’ directory, and the one within ‘staff/staff’ was edited to fit the refactor. I’m not sure if there is potential to refactor these turbo files to keep the code even more DRY. Also, ‘deactivate’, ‘activate’, ‘update_activation’, and ‘set_fosterer’ were all added to the ‘fosterers_controller.rb’ to facilitate the new behavior. ‘set_fosterer’ involved authentication with ‘Action Policy’. Shoutout to @jmilljr24 for hardcore carrying me on the back half of this PR with all things related to the policies and routes. I’ve yet to add tests for this, but the behavior is functioning. Extra tidbit: Added a new gem to the gem file called "binding_of_caller" that enables the REPL and local/instance variable inspection when an error blows up the website.
This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned. |
Automatically unassigned after 7 days of inactivity. |
On hold until account model changes. Reference discussion in #878 |
Description
We have the functionality to deactivate staff accounts. Let's let staff admins also be able to deactivate adopters and fosterers.
This will require you to add a new
deactivated_at
column to theAdopterFosterAccounts
table. You can look at how StaffAccounts was setup for a reference.You will also need to create
#deactivate
and#activate
actions inOrganizations::Staff::FosterersController
. Seeapp/controllers/organizations/staff/staff_controller.rb
for ref.Ultimately, we want this column to be shown on the Fosterers index page.
NOTE: This is just adding deactivated_at and modifying it. We will add the functionality of utilizing deactivation in a separate issue using the policies.
Acceptance Criteria
deactivated_at
toadopter_foster_accounts
table#deactivate
and#activate
methods forStaffAccount
model#deactivate
and#activate
actions inOrganizations::Staff::FosterersController
deactivate
toggle to all fosterer entries at/staff/fosterers
deactivated_at
The text was updated successfully, but these errors were encountered: