feat: Create product hash of published product properties #4336
Conversation
kieckhafer
changed the title
kieckhafer
changed the title
…dp-catalog (fix): Use Catalog collection for PDP
| "hash": { | ||
| type: String, | ||
| optional: true, | ||
| defaultValue: "" |
There was a problem hiding this comment.
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.
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.
isBackorder,isLowQuantityandisSoldOutdon't exist on products, so remove those- Remove
positionsbecause we don't support it anymore - The
mediaprop 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
workflowis 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.
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.
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.
I don't see any reason why hash would be needed on the CatalogProduct
…ub.com/reactioncommerce/reaction into feat-4264-kieckhafer-createProductHash
kieckhafer
dismissed
aldeed’s stale review
@aldeed addressed your comments, ready for another look.
|
@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-hashnpm 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
createdAtandupdatedAt, and thehashitself.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
createCatalogProducthas 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.