Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

semmelei: Review Window, confirmations move to the Dispatch

Open
  • Is something wrong?
#90 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
api, backend, frontend, full-stack, testing

Research direction

Start with the schedule module beside the Deadline, then trace the admin settings API and form, pickup day dispatch tick, Procurement response and page, and the HTTP harness tests with the recording mail sink. Check the existing at-most-once mail logic and CODING_STANDARDS.md, then follow the API client generation and rorm migration workflow. Done means every listed acceptance criterion passes, including review-window timing, cancellation, and the three Procurement states.

Written by the indexing model from the issue text.

Description

ready-for-agent

Parent

#87

What to build

A pickup day gets a Review Window between its Deadline and its Dispatch, and the binding confirmations move from the Deadline to the Dispatch. No Bakery mail yet (that follows in the Bakery CSV ticket); here the Dispatch marks the day dispatched and sends the confirmations.

  • Setting: Admins set the Review Window in whole minutes (non-negative, default 0) through the admin settings API and form.
  • Timing: Dispatch due = the day's Deadline (rule or override) + the current Review Window, computed, never stored, in the schedule module next to the Deadline (Europe/Berlin). A Deadline override moves the Dispatch; a change of the Review Window applies to a day currently in its window on the next tick.
  • Tick: freezing at the Deadline (and "Jetzt einfrieren") stays, but sends nothing. A second step picks days whose Dispatch is due, not called off and not yet dispatched, marks them dispatched (new nullable "dispatched at" on the pickup day) and sends the confirmations with the existing at-most-once logic. A Dispatch missed during downtime happens on the first tick after restart. "Jetzt einfrieren" does not move the Dispatch.
  • Review: an order cancelled by an Admin during the window gets its cancellation mail and no confirmation.
  • Procurement: the summary response carries the Dispatch due time and "dispatched at"; the page shows "Bestellung offen bis HH:MM", "Prüfzeit bis HH:MM" and "An die Bäckerei versendet um HH:MM".
  • Cancel after Dispatch: still allowed; the frontend warns that the sent order does not change.
  • New i18n keys per CODING_STANDARDS.md, API client regenerated, rorm migration committed.

With the default of 0 the Dispatch happens at the Deadline, so nothing visible changes until an Admin sets a Review Window.

Acceptance criteria

  • Review Window settable via the admin settings API and form; negative values rejected
  • No mail at the Deadline when the Review Window is > 0; confirmations at Deadline + Review Window, not one minute before
  • Review Window 0 confirms at the Deadline
  • A Deadline override of a single day moves its Dispatch
  • Shortening the Review Window during a day's window dispatches it on the next tick
  • A called-off day is never dispatched
  • "Jetzt einfrieren" freezes but does not dispatch early
  • An order cancelled during the window gets a cancellation and no confirmation
  • Each day is dispatched once; a later tick sends nothing again
  • The Procurement response reports the right state before the Deadline, during the window and after the Dispatch; the page renders those three states
  • Cancelling an order on a dispatched day shows a warning
  • Tests go through the HTTP harness with the in-process tick and recording mail sink
Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
10h 20m
Merged PRs (30d)
36

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from myOmikron/code

All issues in myOmikron/code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.