Maybe an edge case, but if an entity has two fields handling the same workflow, it is not possible with the event being dispatched to find out, wich field was triggered.

Comments

uniquename created an issue. See original summary.

uniquename’s picture

StatusFileSize
new2.27 KB

With this patch, also the fieldname is passed to WorkflowTransitionEvent. This makes it possible to find out wich field was triggered, if the event is being consumed.

joachim’s picture

Status: Active » Needs work

Good call!

+++ b/src/Event/WorkflowTransitionEvent.php
@@ -51,12 +58,15 @@ class WorkflowTransitionEvent extends Event {
+    $this->field_name = $field_name;

I would pass in the field definition, rather than the name string, since everything else being passed in is an object.

uniquename’s picture

Because the entity the field belongs to is also passed in, I thought the name is enough to get the field definition from the entity.

Actually I'm not sure, would this save RAM?

joachim’s picture

The field definition is probably already loaded and in a static cache somewhere, because the entity is loaded.

Passing in an object means you can type hint, which improves reliability.

uniquename’s picture

StatusFileSize
new2.54 KB

Attached is a patch, that uses the field definition.

bojanz’s picture

Title: Also handle the fieldname in WorkflowTransitionEvent » Expand the available data in WorkflowTransitionEvent
Assigned: Unassigned » bojanz

Merging #2931447: WorkflowTransitionEvent should know the transition ID into this issue.

Let's replace $from_state and $to_state with $transition. This matches the intention of the event closer, gives us access to the ID, and makes the signature parallel to that of guards. We can then deprecate getFromState() and getToState(), but keep them functional for BC reasons.

Note that the transition only has getFromStates(), but the actual "from" state can be easily retrieved using $state_item->getOriginalId(), which is what we'll do in the deprecated method. This is generally an edge casey thing to ever need (we tend to care about the transition and the "to" state).

Still unsure about $field_name VS $field_definition. Leaning towards $field_name cause that's what we do in StateTransitionFormInterface and cause I don't see anything else that can be useful in $field_definition.

(Also note that #6 passes the field item, not the field definition. Not the same thing.)

  • bojanz committed 0803a8a on 8.x-1.x
    Issue #2982709 by uniquename, joachim, bojanz: Expand the available data...
bojanz’s picture

Status: Needs work » Fixed

Went with $field_name, but also added a getField() helper.

Thanks, everyone.

joachim’s picture

> This is generally an edge casey thing to ever need (we tend to care about the transition and the "to" state).

License cares about the from state.

When an order reaches the complete state, you don't know if it's come from draft, or validation, or fulfilment.

bojanz’s picture

@joachim
My guess is that the entire License logic around activation can be replaced with code that reacts to the "order paid" event, now that we have it.
The current logic is an order of magnitude more complex than it was in D7, which is worrying.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

joachim’s picture

> License cares about the from state.

Correction: Licenses only care about the from state because the transition ID wasn't previously available, which this issue has fixed:

        // We have to check the from state, because the event can't tell us
        // the transition: see https://www.drupal.org/project/state_machine/issues/2931447
        if ($activate_on_place && $from_state == 'draft') {
          $activate_license = TRUE;
        }

> My guess is that the entire License logic around activation can be replaced with code that reacts to the "order paid" event, now that we have it.

Yes, that would simplify a few things! I've filed an issue on Commerce License to update code based on new features in State Machine.