Report Builder: per-brick width editing in the builder UI

[nielsdrost7]

Parent: #130 (Report Builder) · Hanging item from #608

Story
As a company admin, I want to set a brick's width (⅓, ½, ⅔, full) from the builder, so I can put two bricks side by side without editing JSON.

Current state (as of PR #608)
The data model fully supports widths: bands.json entries carry width (ReportBlockWidth enum), ReportRenderer lays them out on a 12-column grid, and MasonDocumentConverter round-trips the value through the mason editor inside the reserved _width config key. What's missing is any UI to change it — and one known edge: saving a brick's config slide-over rebuilds the config from the form fields, which drops _width and silently resets the brick to full width (mason's BrickAction owns that flow; see Modules/Core/Mason/MasonDocumentConverter::WIDTH_KEY).

Approach candidates (decide in implementation)

1. Inject a shared width Select into every brick's configureBrickAction() schema via the ReportBrick base class — fixes the reset edge for free since _width becomes a real form field.
2. A per-brick "width" action on the builder page (like move-to-band) operating on the mason state.

Acceptance criteria

• Width is editable per brick instance in the builder (all four ReportBlockWidth values)
• Saving a brick's config slide-over no longer resets its width
• Width persists through save → reload → render (bands.json width field, not config)
• PHPUnit: builder page test setting a width and asserting the persisted bands.json entry

[nielsdrost7]

SMART Plan — Report Builder: per-brick width editing in the builder UI

Context/Epic: Core (Reports) — hanging follow-up from PR #608, parent #130

Specific

Company admins should be able to set a brick's width (⅓, ½, ⅔, full) from the builder UI, and saving a brick's config slide-over should not silently reset it to full width. Current state on develop: the issue's own text says "the data model fully supports widths" via a ReportBlockWidth enum and MasonDocumentConverter::WIDTH_KEY — but neither of those exists anywhere in the codebase (confirmed by grep), nor does the builder page (#523) or brick registry (#521) that would need to exist first. So, taken literally against develop, this issue isn't "add UI for an existing capability" — it's "build the width concept and its UI together," since the Phase 1/2 work that would define it isn't merged either.

Measurable

• Width is editable per brick instance, for all four candidate values.
  • Frontend/Livewire: as a company admin I want to set a brick's width from the builder without editing JSON.

    #[Test]
    public function it_sets_a_bricks_width_from_the_builder_ui(): void
    {
        /* Arrange */
        $template = ReportTemplateStorage::clone('invoice/default', $this->company->id, 'Width Test');

        /* Act */
        Livewire::actingAs($this->user)
            ->test(DesignReportTemplate::class, ['tenant' => Str::lower($this->company->search_code), 'slug' => $template->slug])
            ->call('setBrickWidth', 'header_company', 'half');

        /* Assert */
        $bands = app(ReportTemplateStorage::class)->loadBands($template->slug, $this->company->id);
        $this->assertSame('half', collect($bands['header'])->firstWhere('brick', 'header_company')['width']);
    }

• Saving a brick's config slide-over does not reset its width — the specific regression this issue calls out.
  • PHPUnit: it_preserves_width_when_saving_the_brick_config_slide_over()
• Width persists through save, reload, and render.
  • PHPUnit: it_persists_width_through_save_reload_and_render()

Achievable

1. Blocked on Report Builder: five band canvases (header, group header, details, group footer, footer) #523 (builder page) and the width concept being introduced at all via Report Builder: code-defined Bricks (fields + config schema) #521/Report Builder: file-based persistence (manifest + bands JSON), clone + sync-system #528.
2. Of the two approaches this issue proposes, injecting a shared width Select into ReportBrick::configureBrickAction() is the safer one — it fixes the "config save resets width" regression by making width a real form field instead of side-channel state, per this issue's own reasoning.
3. Review PR [IP-130]: Report Builder — bands + bricks (IP-130, Phases 1-4 + Browsershot driver) #608 first — it claims this exact data model already exists there.

Relevant

Without a width control, laying out two bricks side by side requires hand-editing bands.json, which defeats the point of a visual builder.

Time-bound

Sprint 7.

[nielsdrost7]

Verified 2026-09-08 against the current feature/130-report-builder branch: both problems this issue describes look resolved.

• Select::make('_width') is now a real field inside every content-bearing brick's configureBrickAction() — either directly, or inherited from AbstractDetailProductBrick/AbstractFooterTextBrick (added in commit a147c34, after this issue was filed against an earlier commit). That's the missing UI control this issue asked for.
• Because _width is now part of the form schema itself, Filament's own submitted form data carries it straight through ReportBrickAction::action()'s 'config' => $data — there's no longer a separate rebuild step that can drop it, so the "saving resets width to full" regression no longer reproduces.
• Round trip is covered by two green tests: AdminReportBuilderTest::it_lifts_the_block_width_out_of_the_config_when_saving and ::it_hands_the_stored_width_back_to_the_canvas_on_load.

Linked as Closes #598 on PR #720 (still draft/open) so this closes automatically on merge, rather than closing it manually ahead of the fix actually landing on develop.