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

[16.0] Improve partner applicability on loyalty programs #238

Open
lmignon opened this issue Jan 22, 2025 · 5 comments · May be fixed by #265
Open

[16.0] Improve partner applicability on loyalty programs #238

lmignon opened this issue Jan 22, 2025 · 5 comments · May be fixed by #265
Labels
enhancement New feature or request

Comments

@lmignon
Copy link
Contributor

lmignon commented Jan 22, 2025

Context

The OCA addons loyalty_partner_applicability and sale_loyalty_partner_applicability allow you to restrict the applicability of loyalty programs to specific partners. This is useful when you want to apply a loyalty program only to a subset of your partners. In the current implementation, the restriction is based on a domain applicable to the partners specified at the loyalty rule level. When the system check if a program can be applied to a sale order, it search for all the valid programs and then iterate on each rule to check if the partner is applicable. The program is therefore applicable if at least one rule is applicable to the partner of the sale order.
Moreover, rules not applicable to the partner are also applied as long as at least one rule is applicable for the same program. Without knowing the motivation behind the current implementation, this looks like a strange behavior to me.

Proposal

I would change the implementation to allow to specify the partner applicability at the program level. This would allow to have a more efficient implementation to check if a program is applicable to a sale order and also simplify the configuration by enforcing the concept of partner applicability at the program level. This change will not change the behavior of the current implementation
but place the concept of partner applicability at the right level according to the current behavior.

In the same time, I would also allow to restrict the applicability to a specific list of partners. Sometimes, you want to apply a program to a specific set of partners that can't be defined by a domain.

What do you think about this change? @Tecnativa @pilarvargas-tecnativa @chienandalu @ernesto-garcia-tecnativa @pedrobaeza

@lmignon lmignon added the enhancement New feature or request label Jan 22, 2025
@pilarvargas-tecnativa
Copy link
Contributor

Hello @lmignon

Currently, Odoo's promotion applicability behaviour is that if a rule is met, then the promotion is applicable. The restriction on the applicability of the promotion lies in the configuration of the rules. You have the same case if you define several rules on products. As soon as one of them is fulfilled, the promotion is applicable.

For example:

  • Rule 1: minimum purchase amount of $50 on any product.
  • Rule 2: minimum purchase of 2 products.

If I buy 2 products and the amount is less than 50 the rule applies and if I buy 1 product for an amount of 50 or more the rule applies.
So I don't see the need to apply restriction at the program level because they will never take into account that all the rules are fulfilled to apply the promotion. You simply have to have the rules configured correctly.
On the other hand, I think any domain can cover the case of a set of partners. There is always some data to look for X partner.

Regards

@lmignon
Copy link
Contributor Author

lmignon commented Jan 22, 2025

Hi @pilarvargas-tecnativa

Sorry but I should miss something. The behaviour is not the one you describe. You can easily reproduce the problem.

  1. Create a program of type 'Loyalty Cards'
  2. Create a rule for the product 'Large Cabinet' applicable to partner like 'azure'
  3. Create a rule for the product 'Storage Box' applicable to partner like 'ready'

Create a SO for Azure with 1 line for product 'Storage Box' and confirm it. -> The rule for 'Storage Box' applicable to 'ready' is applied to Azure

The rule define how to compute the point earned on condition related to the product. In your implementation you use the partner domains specified at rule level to know if a program can be applied to the current SO (https://github.com/OCA/sale-promotion/blob/16.0/sale_loyalty_partner_applicability/models/sale_order.py#L59) but rules restricted to others partners are never filtered out from the rules evaluated by the odoo's code. (https://github.com/odoo/odoo/blob/16.0/addons/sale_loyalty/models/sale_order.py#L879). At least this seems to be a bug

In my case, I need to define loyalty programs for a whole year for specific contacts. These programs concern several hundred products and the number of points awarded varies according to the products. It seems logical to me to be able to define the beneficiaries at program level in the same way as we do for the validity period. This will avoid having to load and evaluate programs from which the customer passing his SO is excluded.

If you need to restrict a rule specifically to some customer, the code must be fixed. In the current state, if I move the restriction on partners at the program level, the behavior will be the same.

I can also add the functionality of defining a restriction a program level and fix your code to work as you expect it should work.

Regards

@pilarvargas-tecnativa
Copy link
Contributor

Hi @lmignon

The original behaviour in v15 was that a promotion that met all its rules was applicable to X partner. In v16 all rules are evaluated, it is not known for sure which rule is being fulfilled in order to evaluate the rule + the partner. What this module does is to check if after the promotions fulfil their rules it is applicable to the partner or not, similar to v15 (as if it was done at promotion level, so it is only necessary to set the domain for partners in a rule). Similarly for a coupon code. Even if there are several rules, the set of partners of all of them will be taken into account. The solution is to have independent promotions. Having to evaluate that the rule + partner is fulfilled would imply overwriting the method that makes these checks with the disadvantage that the rest of modules that extend this method to add more conditions are not going to be checked to fulfil the rule + partner.
Those are the limitations of Odoo in v16 but the behaviour with a well configured promotion is the same as in v15 although a PR with improvements is always welcome.

Regards

@lmignon
Copy link
Contributor Author

lmignon commented Jan 22, 2025

@pilarvargas-tecnativa

Here is what I propose:

I'll fix the current implementation to filter out rules from pogram if a restriction on the partner is specified at the rule level and the partner on the so doesn't conform to the provided domain. This will be done by:

  1. overriding the method _program_check_compute_points from the `sale.order' model to call super with the order record into the context

class SaleOrder(models.Model):
     _inherit = "sale.order"

    ....

    def  _program_check_compute_points(self, programs):
        self.ensure_one()
        return super()._program_check_compute_points(programs.with_context(order=self))
  1. overriding the method _get_valid_products from the loyalty.program model to to remove from the rules dictionary, the rules restricted to partners that doesn't match the partner from the order into the context.
  2. remove the method _is_valid_partner or remove it's current behavior and add a deprecation warning into the sale.order model.

I'll add the functionality to define the restriction on the partner at the program level.

I also propose to add a migration script to merge the declared restriction on partner at rule level to the program to ensure a smooth migration to the new version.

Is-it Ok for you? (ping @pedrobaeza )

@pilarvargas-tecnativa
Copy link
Contributor

@lmignon OK by me, go ahead. Thank you!

@lmignon lmignon linked a pull request Jan 27, 2025 that will close this issue
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants