@renatoheeb@gmail.com

I played around with the events and observed the following sequences, starting without the klaro cookie:

• A: Load: onInit, onDecline, deprecated User declines: onDecline, deprecated
• B: Load: onInit, onDecline, deprecated User accepts: onAccept, deprecated

Subsequent page loads:
Load: onInit, onDecline|onAccept, deprecated

For me it looks like the behavior is sound, as niklan mentioned in #15.3
Applying this sequence for googles consent mode, one could use the onInit event to send the default consent state (denied) and then use the onAccept event to communicate a possible consent.

Regarding the description one could write, that the consent was explicit or also implicit, e.g.:
This javascript will be executed after the user has explicitly or implicitly (page load) declined the service.

When it comes to the update script. The cautious approach would be to set the properties only, when not present. Something like:
$klaro_app->set('on_init', $klaro_app->get('on_init') ?: '');
right?

Regarding #15.2: For me this looks like a lot of work as all services would need to be migrated and probably tested. As far as I understand, they would just work like before. Why not adapt them one-by-one afterwards when needed, with people involved, who know these services well and can test them?

re₦atø → created an issue.

Closing, see my update in the issue summary.

If you need to fill up the missing data in hindsight, you can try to get them through the adjustments:

update commerce_giftcard_transaction 
set reference_type = 'commerce_order', 
reference_id = (
	select
            coa.entity_id
        from
            ((commerce_order__commerce_giftcards cocg
        left join commerce_order co on
            (co.order_id = cocg.entity_id))
        left join commerce_order__adjustments coa on
            (coa.entity_id = cocg.entity_id
                and coa.adjustments_value like '%giftcard%'
                and coa.adjustments_value like concat('%', cast(trim(amount__number) + 0 as char charset utf8mb4), '%')))
        where
            cocg.commerce_giftcards_target_id = giftcard
            and coa.entity_id is not null
        limit 1)
where amount__number  < 0  and reference_id is null and reference_type is null

Be careful, this is not bulletproof, the join is only on the amount. But this should work in most cases.

renatoheeb@gmail.com → created an issue.

Wie die Inhaltstypen (Content types) einen Inhalt beschreiben, so beschreibt ein Shipment type ein Shipment.
Ein Shipment ist in meinem Sprachgebrauch eine Lieferung. (Zur Zeit eher mit Versand/Sendung übersetzt - dieses Fass wollte ich aber nicht aufmachen).

Da es um die Typen-Definiton geht, gehört "Typ" für mich bei der Übersetzung dazu; über das davor, lässt sich streiten.

Das Versandart für die "Shipping method" scheint schon zu passen. Persönlich würde ich aber eher die "1 zu 1"-Übersetzung endend in Methode wählen.

• Shipping (im Titel) wäre für mich Versand und nicht Versandkosten.
• Package types wäre für mich Verpackungstypen

Ich sehe das wie du, ist eine Bagatelle. Man kann auch immer ins englische Interface wechseln.

Danke.

Hallo Joachim,

ich habe mir das nochmals kurz im Orginal zusammengestellt und zwei Screenshots gemacht:

In den Screenshots sieht man, dass die "ursprüngliche" englische Bedeutung nicht übernommen wurde. Im Beispiel trifft das auf alle Literale zu (inklusive Titel) und man sieht das von mir in Slack angesprochene "vieles auf *art" übersetzen.

Ich sehe nur schon an diesem kleinen Beispiel, dass Übersetzungen schwierig sind. Ich habe bei uns im Commerce-Bereich viele Begriffe angepasst und habe mich nahe ans englische Original angelehnt, auch wenn die gewählten Begriffe teilweise holprig sind. "Type" ist halt ein Typ und "method" ein Methode.

Im konkreten Fall ist es schwierig, die Menu-Einträge zu unterscheiden.

We still struggle with this issue as it seems others do (#203). For now I added an OrderProcessor with a higher priority than the EarlyOrderProcessor and force a refresh with:

    if ($this->shippingOrderManager->hasShipments($order)) {
      $order->setData(ShippingOrderManagerInterface::FORCE_REFRESH, TRUE);
    }

Anyone else troubled? Probably self-imposed . 🙈

renatoheeb@gmail.com → created an issue.

Same story here, an additional order criteria helped to solve the issue. see #3
The bug is nasty and hard to grasp: The export is working and even the number of records is matching. You have to drill into your data to see the problem.

This bug does really need more love. Also, in the first place I was wondering, why we need to batch execute an export with only 10k rows anyway ...