Elasticsuite: Set "special_price" attribut to "filterable" generate exception

[zkliouel]

Hi,

Follow the stacktrace below :

Exception #0 (BadMethodCallException): Missing required argument $name of Smile\ElasticsuiteCore\Search\Request\Aggregation\Bucket\Histogram.

Exception #0 (BadMethodCallException): Missing required argument $name of Smile\ElasticsuiteCore\Search\Request\Aggregation\Bucket\Histogram.
#0 /var/www/project/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(82): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->_resolveArguments('Smile\\Elasticsu...', Array, Array)
#1 /var/www/project/vendor/magento/framework/ObjectManager/ObjectManager.php(57): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->create('Smile\\Elasticsu...', Array)
#2 /var/www/project/var/generation/Smile/ElasticsuiteCore/Search/Request/Aggregation/Bucket/HistogramFactory.php(43): Magento\Framework\ObjectManager\ObjectManager->create('Smile\\Elasticsu...', Array)
#3 /var/www/project/vendor/smile/elasticsuite/src/module-elasticsuite-core/Search/Request/Aggregation/AggregationFactory.php(58): Smile\ElasticsuiteCore\Search\Request\Aggregation\Bucket\HistogramFactory->create(Array)
#4 /var/www/project/vendor/smile/elasticsuite/src/module-elasticsuite-core/Search/Request/Aggregation/AggregationBuilder.php(91): Smile\ElasticsuiteCore\Search\Request\Aggregation\AggregationFactory->create('histogramBucket', Array)
#5 /var/www/project/vendor/smile/elasticsuite/src/module-elasticsuite-core/Search/Request/Builder.php(157): Smile\ElasticsuiteCore\Search\Request\Aggregation\AggregationBuilder->buildAggregations(Object(Smile\ElasticsuiteCore\Search\Request\ContainerConfiguration),

I finaly found that setting special_price attribut filterable is not managed in the mapping.

Best Regards

[romainruaud]

Hello,

we will not "fix" this one since there is no need to set the special_price attribute to filterable : the price displayed by the price slider in front-office already takes the special_price value into account (since we are using the price index table values).

We will think about preventing the special_price attribute from being set to filterable to prevent any issue.

Regards and thank you for submitting this one.

[zkliouel]

Hello,

I don't understand why ? I you do that i consider this module not compatible with native magento...
For me if an action that i can do in the native BO magento is broken by installing this module it's a critical bug.
Furthermore the price indexation is based on the minimal price of product and the module index only one price for the product (by customer group) so not both prices are indexed.

Regards

[romainruaud]

About setting the special price as filterable that breaks the frontend : we will forbid to do such a thing.

About all prices not being indexed, see PR #331

I let @afoucret give you more explanations on this one

[romainruaud]

I close this one since we wont provide any fix for it.

Feel free to propose a PR if you implement it on your side.

Regards,

[dersam]

On our store, we use the price attribute type for data that should be expressed as a range, but is not a price. As far as I can tell in Magento 2, there is no other way of expressing this besides the price type.

The example in question: bike chains have a range of possible lengths. Obviously, we want this filterable, and there is no other way to express it besides a price type, but elasticsuite's current behavior breaks it.

Forbidding this is not a solution, as we're importing this data from Magento 1. Even if we weren't, this still breaks a normal functionality of Magento. I'm in agreement with @zkliouel that this isn't reasonable. Elasticsuite should handle this situation gracefully, as it is a behavior Magento allows.

However, if there's another way to handle this with Elasticsuite, I'm open to it.

[romainruaud]

Hello @dersam

If you plan to have attributes rendered as a slider/range, you could also use the "decimal" type, which is displaying a slider in Front Office. This is exactly to manage cases like "technical" data (bike chains, or sleeve length, or snowboard width, etc....) that we added this ability.

What you are describing here is not related to @zkliouel issue at all which is speaking specifically about the special price attribute, which is indeed related to other price related configurations, such as customer group and even tax class mechanics, and also with the fact that the price being used for indexing (the final price) is already the special price if one exists.

Please give a try to decimal attributes for displaying your ranges and let met know about it.

Best regards,

[dersam]

The decimal attribute type doesn't exist; see below. Is it a new attribute type that elasticsuite is supposed to provide?

However, I think using a different attribute type is beside the point. Elasticsuite is breaking on a simple configuration that vanilla Magento 2 allows and has no problem with. Not only that, there is no indication in the documentation that price attributes are a problem - it simply fails with an unclear error message.

Forbidding creation is not a good solution. There will be plenty of pre-existing data that will break, despite working normally without Elasticsuite. It raises concerns for what other configurations might crash when using this module if the official response is going to be "don't do that", and fail to handle them gracefully.

[romainruaud]

About setting "special_price" as filterable : this is a non-sense. The special price is already included in the price.

About what I called "decimal" attributes, here is a quick how-to about how I am using them :

First, I create my attribute. Let's call it "Temperature".

I create it as text attribute :

I set this input type to decimal :

I configure Storefront related properties :

I hit Save and Continue edit. Then I go back to StoreFront properties. A new section called "Slider display" appears :

I set the precision and the display pattern. Here I am using a display with Celsius degrees.

I then set a value for "temperature" attribute to some Hoodies.

Then I search for them in front and... voila : http://demo.magento-elastic-suite.io/index.php/catalogsearch/result/?q=hoodie

The filter is appearing with a Slider .

I agree that this part is not well documented, I will add it to the Wiki to avoid misunderstandings.

Best regards,

[dersam]

Thanks for the explanation, I'll give it a try and see if that solves my issue.

I should note that both attribute type and input validation cannot be changed in the admin once the attribute is created. In my use case, I'm converting a Magento 1 store to Magento 2, which means I have 7+ years worth of data and over 100 pre-existing attributes. I will have to work out a way to identify the attributes that need to be updated for Elasticsuite to handle them correctly. I also have plenty of attributes that are configured in a way that Elasticsuite forbids on the frontend, but can't handle because the attribute config was pre-existing.

The particular case of special_price isn't relevant to the issue I have - I agree that it doesn't make sense. However, Magento 1 didn't have any other way to represent decimal attribute values besides price, which means I have a number of price type attributes that aren't really prices simply because that was the only option (see my previous bike chain example).

That's the reason I'm advocating that additional price attributes should be handled gracefully. Some attributes don't make sense, but others _aren't really prices_, and are just relics of a Magento 1 compromise.

For those of us migrating to Magento 2 and looking to use Elasticsuite, more graceful handling of relics like this would be very appreciated, as it reduces the amount of data wrangling necessary.

[romainruaud]

Well you are right.

The only point which is clear here is : we should handle any newly created attribute with "price" type as being properly filterable.

I'll take a look