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

4175 add request type flag #4271

Closed

Conversation

nathangthomas
Copy link
Contributor

Resolves #4175

Description

Adds a request type flag to index and show pages as well as to the downloadable document so that banks can better see which type of request is being made.

Type of change

  • New feature (non-breaking change which adds functionality)

This can be manually tested by logging in as a bank user.

  Organization Admin
     Email: org_admin1@example.com
  Password: password!

  User
  Email: user_1@example.com
  Password: password!

Screenshots

Screenshot 2024-04-02 at 8 41 09 AM Screenshot 2024-04-02 at 8 41 21 AM

Requests-2024-04-02.csv

app/controllers/partners/family_requests_controller.rb Outdated Show resolved Hide resolved
@@ -19,6 +20,7 @@ def call
return self unless valid?

request_create_svc = Partners::RequestCreateService.new(
request_type: @request_type.to_i,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This service should already know the request type just by whether for_families is true or false.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that defining request_type in this way is more transparent. Would you prefer to add logic in the controller to determine request_type rather than using the instance var?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer putting the business logic as far back as possible. The controller is calling a service, which already has to know what kind of request it's creating. We can rely on the service to set the request type.

app/views/requests/_request_type.html.erb Outdated Show resolved Hide resolved
config/database.yml Outdated Show resolved Hide resolved
spec/models/request_spec.rb Outdated Show resolved Hide resolved
@nathangthomas nathangthomas requested a review from dorner April 24, 2024 14:38
@nathangthomas nathangthomas requested a review from dorner May 16, 2024 14:16
@nathangthomas nathangthomas requested a review from cielf May 16, 2024 14:38
Copy link
Collaborator

@cielf cielf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried it on my local. Signed in as verified@example.com, entered a quantity request and got
Screenshot 2024-05-16 at 3 44 50 PM

@cielf
Copy link
Collaborator

cielf commented May 16, 2024

Same effect for individual and child request. (Not at all surprised by that)

@nathangthomas
Copy link
Contributor Author

Well that is embarrassing. I'll take a look at it this afternoon.

@nathangthomas nathangthomas requested a review from cielf May 17, 2024 20:55
@nathangthomas
Copy link
Contributor Author

Seems I either forgot to add or removed request_type from the initializers. I have replaced them and tested locally. Everything should work as expected now.

cielf
cielf previously requested changes May 18, 2024
Copy link
Collaborator

@cielf cielf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alas, the quantity requests are showing up as "I" now. (Strange -- I think I confirmed them as working correctly before ...)

@nathangthomas nathangthomas requested a review from cielf May 21, 2024 17:27
@cielf
Copy link
Collaborator

cielf commented May 21, 2024

There's an issue with setup that's currently blocking me doing functional reviews -- just managing your expectations as to turnaround time.

Copy link
Collaborator

@cielf cielf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM now. @dorner?

@cielf cielf dismissed their stale review May 22, 2024 18:48

addessed,

@@ -8,7 +8,7 @@ class FamilyRequestCreateService

attr_reader :partner_user_id, :comments, :family_requests_attributes, :partner_request

def initialize(partner_user_id:, family_requests_attributes:, comments: nil, for_families: false)
def initialize(request_type:, partner_user_id:, family_requests_attributes:, comments: nil, for_families: false)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, why was this put back? We agreed that it wouldn't be needed because the service itself knows what type it is just by the current parameters being passed in.

@dorner
Copy link
Collaborator

dorner commented May 24, 2024

Had a question... also, lint is failing now.

@dorner
Copy link
Collaborator

dorner commented Aug 16, 2024

@nathangthomas looks like this is almost ready to go - can you finish it up?

@coalest
Copy link
Collaborator

coalest commented Nov 29, 2024

@nathangthomas This PR looks almost done. Could I help carry it across the finish line for you?

@cielf
Copy link
Collaborator

cielf commented Nov 29, 2024

@coalest It hasn't been touched since May -- please go ahead.

@coalest
Copy link
Collaborator

coalest commented Dec 3, 2024

A few questions:

  1. Checking out this branch I see that the new request_type flag is blank for all existing requests. Which makes sense, but I'm wondering will this need to be backfilled in production?
  2. I don't understand the point of the for_families parameter for the RequestCreateService service. We pass a value of true sometimes, but then we were doing nothing with it. Can it be removed?
  3. On a similar note, I see that for_families is a column in the partner_requests table but that table doesn't seem to be used anywhere in the application. There isn't even a PartnerRequest model defined. Can this be deleted or does it have important info in production?

@cielf
Copy link
Collaborator

cielf commented Dec 3, 2024

  1. Unfortunately, we can't backfill the data for this -- there isn't a basis for telling the difference between an individual and a quantity request once it's been saved.

2/3. I expect we'll be able to get rid of those after a bit of investigation, and I've added it to our tech debt inbox. I think it's out of scope for this issue, though.

@coalest
Copy link
Collaborator

coalest commented Dec 10, 2024

Closing this as #4827 was just merged which was built off of this work. Thanks @nathangthomas for doing the heavy lifting 🎉

@coalest coalest closed this Dec 10, 2024
@cielf
Copy link
Collaborator

cielf commented Dec 15, 2024

"I don't understand the point of the for_families parameter for the RequestCreateService service. We pass a value of true sometimes, but then we were doing nothing with it. Can it be removed?"
In discussion in the planning meeting, we think you've confused RequestCreateService and FamilyRequestCreateService, where for_families is in use.

@coalest
Copy link
Collaborator

coalest commented Dec 16, 2024

The for_families attribute used to be present in both RequestCreateService and FamilyRequestCreateService, but I removed it from `RequestCreateService in this commit: b761496.

If you look at the commit before this request_type PR was merge here, you can see that we pass in a for_families attribute to RequestCreateService from FamilyRequestCreateService, save it as an instance variable, but then do nothing with it. I removed it as I think it is more confusing to leave it there.

Regardless, I don't think we have to worry about this. I could have factored out for_families in the FamilyRequestCreateService, but I left it there so the PR would stay on scope without additional refactoring.

@coalest
Copy link
Collaborator

coalest commented Dec 16, 2024

Since we're discussing it though, I opened a small PR (internal refactor only) to remove that attribute completely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a flag that is the type of request.
4 participants