m/paliad
1
0
Fork 0
Code Issues 152 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Dashboard edit-mode overhaul: drag/drop broken, no resize, per-widget options need expansion #69

New Issue
Open
opened 2026-05-21 07:29:19 +00:00 by mAi · 1 comment
mAi commented 2026-05-21 07:29:19 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-21 09:28 on the just-shipped configurable dashboard (m/paliad#46, all 3 slices merged 2026-05-20):

The new editable dashboard only allows "resorting" in a very limited manner. I can switch the first two widgets of the same size, but nowhere else. The resorting does not working, there is no resizing... this needs an overhaul.

We also need to have widget options where we can set limits, position, content / views etc?!

What's broken / missing

1. Drag/drop reorder is severely limited

m can only swap the first two same-size widgets. Other reorder attempts fail. The 12-col grid implementation from newton's Slice B is either:

  • Missing drop-target hit detection on most widget cells, OR
  • Snapping only within the first row, OR
  • The grid-recalculation step after a drop doesn't fire / fires with wrong indices.

Acceptance: drag any widget anywhere on the grid (incl. between rows, into empty cells); drop lands correctly; layout autosaves; reload preserves the new order.

2. Resizing is absent

The design called for per-widget resize (each widget has a size — 1x1, 2x1, 2x2 etc.). Either resize handles never rendered, or they're hidden behind the wrong CSS class, or the drag handler doesn't recognise the resize gesture vs. the move gesture.

Acceptance: drag bottom-right corner of a widget to resize; widget snaps to a valid grid size (clamped to grid cols); layout autosaves; sibling widgets reflow.

3. Per-widget options need to be richer

Current settings (counts + horizon dropdowns) are too thin. m wants:

  • Limits — max items per widget (already partially there as 'counts'?), max date horizon
  • Position — explicit X/Y override (vs drag-only)
  • Content / views — which view-type the widget renders (e.g. for the deadlines widget: list view vs calendar view vs timeline-strip; for the activity widget: full vs compact; etc.). Reuse the Custom Views' view-type system where applicable.

Widget-specific options are catalog-defined per widget; each widget declares its option schema and the settings pane renders the right controls.

Out of scope

  • Adding entirely new widget types (Slice C catalog expansion already shipped some; more is a separate ticket).
  • Per-firm widget restrictions / role-gated widgets.
  • Sharing layouts between users.

Role recommendation

fixer → coder. The two bugs (drag/drop + resize) are pure regressions on a freshly-shipped feature; the per-widget-options expansion is small if scoped to the existing settings pane infrastructure. Single PR per logical area is fine, OR one bundled PR if the diff stays reviewable.

Branch: mai/<worker>/dashboard-overhaul.

## Trigger m 2026-05-21 09:28 on the just-shipped configurable dashboard (m/paliad#46, all 3 slices merged 2026-05-20): > The new editable dashboard only allows "resorting" in a very limited manner. I can switch the first two widgets of the same size, but nowhere else. The resorting does not working, there is no resizing... this needs an overhaul. > > We also need to have widget options where we can set limits, position, content / views etc?! ## What's broken / missing ### 1. Drag/drop reorder is severely limited m can only swap the first two same-size widgets. Other reorder attempts fail. The 12-col grid implementation from newton's Slice B is either: - Missing drop-target hit detection on most widget cells, OR - Snapping only within the first row, OR - The grid-recalculation step after a drop doesn't fire / fires with wrong indices. **Acceptance:** drag any widget anywhere on the grid (incl. between rows, into empty cells); drop lands correctly; layout autosaves; reload preserves the new order. ### 2. Resizing is absent The design called for per-widget resize (each widget has a size — 1x1, 2x1, 2x2 etc.). Either resize handles never rendered, or they're hidden behind the wrong CSS class, or the drag handler doesn't recognise the resize gesture vs. the move gesture. **Acceptance:** drag bottom-right corner of a widget to resize; widget snaps to a valid grid size (clamped to grid cols); layout autosaves; sibling widgets reflow. ### 3. Per-widget options need to be richer Current settings (counts + horizon dropdowns) are too thin. m wants: - **Limits** — max items per widget (already partially there as 'counts'?), max date horizon - **Position** — explicit X/Y override (vs drag-only) - **Content / views** — which view-type the widget renders (e.g. for the deadlines widget: list view vs calendar view vs timeline-strip; for the activity widget: full vs compact; etc.). Reuse the Custom Views' view-type system where applicable. Widget-specific options are catalog-defined per widget; each widget declares its option schema and the settings pane renders the right controls. ## Out of scope - Adding entirely new widget types (Slice C catalog expansion already shipped some; more is a separate ticket). - Per-firm widget restrictions / role-gated widgets. - Sharing layouts between users. ## Role recommendation **fixer → coder**. The two bugs (drag/drop + resize) are pure regressions on a freshly-shipped feature; the per-widget-options expansion is small if scoped to the existing settings pane infrastructure. Single PR per logical area is fine, OR one bundled PR if the diff stays reviewable. Branch: `mai/<worker>/dashboard-overhaul`.
mAi self-assigned this 2026-05-21 07:29:19 +00:00
mAi commented 2026-05-21 07:56:09 +00:00
Author
Collaborator
Copy Link

Shipped via pasteur; merged at https://mgit.msbls.de/m/paliad/commit/f8c6206. Drag/drop + resize + per-widget options live after Dokploy deploy.

Shipped via pasteur; merged at https://mgit.msbls.de/m/paliad/commit/f8c6206. Drag/drop + resize + per-widget options live after Dokploy deploy.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#69
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?