-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
feat: Create product hash of published product properties #4336
feat: Create product hash of published product properties #4336
Conversation
…dp-catalog (fix): Use Catalog collection for PDP
"hash": { | ||
type: String, | ||
optional: true, | ||
defaultValue: "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need any default value. Is there a reason to have it?
Also, can we call it publishedProductHash
for clarity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't make sense, but it was defaulting to {}
before I added this, which was causing an error. As soon as I added it, the error went away.
I changed a few things after that so I'll try to remove it and update the name.
workflow: { | ||
status: product.workflow.status | ||
} | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isBackorder
,isLowQuantity
andisSoldOut
don't exist on products, so remove those- Remove
positions
because we don't support it anymore - The
media
prop that we generate on the CatalogProduct will need to be part of the hash (should show as changed if any media have changed or the order of the media) - I don't think
workflow
is needed because we don't publish it
Also, I believe you will need to add all of the descendent variants and options to the hash. I guess this is why I was thinking the catalog schema would be hashed rather than product schema. Even though we are storing the hash on Product, we need to tell them to republish if anything beneath that product has changed, which includes all properties of all its variants and options.
} | ||
}, | ||
{ upsert: true } | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
upsert: true
and $setOnInsert
are not needed because we know for sure it already exists, because we have productId
.
* @param {Object} collections - Raw mongo collections | ||
* @return {Object} updated product if successful, original product if unsuccessful | ||
*/ | ||
export default async function hashProduct(productId, collections) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is updating DB, it belongs in no-meteor/mutations
rather than no-meteor/utils
barcode: product.barcode, | ||
createdAt: product.createdAt, | ||
description: product.description, | ||
hash: product.hash, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any reason why hash would be needed on the CatalogProduct
…ub.com/reactioncommerce/reaction into feat-4264-kieckhafer-createProductHash
@aldeed addressed your comments, ready for another look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG2M!
@kieckhafer I changed this PR to merge into release 1.14.0 since 1.13.0 is out now. We've got a few conflicts if you can resolve I'll merge. |
Resolves #4264
Impact: minor
Type: feature
Issue
After the removal of revisions, we need a way to allow an admin user to see if a product has been updated. Saving a hash of the data in it's current state, to allow for comparison, will allow the admin user to see if changes have been made.
Solution
Use the
object-hash
npm library to create a hash based on specific fields of a product that we want to track. Save this hash to the product itself, to check against to see if fields have been updated (ticket #4281)Most fields are included in this hash. The primary excluded fields are system generated auto-fields such as
createdAt
andupdatedAt
, and thehash
itself.Additional notes:
createCatalogProduct
, so we can keep it separate incase we ever want to create / see the catalog data without publishing it at the same time.Breaking changes
The function
createCatalogProduct
has been moved into it's own file. This should not create any issues, as it was not an exported function, but just be aware.Testing
OR
Start the app and see the hash on a product that's already created, via migration.