Hi all,
As some of you may be aware of, I've been working on improving the offer module for some time now. I cleaned up the proxy resolution, allowed multiple benefits per line item, and have now pending the definition of allowed combinations of offers. I noticed
someone else already backported our code to define excluded categories on ranges. Thanks Diederik. Excellent!
Specifically I'm now looking into https://github.com/django-oscar/django-oscar/issues/2788 where repeated consumption of basketlines are marked as problematic.
Working on this issue the state of the offer implementation coming into focus more and more, which I'd like to share with you for further feedback and discussion.
Currently I'm operating on following hypothesis:
To wit,
Which means,
Of course, being about mechanisms means that it must accommodate rich policies.
What I'm currently struggling with is two fields that touch on policy: offer.max_applications and benefit.max_affected_items
It would seem to me that both try to implement the same limitation: the number of line items that may be affected by an benefit. It seems to me that max_applications is an incomplete attempt at imposing restrictions of applying benefits that rely on too
many side-effects, and breaking the idem-potency rule I'd like to enforce. The benefit.max_affected_items does look like a promising and useful feature to limit benefit applications, and I'd like to make that one the core variable to enforce such limits.
I would appreciate if you could share with me your usage of max_applications and max_affected_items to I can validate (or discard) my assumptions.
have a nice weekend!
-- Lab Digital Paul J Stevens | Systems Engineering M: +31 (0)62 460 6876 T: +31 (0)85 060 3980 Kanaalweg 14-G, 3526 KL Utrecht
And what's up with codecov/changes failures? Overall coverage improved, but that single check still complains. How useful is that, or not?