Skip to content
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

Prevent staff from changing application statuses for matched pets #579

Open
mononoken opened this issue Mar 21, 2024 · 2 comments
Open

Prevent staff from changing application statuses for matched pets #579

mononoken opened this issue Mar 21, 2024 · 2 comments
Labels
on hold Further investigation/decision-making is required question Further information is requested

Comments

@mononoken
Copy link
Collaborator

On hold pending feedback for desired solution. Please read below.

Problem

#578 added validations to prevent multiple matches for the same pet as well as to ensure adopters can only apply for a pet once.

However, this flow is currently possible:

  1. Match is created on pet with multiple applications on it (all adopter application statuses are set to :adoption_made)
  2. Staff navigates to http://localhost:3000/alta/pets/8?active_tab=applications
  3. Staff can still change status of pet from adoption_made to any other status.
  4. If status is changed to :successful_applicant, the New Adoption button becomes active.
  5. If they click "New Adoption", the new validations prevent a new match from being generated, and they receive a curt "Error" flash from the controller.

The data is protected in regards to the matches, but the adopter applications feel like they need more cleanup after a match is made.

Solutions

  1. Disable the staff's ability to change the adopter application status after it is set to :adoption_made.
  2. Remove these applications from the staff's view completely.
  3. Soft delete adopter applications after the match is made.

Any others? Is this not worth considering?

I think this would also be related to whether or not it is possible for a match to be destroyed. I think that topic was mentioned in the last meeting, but I don't remember if a clear direction was chosen on that.

📷 Screenshots/Demos

Clip of the flow, where it is currently possible to update statuses of applications for adopted/matched pets.

matched-pet-updating-app-statuses.mov
@mononoken mononoken added the on hold Further investigation/decision-making is required label Mar 21, 2024
@nsiwnf
Copy link
Collaborator

nsiwnf commented Mar 23, 2024

Yeah, curious what stakeholders would say. Like, do they ever have something like a 1-year check-in after adoption, "how's it going with Rosco?"

@nsiwnf nsiwnf added the question Further information is requested label Mar 23, 2024
@kasugaijin
Copy link
Collaborator

The way I handled this on the original app was to leave adopter applications in place and allowed staff to destroy a match. This is going to be very rare, but in some cases it doesn’t work out and the dog comes back. I thought leaving the adopter applications in place would allow staff to see who else was interested in the dog so they could reach out and let them know the dog was back. The adoption was destroyed while viewing the pet, not applications.

We could follow a similar flow.

  • disable editing application status on applications for a pet when a match is made (set unsuccessful application statuses to adoption made so an adopter can see that has happened)
  • Then on the pet show have an option to destroy a match. This would then bring the application status back to an editable state. We could set them to awaiting review to start the process again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold Further investigation/decision-making is required question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants