[Core][Originator] Base on promotion codes instead of originator

[Zales0123]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	yes
Related tickets
License	MIT

As Promotions have now unique codes, there is no need to use separate service to determine origin of promotion (or any other adjustment).

[michalmarcinkowski]

Looks good! 👍

Since we have adjustments applied on different levels, what do you think about adding one more scenario for item promotion?

[lchrusciel]

According to spec it should be string instead of int

[Zales0123]

@michalmarcinkowski ok, I fact there is no possibility for such scenario 😄 we have now two types of unit promotions - fixed and percentage and both uses price range and taxon filter. Therefore, to revert promotion we should modify specific product taxon or price (!), which I think is not the point in this case ;)

[pjedrzejewski]

🎆

[michalmarcinkowski]

@Zales0123 there is possibility! 😄 We can use order promotion rule together with item promotion action, e.g.: Given the promotion gives 5% off on every product to every order with items total at least "€80.00"

[dantleech]

This change couples adjustments to promotions? What if an adjustment is made by a non-promotion?

[dantleech]

Hmm. Now I wonder if I should be using promotions ...

[michalmarcinkowski]

It doesn't couple adjustments with promotions. Promotions just use originCode field from adjustment to be able to recognize them. Non promotion adjustments are not affected by this change (we already have also e.g. tax adjustments).

[dantleech]

ok, yes I see now. so I can still reference something with the combination of the type and origin_code. Thanks :)