Skip to content
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

Open
macrozone opened this issue Mar 4, 2021 · 3 comments
Open

[FEATURE REQUEST] delete / hide products #333

macrozone opened this issue Mar 4, 2021 · 3 comments
Labels
feature request Suggest an idea for this project
Milestone

Comments

@macrozone
Copy link
Contributor

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:

  1. As a shop admin I want to control whether a product appears in lists
  • products that do not have this flag should still be accessible through direct call, but never through search (something like "discoverable"?)
  • products without this flag behave like normal products otherwise
  1. As a shop admin I want to control whether a product can be ordered
  • usually products that are hidden by 1) can also not be ordered, but this should be controled by an independent flag
  • these products cannot be checked out, but everything else stay the same
  1. As a shop admin, I want to delete products, so that they won't appear to customers
  • deleted products this way should not be accessible by non-admins, neither through direct call nor list
  • deleted products this way should only be accessible by admins if the request contains a special flag (includeDeleted), both for lists and single Query.product
  • deleted products this way are not accessible through orders or similar (they are null)
  1. as a shop admin I want to hide newly created products, so that i can review them
  • they do not appear to non-admins in list or detail view
  • admins see these products in list or in detail view without a special flag as if they were published
  • once published, products can never be unpublished
  • (or less strict): once published, products can only be unpublished if they do not appear in orders, otherwise i get an error. I have to delete them (3) if I want to hide them

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.

@macrozone macrozone added the feature request Suggest an idea for this project label Mar 4, 2021
@schmidsi
Copy link
Member

schmidsi commented Mar 4, 2021

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:

  • I like the discoverable flag. Pretty straight forward what's going on.
  • A further flag would be orderable. For example, a product was listed once but now not offered anymore. It should stick around, because it could be that somebody ordered it. But it will be marked as non-discoverable and non-orderable

@macrozone
Copy link
Contributor Author

@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)

@pozylon
Copy link
Member

pozylon commented Mar 8, 2021

Very interesting topic but I think we still haven't found a sustainable way to tackle these problems yet.

I agree with the requirements:

  • As a shop admin I want to control whether a product appears in lists
  • As a shop admin I want to control whether a product can be ordered
  • As a shop admin, I want to delete products, so that they won't appear to customers

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:

  • Hiding products from lists is already possible by using a filter plugin we just have to document that more
  • Completely removing products so that they are not accessible by _id is something that is usually not required but could be done like @macrozone said for accidential publications. I suppose for these edge cases we could add a "permanent delete" feature that is available as long as the product has not been added to any cart or wishlist?
  • Accessability (Legal blockings or any kind of user-defined product), Search-Discoverability and Orderability could be done by a plugin system that controls aspects of single products. Maybe a default plugin could be written that uses the proposed flags to achieve that.

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.

@pozylon pozylon added this to the v3.0 milestone Dec 6, 2022
@pozylon pozylon moved this to v3.0 (Q3 / 2023) in Roadmap Dec 6, 2022
@pozylon pozylon added this to Roadmap Dec 6, 2022
@pozylon pozylon modified the milestones: v3.0, v3.1 Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Suggest an idea for this project
Projects
Status: v3.0 (Q3 / 2024)
Development

No branches or pull requests

3 participants