k1nq/TREK
1
0
Fork 0
mirror of https://github.com/mauriceboe/TREK.git synced 2026-10-18 21:16:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(dayplan): a day can be deleted from the reorder dialog, after a warning that says what goes with it

Browse Source 
Every row of the reorder dialog, and of the days sheet on a phone, now has a delete button. It first asks, and the question lists what goes with the day: planned places stay in the place list, notes and day texts are deleted, bookings stay without a day, a stay that checks in or out on the day is cancelled with its booking and expense (shown in the danger tone), and on a dated trip the later days and their bookings move one date earlier or the trip ends a day earlier.

The server side moved from a bare DELETE into DayRemovalService, which REST, the delete_day tool and the plugin RPC all use. It closes the numbering, keeps the dates on their positions like a reorder, re-stamps the moved bookings, shifts the road trip boundaries, cancels touching stays through the accommodations domain, refuses the last day of a trip, and fans out day:deleted, day:reordered and trip:updated so collaborators renumber and see the new day count and end date. The trip query moved into a leaf file so the days domain can read it without a module cycle.

On the client the delete is online only, runs optimistically through the days slice with the same reducer collaborators apply, and the ConfirmDialog gained a slot for extra content, an Escape that only closes itself, and the danger and accent tokens.
This commit is contained in:
Maurice
2026-09-23 18:42:02 +02:00
parent 436f0740fb
commit 2f6f921aef
78 changed files with 3086 additions and 170 deletions
Download Patch File Download Diff File Expand all files Collapse all files
client/tests/unit/remoteEventHandler/days.test.ts
+41
View File
@@ -78,6 +78,47 @@ describe('remoteEventHandler > days', () => {
expect('20' in dayNotes).toBe(true);
});
// A delete now closes the gap on the server and keeps the dates on their slots;
// the collaborators run the same reducer the deleting tab ran optimistically.
it('FE-WSEVT-DAY-014: day:deleted then day:reordered leaves the same numbering and dates as the server', () => {
useTripStore.setState({
trip: buildTrip({ id: 7 }),
selectedDayId: 20,
days: [
buildDay({ id: 10, day_number: 1, date: '2026-06-01' }),
buildDay({ id: 20, day_number: 2, date: '2026-06-02' }),
buildDay({ id: 30, day_number: 3, date: '2026-06-03' }),
buildDay({ id: 40, day_number: 4, date: null }),
],
refreshDays: vi.fn(async () => {}),
loadReservations: vi.fn(async () => {}),
});
useTripStore.getState().handleRemoteEvent({ type: 'day:deleted', dayId: 20 });
const afterDelete = useTripStore.getState();
expect(afterDelete.days.map(d => [d.id, d.day_number, d.date])).toEqual([
[10, 1, '2026-06-01'], [30, 2, '2026-06-02'], [40, 3, '2026-06-03'],
]);
expect(afterDelete.selectedDayId).toBeNull();
useTripStore.getState().handleRemoteEvent({ type: 'day:reordered', orderedIds: [10, 30, 40] });
expect(useTripStore.getState().days.map(d => [d.id, d.day_number])).toEqual([[10, 1], [30, 2], [40, 3]]);
});
it('FE-WSEVT-DAY-015: day:deleted asks the planner to reload its stays, which a deleted day can cancel', () => {
seedData();
const refresh = vi.fn();
window.addEventListener('accommodations:refresh', refresh);
try {
useTripStore.getState().handleRemoteEvent({ type: 'day:deleted', dayId: 10 });
expect(refresh).toHaveBeenCalledTimes(1);
useTripStore.getState().handleRemoteEvent({ type: 'day:updated', day: buildDay({ id: 20 }) });
expect(refresh).toHaveBeenCalledTimes(1);
} finally {
window.removeEventListener('accommodations:refresh', refresh);
}
});
// The reorder is applied optimistically from orderedIds, then the authoritative
// dates + re-stamped booking times are pulled (#589).
describe('day:reordered', () => {