-
-
Notifications
You must be signed in to change notification settings - Fork 436
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
Fixed Mage_Catalog_Model_Product_Status::addSaleableFilterToCollection() does nothing #2603
Conversation
I've added to this PR the fix for Mage_Catalog_Model_Product_Status::addVisibleFilterToCollection(), which historically was doing exactly the same thing as addSaleableFilterToCollection(), but was commented and deprecated years ago. |
Maybe there is/was a reason be able to sell diabled products?
There was some commented code in
|
you can't anyway, the order won't go through
I don't think that's a good idea to have a class called "something_product_status" modify the product_collection, which is probable why it was removed and deprecated 3000 years ago. |
Agree with this pr, but i also like idea of |
Maybe there should be an option in the store configuration that allows to create orders containing disabled products as well. By default it should be disabled because when the decision is made to disable a product it is done for several solid reasons:
In the first case, I should be able to create an order as an administrator even if I deliver it in say 3 months. It is like a pre-order, an agreement between me and the customer. |
I think that if "they" wanted to have disabled products in the order they would have removed the call to Mage_Catalog_Model_Product_Status::addSaleableFilterToCollection() instead of commenting its content. I've found myself many times trying to filter disabled products from a collection and getting frustrated because every piece of code you can find on the internet tells you to use Mage_Catalog_Model_Product_Status::addSaleableFilterToCollection() which doesn't work. It is true, somebody could want disabled products in orders, which is wrong btw, otherwise disabling a product has no meaning anyway, if you just want to hide it from the frontend just use the visibility. I also think that a disabled product shouldn't be "reordered" (using the reorder funcionality in the frontend). At the same time we could have many more people having to check thousands of disabled products while creating an order and get frustrated that openmage keep showing those products (which can't even be filtered out). |
Looks good to me, but how about using Same thing can be said for |
…oCollection() that does nothing
Good idea @elidrissidev, I've converted the code! |
app/code/core/Mage/Adminhtml/Block/Sales/Order/Create/Search/Grid.php
Outdated
Show resolved
Hide resolved
app/code/core/Mage/Catalog/Model/Resource/Product/Collection.php is adding a status filter: You again apply same kind of filter to: app/code/core/Mage/CatalogSearch/Model/Layer.php This is colliding with app/code/core/Mage/Catalog/Model/Resource/Layer/Filter/Price.php: As it is trying (not very smart) to replace any e.status with 1=1, creating an invalid mysql query. I really cant tell why this is not creating trouble for others, but code speaks for itself. |
@leissbua Do you face this issue in the latest release? The duplicate filter was already removed #2662. Additionally, #2660 was opened afterwards to address the naive condition replacement. Edit: |
This is happening in the latest release and all previous releases i checked (19.4.21): |
Can you share reproduction steps? although I don't run the recent OM versions in production, I've used many times locally including the search, but never came across this issue. |
Enable flat catalog, do a search, get an invalid query. I think code speaks for itself, same reason you removed the additional status in-Filter in catalog. |
Already did those exact steps, and even made sure the code is going through the The query I get seems valid: SELECT `e`.`entity_id`, `e`.`type_id`, `e`.`attribute_set_id`, `e`.`name`, `e`.`short_description`, `e`.`price`, `e`.`special_price`, `e`.`special_from_date`, `e`.`special_to_date`, `e`.`small_image`, `e`.`thumbnail`, `e`.`news_from_date`, `e`.`news_to_date`, `e`.`status`, `e`.`url_key`, `e`.`required_options`, `e`.`image_label`, `e`.`small_image_label`, `e`.`thumbnail_label`, `e`.`msrp_enabled`, `e`.`msrp_display_actual_price_type`, `e`.`msrp`, `e`.`tax_class_id`, `e`.`price_type`, `e`.`weight_type`, `e`.`price_view`, `e`.`shipment_type`, `e`.`links_purchased_separately`, `e`.`links_exist`, `e`.`open_amount_min`, `e`.`open_amount_max`, `price_index`.`price`, `price_index`.`tax_class_id`, `price_index`.`final_price`, IF(price_index.tier_price IS NOT NULL, LEAST(price_index.min_price, price_index.tier_price), price_index.min_price) AS `minimal_price`, `price_index`.`min_price`, `price_index`.`max_price`, `price_index`.`tier_price`
FROM `catalog_product_flat_1` AS `e`
INNER JOIN `catalog_product_index_price` AS `price_index` ON price_index.entity_id = e.entity_id AND price_index.website_id = '1' AND price_index.customer_group_id = 0
WHERE (e.status = 1) AND (e.status IN(1)); Ignoring the fact there is an additional redundant condition, since I'm trying to identify how the issue happens first. |
It is valid, because there is no entity_id in condition: It replaces and that gives:
If you have another condition like:
it ends as
-> Invalid query |
I think I did something about this "1=1" thing, which I really don't like, but that wasn't approved, I can't find it at the moment. |
Here #2660 |
Ok, how do we want to handle the situation, from my pov this needs to be fixed / removed: magento-lts/app/code/core/Mage/CatalogSearch/Model/Layer.php Lines 64 to 66 in 112f5a0
|
I agree that the 1=1 is just stupid/dumb code and could be resolved. The case that e.status gets added twice is bad and additonally duplicates the entity_id in case as well. As the status Filter has been removed in catalog/model/layer.php states that it clearly should be removed in the search layer as well. |
if you could give a review to #2660 that would be great, I want to see that horrendous "1=1" thing go away |
Try to create a new order from backend, select the customer, the store view and the try to "add product", the products shown on the grid that appears should be the saleable products, but they're not, they're both enabled and disabled products.
Why?
In
app/code/core/Mage/Adminhtml/Block/Sales/Order/Create/Search/Grid.php
there's a call towhich is deprecated and empty:
This PR fixes all the calls to addSaleableFilterToCollection methods.
Question, I would also remove the method but it will for sure break some installations, should we keep it as it is? althoguh the functionality is broken since years?