Initial Scheduling Toggle State in Flex Components

[delcorsets]

I'm building a custom flex component with scheduling fields using the can_disable group pattern, and I'm running into a persistent issue: toggles are defaulting to ON when new list items are created, rather than OFF.

Here's the property structure I'm using:

```json
{
"code": "start_date",
"prompt": "Not Visible Before",
"type": "group",
"can_disable": 1,
"properties": [
{ "code": "start", "prompt": "Start Date/Time", "type": "datetime" }
]
}
```

I've tried several variations to get the toggle to default to OFF for new items:

1. "settings": { "enabled": 0 } on the group - toggle still defaults ON
2. "template": { "settings": { "enabled": 0 } } on the group - toggle still defaults ON
3. No settings or template at all (matching the pattern in mmx-mega-menu) - toggle still defaults ON
4. Nesting start/end inside a parent group without can_disable (caret-only collapsible) - child toggles still default ON

The fields are inside a list_type: group list property. When a new list item is created in Page Builder, both the Not Visible Before and Not Visible After toggles are ON by default, which means all new items are immediately date-gated and invisible until toggles are manually turned off.

For reference, I have another component on the same site that uses the identical pattern (can_disable: 1, no settings/template) and its scheduling toggles correctly default to OFF. The only structural difference I can identify is that in the other component the scheduling fields are at the top level of the list item, whereas in my component they are nested inside a group. Also, the component I'm having trouble with is global, the other one is not.

Questions:
1. Is there a correct way to specify can_disable defaults for new list items?
2. Does nesting a can_disable group inside another group affect its default state?
3. Is this a known issue?

Running Miva 26.01.01.

Thanks!

[Nick]

I believe the issue is where you're placing template and how the path resolves through nested groups.

template belongs on the list, not on the group. It defines the default values for a brand-new item when an admin clicks "Add," and within it you reference each sub-property by its code, mirroring the shape of l.settings:instance for that list item.

Placing template or settings directly on the group property definition (attempts 1 and 2) won't have any effect — those aren't recognized fields at that level.

Correct structure:

{
  "type": "list",
  "code": "items",
  "list_type": "group",
  "template": {
    "start_date": {
      "settings": { "enabled": 0 }
    },
    "end_date": {
      "settings": { "enabled": 0 }
    }
  },
  "properties": [
    {
      "code": "start_date",
      "prompt": "Not Visible Before",
      "type": "group",
      "can_disable": 1,
      "properties": [
        { "code": "start", "prompt": "Start Date/Time", "type": "datetime" }
      ]
    },
    {
      "code": "end_date",
      "prompt": "Not Visible After",
      "type": "group",
      "can_disable": 1,
      "properties": [
        { "code": "end", "prompt": "End Date/Time", "type": "datetime" }
      ]
    }
  ]
}

If the can_disable groups are nested inside a parent group, the path in template must include that parent.

If your fields are wrapped in a parent group (e.g., "code": "scheduling"):

"template": {
  "scheduling": {
    "start_date": {
      "settings": { "enabled": 0 }
    },
    "end_date": {
      "settings": { "enabled": 0 }
    }
  }
}

The template structure has to exactly mirror l.settings:instance. You can verify the correct path by adding a new item, saving, then dumping the instance:

<mvt:assign name="g.debug" value="glosub( miva_array_serialize( l.settings:instance ), ',', asciichar(10) )" /> <pre>&mvt:global:debug;</pre>

Find where settings:enabled appears relative to the list item's code path — your template must mirror it exactly.

Your questions:

1. Correct way to default can_disable to OFF: template on the list, with the path group_code.settings.enabled = 0.
2. Does nesting affect the default? Not inherently, but it changes the path required in template. If the working component has scheduling at the top level of the list item, its path is just start_date.settings.enabled; nested under a parent group, you need the extra level. Almost certainly the root cause.
3. Known issue? The behavior is by design — can_disable defaults to enabled unless overridden via template. https://docs.miva.com/developer/deve...ate-definition