Skip to content

OBPIH-6747 support empty lot number in import that matches inventory item defined as null#4866

Merged
awalkowiak merged 9 commits intorelease/0.9.2-hotfix1from
feature/OBPIH-6747-support-empty-lot-number-in-import-that-matches-inventory-item-defined-as-null
Oct 1, 2024
Merged

OBPIH-6747 support empty lot number in import that matches inventory item defined as null#4866
awalkowiak merged 9 commits intorelease/0.9.2-hotfix1from
feature/OBPIH-6747-support-empty-lot-number-in-import-that-matches-inventory-item-defined-as-null

Conversation

@drodzewicz
Copy link
Collaborator

@drodzewicz drodzewicz commented Sep 27, 2024

✨ Description of Change

A concise summary of what is being changed. Please provide enough context for reviewers to be able to understand the change and why it is necessary. If the issue/ticket already provides enough information, you can put "See ticket" as the description.

Link to GitHub issue or Jira ticket: OBPIH-6747

Description:
The inferring bin Location and lot number required a bit of a refactor, I decided to move many parts into standalone service methods for better maintainability and readability because this feature has grown a bit.

Additionally since there are many different inferring/binding scenarios I am working on implementing tests for these methods


📷 Screenshots & Recordings (optional)

If this PR contains a UI change, consider adding one or more screenshots here or link to a screen recording to help reviewers visualize the change. Otherwise, you can remove this section.

@drodzewicz drodzewicz added warn: do not merge Marks a pull request that is not yet ready to be merged status: ready for review Flags that a pull request is ready to be reviewed labels Sep 27, 2024
@drodzewicz drodzewicz self-assigned this Sep 27, 2024
@github-actions github-actions bot added type: feature A new piece of functionality for the app domain: backend Changes or discussions relating to the backend server labels Sep 27, 2024
return debitTransaction
}

String bindOrInferLotNumber(ImportPackingListItem obj, Map source) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I can see that the only property from obj we use is the origin. Let's change the arguments to be Location origin, Map source, since we do not need anything else from the obj.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

let's leave it as they are since the methods are basically the @UseBinding methods but moved to the service.
The other binding method requires this obj since we set obj.binLcoationNotFound flag on it and it would be weird where one has this argument and the other binding method doens't

return availableBinLocations
}

AvailableItem getAvailableItemWithDefaultLots(Location origin, String productCode) {
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 the name of this method doesn't fit to what the method is actually doing. We should either think about the name again, or at least add a comment above the method.
My point is that if you find 3 items, in fact there is 3 available items found, but the method would return null, which is a bit misleading.

return null
}

AvailableItem inferAvailableItemByBinLocation(Location origin, String productCode, String binLocationName) {
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 get fits more than infer - we should change it to get here or use infer in all methods.

return new Location(name: source['binLocation'])
@BindUsing({ obj, source ->
FulfillmentService fulfillmentService = Holders.grailsApplication.mainContext.getBean(FulfillmentService)
return fulfillmentService.bindOrInferBinLocation(obj as ImportPackingListItem, source as Map)
Copy link
Collaborator

Choose a reason for hiding this comment

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

instead of casting it here, I think you could assign the type in the obj, source, like:

@BindUsing({ ImportPackingListItem obj, Map source -> })

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 am not sure why but for some reason this doesn't work.
When doing this it can't find the method which is why I resorted to the approach of casting the value

@drodzewicz drodzewicz removed the warn: do not merge Marks a pull request that is not yet ready to be merged label Oct 1, 2024
@awalkowiak awalkowiak merged commit 84e5e4f into release/0.9.2-hotfix1 Oct 1, 2024
@awalkowiak awalkowiak deleted the feature/OBPIH-6747-support-empty-lot-number-in-import-that-matches-inventory-item-defined-as-null branch October 1, 2024 13:54
jwalbers pushed a commit to jwalbers/openboxes that referenced this pull request Oct 29, 2024
jwalbers pushed a commit to jwalbers/openboxes that referenced this pull request Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain: backend Changes or discussions relating to the backend server status: ready for review Flags that a pull request is ready to be reviewed type: feature A new piece of functionality for the app

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants