Acum că am discutat despre produse, este timpul să trecem la comenzi. Îmbunătățim multe aspecte ale comenzilor pe baza feedback-ului anterior. Unul dintre aceste aspecte este conceptul de stări și stări ale comenzilor.

În Commerce 1.x, comenzile au un statut. Starea indică pagina curentă de checkout, dacă comanda este un coș, dacă a fost plătită și îndeplinită (expediată) sau poate anulată/rambursată. Stările sunt secvențiale și una după alta. Ele sunt grupate pe stări, de exemplu, toate statusurile de verificare aparțin stării "checkout".

Problema cu acest model este că o listă de stări indică mai multe concepte (starea de checkout, starea de plată, starea de îndeplinire etc.). Aceste concepte sunt paralele și încercarea de a le gestiona secvențial creează erori și confuzie. De exemplu, o comandă ar putea fi plătită înainte sau după finalizarea procesului de checkout din cauza naturii asincrone a anumitor gateway-uri de plată sau pentru că afacerea își facturează clienții la sfârșitul lunii. În plus, sistemul nu impune cerința ca statutul să se schimbe secvențial; acesta poate fi setat la orice alt statut în orice moment. De asemenea, nu există nicio modalitate de a exprima reguli precum "numai comenzile finalizate pot fi rambursate" sau "comenzile finalizate nu pot fi trimise înapoi la checkout".

Cerințele noastre pentru Commerce 2.x au fost:

  • Îndepărtarea distincției neclare dintre status și stat. Să aibă doar state.
  • Împărțirea fluxului de lucru al comenzilor în mai multe fluxuri de lucru (comandă, checkout, plată, îndeplinire) plus un câmp boolean care să indice "este această comandă un coș",
  • Permiteți ca diferite tipuri de comenzi să folosească diferite fluxuri de lucru (un tricou ar putea trece prin diferite stări decât un bilet DrupalCon).
  • Furnizarea unui API pentru exprimarea tranzițiilor permise între stări, permițând o mai bună interfață de utilizare și validare.

Pentru a rezolva acest lucru la nivel de API, am introdus conceptul de flux de lucru, care este o colecție de stări (id, etichetă) și tranziții (id, "de la" stări, "la" stare, etichetă). Am creat, de asemenea, grupuri de fluxuri de lucru, o modalitate de a grupa fluxurile de lucru utilizate în același scop (fluxuri de lucru pentru comenzi, fluxuri de lucru pentru plăți, fluxuri de lucru pentru marketingul produselor etc.). Fluxurile de lucru și grupurile vor fi definite în cârlige în D7. Deoarece este vorba de D8, acestea sunt definite în yaml, la fel ca și legăturile de meniu.

mymodule.workflow_groups.yml:

order:
  label: Order
  entity_type: commerce_order

mymodule.workflows.yml:

default:
  id: default
  label: Default
  group: order
  states:
    new:
      label: New
    fulfillment:
      label: Fulfilment
    completed:
      label: Completed
    canceled:
      label: Canceled
  transitions:
    create:
      label: Create
      from: [new]
      to:   fulfillment
    fulfill:
      label: Fulfill
      from: [fulfillment]
      to: completed
    cancel:
      label: Cancel
      from: [new, validation, fulfillment]
      to:   canceled

Aceste exemple sunt prescurtate pentru a fi scurte, fluxul de lucru real al comenzilor va avea stări și tranziții suplimentare. Tranzițiile pot fi limitate în continuare prin clase de protecție, cum ar fi aceasta.

Starea curentă este stocată într-un tip de câmp special (StateItem), care face referire la fluxul de lucru utilizat și acționează ca o mașină de stare. Acesta dispune de o API pentru obținerea tranzițiilor permise:

<?php
$order_state = $order->getState();
print $order_state->value; // fulfillment
// Get the allowed transitions for the current state.
$transitions = $order_state->getTransitions();
// All transitions have a translatable label that can be shown in the UI (great for action buttons)
print_r($transitions['completed']->getLabel());
// Same as $order_state->value = 'completed';
$order_state->applyTransition($transitions['complete']);
?>

Este furnizat un validator corespunzător care asigură că a fost setată o stare validă, luând în considerare și valoarea anterioară.

Cum se pune totul cap la cap

Deoarece aceste API-uri nu sunt specifice comerțului, le-am plasat într-un modul State Machine nou creat. README oferă o prezentare mai detaliată a funcționalității oferite. Începând din această dimineață, codul este, de asemenea, disponibil pe drupal.org, cu o versiune beta planificată pentru săptămâna viitoare.

Cu ajutorul acestui modul, viitorul arată astfel:

Acestea sunt fluxurile de lucru implicite, concepute pentru a fi generice și suprascriptibile pentru fiecare tip de comandă. Bineînțeles, stările și tranzițiile acestora s-ar putea schimba în cadrul viitoarelor versiuni preliminare. Cel mai interesant flux de lucru de aici este fluxul de lucru al comenzilor. Să ne uităm la stările disponibile:

  • nou: Nu a fost plasată încă (în checkout sau în curs de editare de către administrator)
  • validare: În așteptarea validării (revizuirea unui scor de fraudă, verificarea prin e-mail de către client etc.)
  • fulfillment (îndeplinire): În așteptarea îndeplinirii (trimiterea tuturor pachetelor relevante)
  • finalizat: Completat și nu mai poate fi modificat.

Unele stări pot fi sărite cu Reguli (sau cu un abonat la un eveniment) dacă nu sunt necesare. Vom avea, de asemenea, o stare de anulare (de la new/validation/fulfillment) și o stare de rambursare (formular completat).

În concluzie, am îmbunătățit în mod dramatic un API foarte vizibil pentru dezvoltatori. De asemenea, am lăsat loc pentru o posibilă interfață utilizator în viitor (în contrib). Săptămâna viitoare ne vom uita la coșuri și la tipurile de articole de comandă/linie.

https://drupalcommerce.org/blog/43169/commerce-2x-stories-workflows