[TCA] type=check with multiple items (bitmask) only shows overall true/false

[maikschneider]

Problem

The Boolean partial used for type=check columns renders a single ✓ (truthy) or ✗ (falsy) icon based on the integer value. For single-checkbox fields this is correct. For multi-checkbox fields (bitmask), a stored value like 6 (bits 1 and 2 set) is shown as ✓, but the individual checkbox states are lost.

Example TCA config:

'my_options' => [
    'config' => [
        'type'  => 'check',
        'items' => [
            ['label' => 'Option A', 'value' => 1], // bit 0
            ['label' => 'Option B', 'value' => 2], // bit 1
            ['label' => 'Option C', 'value' => 4], // bit 2
        ],
    ],
],

A stored value of 6 means "Option B + Option C" — but the current output is just ✓.

Expected behaviour

When items has more than one entry, the partial should decode the bitmask and display the labels of all enabled bits — e.g. as a compact badge list: Option B · Option C.

Suggested fix

initTableConfiguration() in AbstractBackendController.php:
Pass the items array into colConfig for multi-check columns:

if ($config['config']['type'] === 'check') {
    $partial = 'Boolean';
    $checkItems = $config['config']['items'] ?? [];
    if (count($checkItems) > 1) {
        $column['checkItems'] = array_map(
            fn($item) => [
                'label' => $this->getLanguageService()->sL($item['label']),
                'value' => (int)($item['value'] ?? 1),
            ],
            $checkItems
        );
    }
    $filter = ['partial' => 'Checkbox'];
}

Boolean.html partial — extend to handle multi-check:

<f:if condition="{colConfig.checkItems}">
    <f:then>
        <f:for each="{colConfig.checkItems}" as="checkItem">
            <f:if condition="{item.{colConfig.columnName}} % {checkItem.bitDivisor}">
                <span class="badge">{checkItem.label}</span>
            </f:if>
        </f:for>
    </f:then>
    <f:else>
        <!-- existing single-checkbox logic -->
    </f:else>
</f:if>

Note: bitmask evaluation in Fluid requires a ViewHelper or pre-computed values. Consider
computing the enabled labels in PHP (in processTableConfiguration or a dedicated method)
rather than trying to do bitwise operations in Fluid.

Files to change

• Classes/Controller/AbstractBackendController.php — extend check branch to pass checkItems
• Resources/Private/Partials/Columns/Boolean.html — add multi-check rendering path

---

Agent prompt — validate & fix

Verify and improve bitmask check field rendering in xima-typo3-recordlist.

Context:
- `Classes/Controller/AbstractBackendController.php`, `initTableConfiguration()`:
  `type=check` sets `$partial = 'Boolean'` but does NOT pass the `items[]` array into colConfig.
- `Resources/Private/Partials/Columns/Boolean.html` renders a single ✓/✗ icon based on
  the field value's truthiness — correct for single checkboxes, lossy for bitmask fields.

Validation steps:
1. Confirm the check branch in `initTableConfiguration()` does not pass items into colConfig.
2. Confirm the Boolean partial does not handle multi-check/bitmask.
3. Identify a real multi-checkbox TCA field in the codebase or test fixture to validate against.

Fix approach:
- In `initTableConfiguration()`, when `count($config['config']['items'] ?? []) > 1`, pass
  the items (with translated labels and their bit values) into `$column['checkItems']`.
- Evaluate bitmask in PHP rather than Fluid — either in `initTableConfiguration()` by
  storing a helper structure, or in a `modifyRecord()` / `modifyPaginatedRecords()` hook
  that pre-computes the enabled label list per record and stores it as `_checkItems_fieldname`.
- Update `Boolean.html` to render the pre-computed label list when `colConfig.checkItems` is set,
  falling back to the existing ✓/✗ for single-checkbox fields.

Keep the single-checkbox path exactly as it is today. Do not break existing behaviour.

[pixelbrackets]

The Boolean partial used for type=check columns renders a single ✓ (truthy) or ✗ (falsy) icon based on the integer value. For single-checkbox fields this is correct.

This is is only correct for the intended search behaviour. But not for the current UI and the expections this UI sets for regular editors.

The search works like this: Show all results by default (boolean field = 0 || 1), remove results when a toggle is active (boolean field = 1).
Editors however read the toogle to behave like showing only results with an inactive field (boolean field = 0) or results with an active field (boolean field = 1).

Example:

Possible solutions:

1. Adjust the search behaviour to represent the toggle - search for 0 by default and 1 if active. Breaking change however.
2. UI makes the intended search behaviour more clear by using badges. This is a known pattern for searches. This would need a custom backend style however, I think there is no default style like this.
   Example:
3. UI offers multiple selections:
   • All
   • Active
   • Inactive
     This is the makes the search form rather large and technical however. And the labels may not represent the behavriour of the field value (does the boolean represents On/Off/Yes/No/Active/Inactive/Inverted/…)

[pixelbrackets]

→ Solution 3 was partially introduced in the latest version 14.3 to replace the ambiguous toggle

[maikschneider]

Quick fix #74

Bitmasks and custom label expressions still need further improvements.