Rule system v2

[OliverSkroblin]

Effort: high

Description:

The current rule system is based on the data of the sales channel context and the user's current shopping cart.

For the implementation of new rules, it is often necessary to adapt the sales channel context or the shopping cart.

If the data is aggregated (product sales, etc.), an indexer is often necessary to make the data available in a performant way.

Therefore, we would modify the rule system so that the data for the validation does not come from the context but from a prepared data collection.

This is assembled before the start of the rule validation and is provided over the scope.

To be discussed:

• Remove the sales channel context completly

Benefits

• The system will be much more flexible
• It will be easier to provide more data for validation
• The initialization requires

Break strategy

We will add the new data collection in the RuleScope class:

abstract class RuleScope
{
    abstract public function getContext(): Context;

    abstract public function getSalesChannelContext(): SalesChannelContext;
    
    abstract public function getData(): RuleDataCollection;
    
    public function getCurrentTime(): \DateTimeImmutable
    {
        return new \DateTimeImmutable();
    }
}

[mazzefrie]

What is with the good old topic "HTTP-Cache" and "Rules"? Could that be includeded in a Rule Builder v2 concept as well?

[OliverSkroblin]

Reduce rule system, improve tag system

Currently, our rules access high amounts of product and customer data. The payload of cart line items continues to grow and the indexed fields at the customer are also constantly increasing.

The discussion arose to only support tags in the rules. Of course, this would mean a step backwards in the rule system, but it would increase the resources for determining the valid rules extrem.

However, in order to prevent our customers from ending up in an administration chaos of tags, the idea of a "tag builder/tag indexer" came up.

This could be implemented in several ways:

Query approach

We would create a UI for customers and products where the customer can define tag-queries (see dynamic product groups). At each tag-queries we define which tag should be added when the query matches.

Script approach

We would read the product during indexing and then call a Twig script. In the Twig script, values can then be queried on the product and the object can be tagged with several tags. A script could look like this:

{% set sales = product.sales %}

{% if sales > 1000 %}
    {% do product.tags.add('top-seller') %}
{% endif %}

{% if ... || .. %}
    {% ... %}
{% endif %}

What does it mean?

Individual rules like "Has products from category xy in shopping cart" or "Customer has already placed 10 orders" would be removed and should be realizable over the tag builder.

Generic rules like "Line Item has weight > xxx" would stay

[AndreasA]

Personally, I would also like it if you add support for dependency injection by separating rule payload and rule matcher, similar to constraints and validators in Symfony validator.
However, if the rule data option is available it isn't that important anymore.

However, it could still be helpful and performance should not be an issue as that is up to the developer for a corresponding rule - e.g. I can do slow operations inside the match method already without needing dependency injection - e.g. calling external services or just a plain sleep.

[OliverSkroblin]

I understand the point that you would like to use services in the rules, unfortunately they are not designed for that and we don't want to change that in the future.

Of course there is already the possibility to program rules slowly, but if we open the window for service injection, this would lead even faster to the use of services and the execution of intensive operations.

[AndreasA]

@OliverSkroblin Well as long as one can easy extend the rule payload with custom data from services, it is fine I think which I think the suggestion at the beginning of the proposal would take care of (RuleDataCollection)? If there are corresponding events,.

[OliverSkroblin]

I think I would like to split the rule system, so that there are rules responsible for delivering content and rules needed for the shopping cart.

This would allow us to evaluate the rules for content independently of the shopping cart. The shopping cart would then only need to be loaded when it is actually needed. My goal would be that listings and detail pages no longer require the shopping cart, so that they can be cleanly cached.

The current HTTP Cache rework is already heading in that direction, but it has more of an approach to 'marking' these rules. However, this doesn't prevent the rules from being evaluated.

I think I'll rewrite the proposal and focus on splitting the system for content and the shopping cart, as well as how the migration strategy and extensibility look in this regard.

[OliverSkroblin]

See: #3406