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

Eagerly de-duplicating items when submitting request #4414

Merged
merged 11 commits into from
Jun 8, 2024

Conversation

patelkrunal31
Copy link
Collaborator

@patelkrunal31 patelkrunal31 commented May 31, 2024

Resolves #4394

Description

In order to support the packs, we want the request items to be collapsed at save, so the banks only see one line per item in the request.

On save, the request items should be collapsed so that there is only one request item per item.

Type of change

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

How Has This Been Tested?

We have added unit tests to cover all the scenario and verified manually by going through the flow on local machine.

Screenshots

Screenshot 2024-05-31 at 4 45 19 PM Screenshot 2024-05-31 at 4 46 01 PM Screenshot 2024-05-31 at 4 46 17 PM Screenshot 2024-05-31 at 4 46 36 PM Screenshot 2024-05-31 at 4 47 44 PM

@patelkrunal31 patelkrunal31 force-pushed the kp/merge-line-items-at-request-save branch from 578d3d5 to ac33f88 Compare May 31, 2024 18:40
if pre_existing_entry
pre_existing_entry.quantity = (pre_existing_entry.quantity.to_i + input_item['quantity'].to_i).to_s
# TODO: Is the following the correct way to merge?
pre_existing_entry.children += input_item['children'] || []
Copy link
Collaborator

Choose a reason for hiding this comment

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

We aren't sure how this child field is meant to be used, so we weren't sure whether this merge method makes sense.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you don't need to do this. From what I can tell, each child has a field item_needed_diaperid (which seems to indicate that a child can only really be associated with a single item). So when the family request is created, the logic collects all the children in the family relevant to the given item ID and passes them in. In this case, since the item ID is the same, the list children should also be the same. Probably worth some footling around to verify.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Also probably should have tests around this.

Copy link
Collaborator

Choose a reason for hiding this comment

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

We chatted with Brock. It generally shouldn't happen because today the family requests controller eagerly groups the requested items (but we obvs don't want to rely on that controller logic for the model to be correctly instantiated). We think the 'correct-ish' way to merge in children if it somehow occurred is to do it as a set-style operation. If the upstream code has mucked about with quantity and done it poorly, we won't be able to fix things here for it without causing more issues.

Might be a way in the future to pull more of that instantiation logic out of the controller, but we added a test for now to verify the behavior we've implemented.

Comment on lines +70 to +77
name: fetch_organization_item_name(input_item['item_id']),
partner_key: fetch_organization_partner_key(input_item['item_id'])
Copy link
Collaborator

Choose a reason for hiding this comment

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

We're relying on the fact that a single request doesn't come from more than one partner (which is why we're not doing any merging of name / partner).

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah. Probably all of this needs additional refactoring well beyond this de-duplication.

@patelkrunal31 patelkrunal31 force-pushed the kp/merge-line-items-at-request-save branch from 0c9828f to ee2341f Compare May 31, 2024 19:50
@patelkrunal31 patelkrunal31 marked this pull request as ready for review May 31, 2024 20:51
app/mailers/requests_confirmation_mailer.rb Outdated Show resolved Hide resolved
if pre_existing_entry
pre_existing_entry.quantity = (pre_existing_entry.quantity.to_i + input_item['quantity'].to_i).to_s
# TODO: Is the following the correct way to merge?
pre_existing_entry.children += input_item['children'] || []
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you don't need to do this. From what I can tell, each child has a field item_needed_diaperid (which seems to indicate that a child can only really be associated with a single item). So when the family request is created, the logic collects all the children in the family relevant to the given item ID and passes them in. In this case, since the item ID is the same, the list children should also be the same. Probably worth some footling around to verify.

if pre_existing_entry
pre_existing_entry.quantity = (pre_existing_entry.quantity.to_i + input_item['quantity'].to_i).to_s
# TODO: Is the following the correct way to merge?
pre_existing_entry.children += input_item['children'] || []
Copy link
Collaborator

Choose a reason for hiding this comment

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

Also probably should have tests around this.

@patelkrunal31 patelkrunal31 requested a review from dorner June 1, 2024 15:46
@scooter-dangle
Copy link
Collaborator

Added data migration in #4417. Dunno if that's the right way to do that, but I don't want us to have to worry about data persisting that would fail the newly added validation.

@patelkrunal31 patelkrunal31 force-pushed the kp/merge-line-items-at-request-save branch from e2bbc6a to 0b88184 Compare June 1, 2024 16:45
Copy link
Collaborator

@awwaiid awwaiid left a comment

Choose a reason for hiding this comment

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

One change

@@ -33,6 +33,7 @@ class Request < ApplicationRecord
enum status: { pending: 0, started: 1, fulfilled: 2, discarded: 3 }, _prefix: true

validates :distribution_id, uniqueness: true, allow_nil: true
validate :item_requests_uniqueness_by_item_id
Copy link
Collaborator

Choose a reason for hiding this comment

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

Right -- this is the one that could be annoying if we didn't do the data cleanup.

Copy link
Collaborator

Choose a reason for hiding this comment

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

... but I haven't found any places where we actually do editing of item requests after create. So probably fine actually.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I changed it to be a validation on item_requests.

@@ -59,6 +60,13 @@ def user_email

private

def item_requests_uniqueness_by_item_id
item_ids = request_items.map { |item| item["item_id"] }
Copy link
Collaborator

Choose a reason for hiding this comment

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

Switch this to item_requests

formatted_line_items.each do |input_item|
pre_existing_entry = items[input_item['item_id']]
if pre_existing_entry
pre_existing_entry.quantity = (pre_existing_entry.quantity.to_i + input_item['quantity'].to_i).to_s
Copy link
Collaborator

Choose a reason for hiding this comment

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

.to_s meh, but I get it ... the actual database for Partner::ItemRequest quantity is a string! hmmmmm

Copy link
Collaborator

Choose a reason for hiding this comment

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

soooo annoying that the schema uses string for quantity

Comment on lines +70 to +77
name: fetch_organization_item_name(input_item['item_id']),
partner_key: fetch_organization_partner_key(input_item['item_id'])
Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah. Probably all of this needs additional refactoring well beyond this de-duplication.

@scooter-dangle
Copy link
Collaborator

scooter-dangle commented Jun 1, 2024

Blerg. Found a place where we can end up adding dup items in the seed:

Array.new(Faker::Number.within(range: 4..14)) do
item = p.organization.items.sample
new_item_request = Partners::ItemRequest.new(
item_id: item.id,
quantity: Faker::Number.within(range: 10..30),
children: [],
name: item.name,
partner_key: item.partner_key,
created_at: date,
updated_at: date
)
partner_request.item_requests << new_item_request
end

  • Will need to pre-sample all the items we intend to add so that we don't end up adding dups.

EDIT: I'll add a quick fix for this one.

Copy link
Collaborator

@awwaiid awwaiid left a comment

Choose a reason for hiding this comment

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

This all works and is good; we still have an issue with some historical data separately. This will prevent and assume the prevention of duplicates going-forward.

However, I'd still like a @dorner check before we merge since it's a bit wide-sweeping.

@dorner
Copy link
Collaborator

dorner commented Jun 7, 2024

I'm good for this. Is it blocked on #4417 ?

@awwaiid
Copy link
Collaborator

awwaiid commented Jun 8, 2024

No, this specific merging action isn't blocked -- it will prevent new duplicates and old-duplicates aren't affected by this since they (contents) aren't edited after create. We still want to de-duplicate the historical records for cleanliness, and it will allow the mailer refactor and a cleaner assumption.

@awwaiid awwaiid merged commit e391667 into main Jun 8, 2024
38 checks passed
@awwaiid awwaiid deleted the kp/merge-line-items-at-request-save branch June 8, 2024 01:54
@awwaiid awwaiid added this to the Request Units (Packs) milestone Jul 21, 2024
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.

Merge line items at request save. Not just for children anymore. ()
4 participants