-
Notifications
You must be signed in to change notification settings - Fork 18
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
[FEATURE REQUEST] delete / hide products #333
Comments
Thanks for this issue. I think you are pointing to some very important details here and also propose a good solution. Some remarks from my side:
|
@schmidsi yes, but to be precise: in general, every product should be readable, forever. The exceptions are law-suits or accidental published products or similar. orderable would be 2). it would decouple beeing able to order it to whether it would be listed somewhere. A customer may decide to still list the product (discorverable true), but show that it won't be ordered again and therefore can't be purchased anymore (orderable false). Another customer might also want to hide this product from list (setting discoverable AND orderable to false) |
Very interesting topic but I think we still haven't found a sustainable way to tackle these problems yet. I agree with the requirements:
For most e-commerce cases we have used Unchained before except for one (Veloplus), DRAFT,ACTIVE,DELETED are more than enough but for the requirements above additional flags like discoverable and orderable are too strict and is not very "hackable" so I'd solve this by the ability to extend product behavior by a plugin style that allows to control visibility and orderability by code. That is already partly done:
The publication workflow for reviews is already there, a product currently is first in DRAFT (= hidden) and can be published. It's currently very easy to change the behavior that only admins can publish a product by using the ACL.10. So I think we should definetely sketch out a master plan for these cases but it should be built in a "hackable" way rather than built-in assumptions on how publication,orderability etc. works based on product flags. |
Introduction
while its in general good to not delete entries in your db,
you still want to hide certain products from customers e.g. because the producer of the product wants to remove it from market due to some law suite or so.
its important that customers can neither access these products through list, nor through direct query by id, nor through orders. It should show that this product has been removed and should not reveal any details of this product
Is your feature request related to a problem? Please describe.
The problem is that neither setting product.state to null (which maps to a "DRAFT" state) nor to "DELETED" hides the product from
Query.product
furthermore, i think there is an additional problem here: Setting a product to "DRAFT" seems to do exactly the same thing as setting it to "DELETED" and its entangled with the functionality to hide products from assortment.searchProducts, which i think is a different thing
Describe the solution you'd like
First lets try to formalize the requirements:
4 is sursprisingly the most tricky one to get right, but i think its important to be very precise and strict.
(the list is maybe not complete)
These requirements probably lead to new flags on the product. Maybe its wise to remove the old status flag and migrate it. Its maybe possible to restore the old behavior by the migration, but with more flags, so that nothing breaks or changes. But afterwards you would have better control.
The text was updated successfully, but these errors were encountered: