Problem/Motivation

As is stands now, activationStatus is a dynamic value determined by conditions plugin. Because it is dynamic, we are not able to set the activation value via config overrides. We need a way to handle when the activation method is static vs dynamic so developers can handle feature flags that activated based off environment.

Proposed resolution

Add Two new fields to the entity, settings and schema:

  • activationMethod - string : Used to determine what type of activation method is being used for determining if the switch is activated.
  • manualActivationStatus - boolean : Used to determine, for activation methods that are manual, are they activated?

Remaining tasks

  1. update entity with new fields
  2. update schema with new fields
  3. update settings form with new fields
  4. update getters and setters
  5. update getActivation forked logic

User interface changes

Setting form will have two new fields.

API changes

Update getActivation().

Data model changes

Add two new fields.

Comments

robpowell created an issue. See original summary.

robpowell’s picture

StatusFileSize
new6.48 KB

Since we are making schema changes w/o an update hook, you have to uninstall module, update code and then re enable.

known issues:

  • Entity form saves but on edit it doesn't display values

Next steps

  • resolve Entity form saves but on edit it doesn't display values
  • Test manual switch< /li>
  • Test conditional switch
  • Test config override manual switch< /li>
  • Test config override conditional switch
slucero’s picture

Nice work on this! I ran through and added some comments below on different sections, but this looks like it's coming along great and going in a good direction.

  1. +++ b/config/schema/switch.schema.yml
    @@ -21,3 +21,11 @@ switches.switch.*:
    +    activationMethod:
    +      type: string
    +      label: 'Activation Method'
    +      nullable: true
    

    Should this be an optional value? I think if it's not available we're going to run into some complications trying to determine how to check activation status.

  2. +++ b/src/Entity/SwitchEntity.php
    @@ -124,6 +140,42 @@ class SwitchEntity extends ConfigEntityBase implements SwitchInterface, EntityWi
    +    if ($this->isManualActivationMethod()) {
    +      return $this->set('manualActivationStatus', $status);
    +    }
    +
    +    // @todo: determine if there is a better way to handle when it is a conditional.
    +    // E.G., on the interface we are saying return $this, however if the switch
    +    // is conditional, we will not make the change.  This could be confusing for
    +    // developers.
    ...
    +
    

    I think we should always set the value for this field regardless of the activation method setting. As a developer I would expect this to be the case, and I could debug why the activation method is set as it is separately.

    So for this section I would simplify this setter method back to just the assignment and returning `$this`.

  3. +++ b/src/Entity/SwitchEntity.php
    @@ -169,23 +221,40 @@ class SwitchEntity extends ConfigEntityBase implements SwitchInterface, EntityWi
    +    if ($this->isManualActivationMethod()) {
    ...
    +  protected function isManualActivationMethod() {
    +    $activationMethod = $this->get('activationMethod')->value;
     
    -    return FALSE;
    +    return ($activationMethod == 'manual') ? TRUE : FALSE;
       }
    

    Thoughts on simplifying this method out and using a `switch` over the result of `get('activationMethod')` instead? In this format we could have a handler for `manual`, `condition`, and then a default handler for the scenario we don't recognize the result and throw and exception instead?

    In the current format if the activation method were set to something like `wheelOfFortune` we would always default to evaluating the conditions with no warning about an invalid configuration being provided.

  4. +++ b/src/Entity/SwitchEntity.php
    @@ -169,23 +221,40 @@ class SwitchEntity extends ConfigEntityBase implements SwitchInterface, EntityWi
    +      // @todo Determine if we are doing and/or logic?
    +      $activation_conditions = $this->getActivationConditions();
    +      $is_or = TRUE;
    +      // @todo: This might be helpful for logging.
    +      $conditions_true = [];
    ...
    +      foreach ($activation_conditions as $condition_plugin) {
    +        $condition_value = $condition_plugin->evaluate();
    ...
    +        if ($is_or && $condition_value) {
    +          $conditions_true[] = $condition_value;
    +          return $condition_value;
    +        }
    

    In the interesting of keeping things modularized and readable it might be worth considering moving the condition evaluation into a separate helper function parallel to the `getManualActivationStatus()` method.

    Looking long term this would also set a good precedent in case a new method for determining the activation status were ever introduced.

  5. +++ b/src/Form/SwitchForm.php
    @@ -92,6 +92,36 @@ class SwitchForm extends EntityForm {
    +        'manual' => t('Manual'),
    +        'condition' => t('Condition'),
    ...
    +      '#description' => t('Note: Manual Activation Methods are required for overrides.'),
    

    Anywhere we're passing through translation we need to use `$this->t()` instead of passing to the global function.

  6. +++ b/src/Form/SwitchForm.php
    @@ -92,6 +92,36 @@ class SwitchForm extends EntityForm {
    +      '#default_value' => $switch->getActivationMethod(),
    ...
    +      '#default_value' => $switch->getManualActivationStatus(),
    

    Without running the code and debugging it these default values look right. I'm not sure off-hand why the configuration values wouldn't be shown.

    For next steps debugging I'd suggest running the export and confirming the new schema values are set as expected.

  7. +++ b/src/Form/SwitchForm.php
    @@ -92,6 +92,36 @@ class SwitchForm extends EntityForm {
    +      '#states' => array(
    +        'visible' => array(
    +          ':input[name="activation_method"]' => array('value' => 'manual'),
    +        ),
    +        'required' => array(
    +          ':input[name="activation_method"]' => array('value' => 'manual'),
    +        ),
    +      ),
    

    Nice work adding in the States API configuration. I love the consideration for the editorial UX.

slucero’s picture

robpowell’s picture

Status: Active » Needs review
StatusFileSize
new6.49 KB
new5.52 KB

Next Steps: points 6 and 7.

slucero’s picture

StatusFileSize
new7.6 KB
new3.85 KB

This patch addresses point 6 above by matching the form API field name to the schema API name.

I've also added the same visibility configuration through the States API to the Activation Conditions section.

robpowell’s picture

Status: Needs review » Reviewed & tested by the community

Looks good!

  • slucero committed f1aade4 on 8.x-1.x authored by robpowell
    Issue #3009719 by robpowell, slucero: Make activationStatus override-...
slucero’s picture

Assigned: robpowell » Unassigned
Status: Reviewed & tested by the community » Fixed
Issue tags: +Needs tests

Merged! See commit f1aade4.

Status: Fixed » Closed (fixed)

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