I'll approve the PR because this does seem to fix the issue, but I'm curious why we're setting values like this in the validator. It seems outside of the functionality of what a validator should do

@ewaterman it's due to the fact, that the expiration date comes from an inventory item, and we do not provide the inventory item's id to be bound, but we rely on product/lotNumber pair that is used to find an inventory item.
The assignment of the expirationDateToDisplay is used only in order to display that date in the table - it is not persisted anywhere and validated.
On regular basis, in the toTableJson() we would just do:

expirationDate: inventoryItem?.expirationDate

but as I wrote earlier - we don't bind the InventoryItem to the ImportPackingListItem, but we rely on product/lotNumber pair.

it just feels weird for a validation step to be setting any fields on the object, even if they're not persisted. IMO once we hit the validation step, the object should already be fully constructed and so all we should need to do is simple checks on the fields. Embedded validators like this should be small. If we need to do other complex lookups or call other service methods, it signals to me that either we're missing important references in the object, or we might need a more deliberate validation step that happens outside of the object (via a XValidator.validate(x) call or something).

Anyways, the code is already merged and this is not new code, but it does feel to me like this validator is taking on too much responsability.