Move price tracking to late order processor

Made a quick stab at the late-order processor. I do use cart flyout, so form alter is not for me.

BOGO offers - and the same applies to any custom gift logic that someone had - we skip and order items whose adjusted price is zero

Think we should take care of adjusted price 0 and skip it. If there is a BOGO offer where you get the product at a 50% discount, that still should be considered as the lowest price.

Follow up, the order processor needs to be treated as a regular one, but to run after taxes.

If we do a late order processor (as commerce_shipping has), it's not going to trigger on initial price calculation on price load - and we need it there, to react in the same place as do the add-to-cart form. (processors not tagged with adjustment types are separately loaded only if there is an order present - and we need to track price history regardless if anyone added it to the cart)

And think my last update :-D

Think we need to do, in terms of EU regulation:

• Keep only tracking for anonymous users in order processor (as is now) - logged-in users can fit "personalized discounts"
• Keep only tracking when a user does not add anything to the order - once a user creates his order, he can apply coupons, etc.. - again which means it's a personalized discount. And as well we don't have any BOGO problems

I would keep it simple for the sake of EU regulation first, and then later add more flexibility for the sake of general price history tracking (aka. logged-in users, coupons, etc..)

Per my understanding of regulative - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021XC1229(06)
Merchants are not required to track:

• BOGO offers like - buy 1, get 1
• Loyalty discounts/cards - gift card, special discounts for logged-in users
• Personalized discounts - coupons and logged-in users as well could fit that criteria
• Discount for specific groups or payment methods - again, logged-in users/roles. And as well reason to not track prices from actually orders

We have a client who confirmed they need the loyalty discounts (role-driven discount) to be included in the "lowest price in 30 days" to comply with the regional implementation of the Omnibus directive. This is likely due to the Loyalty Club (Member Club) being available to anyone if they register to the site. Whether this is required or the merchant wants to be pro-actively compliant is difficult to assess but they're backing this up based on the following quote:

Priser som er tilbudt til medlemmer av kundeklubben og lignende de siste 30 dagene skal også tas med i denne beregningen.

https://www.minmote.no/nyheter/a/mQ2a0l/nye-eu-regler-butikker-maa-vise-...

Maybe we can simplify this logic with config settings or general settings

So that shops can opt-out or opt-in for full tracking.

I am more in favor of opt-in because opt-out means by default everything is tracked

I see two different problems in fact

- tracking all roles - think we need to have an option for that ($order->getCustomer()->isAnonymous())
- tracking active orders - etc. when the user applies a coupon ($order->id() > 0)

The latter as well is also important because there are cases when XYZ customer care gives coupons with high percentages to customers,
for XYZ problems with the last purchase. And that should not be tracked as lowest price.

     if (Settings::get('commerce_price_history_track_roles', FALSE)) {
      // Track only anonymous prices.
      // Logged-in user and different pricing can be considered as
      // personalized pricing.
      if (!$order->getCustomer()->isAnonymous()) {
        return;
      }
    }

    if (Settings::get('commerce_price_history_track_coupons', FALSE)) {
      // Skip processor for once a user add items to the order -
      // we only need track price not affected with coupons, so promotions
      // without coupons. Once a user add a coupon, means it need's to have an
      // proper order.
      if ($order->id() > 0) {
        return;
      }
    }

Expanded upon existing code to add settings form to be configurable to which roles are tracked, which product variation types are tracked, and if prices affected by coupons should be tracked. (as well as returned the previous version of price checking because had some duplicate entries)

Because I only need to track anonymous users, I did not expand further on other implementation details - calling proper user context on all places for non-anonymous users.

The settings form currently looks like this and the following settings are;
- user role - which user role to track
- variation types - which variation type to exclude (as in my case, I have bundles)
- option to turn on tracking prices affected by coupons