Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Multi-Branch Package Creation (Group Login)

Business and implementation hub for shared package creation and package access rules for Group Login staff. For the detailed FE plan and API contract, see the linked documents below.

Authoritative source-of-truth PRD (ClickUp): Multi-Branch Selection for Package Creation (Group Login). The documents in this KB are the extraction for engineering planning. If they ever disagree with the upstream PRD, the upstream PRD wins.

Design: Figma — Partner Portal Desktop, Group Login — covers the Branches field on the Create Package form header.


Read by role

You are…Start here
Product / Business / Engineering — what we’re building and the final decisionsPRD — src/PRD/Multi_Branch_Package_Creation_20260909000000.md
Frontend (book-bite) — UI components, Branches field, create/edit permissions, and submit flowFE Spec — src/PRD/FE_Multi_Branch_Package_Creation_20260909000000.md
Backend (hh-server) — API contracts, access rules, transaction behavior, and existing approval flowBE Spec — src/PRD/BE_Multi_Branch_Package_Creation_20260909000000.md
QA — test matrix, critical test cases, pre-rollout checklistQA Spec — src/PRD/QA_Multi_Branch_Package_Creation_20260909000000.md

v1 in one paragraph

Group Login staff get a Branches multi-select field on the Create Package form — visible only for staff with access to multiple restaurants — and submit once to create one shared package attached to every selected restaurant. The backend creates one HhPackage::Package, one RestaurantPackage per selected restaurant, and one approved creation PackageSubmission in one all-or-nothing transaction. The submission is anchored to the staff default restaurant for the existing audit and admin-review context; it does not represent a submission per branch. Group staff may edit a shared package and the package-level change applies to all attached restaurants; a single-restaurant staff member may view it but cannot edit or deactivate it. Existing per-restaurant active and expiry behavior remains unchanged. Non-group accounts keep the existing single-restaurant create flow. Partner Portal web only; mobile app is out of scope.


Glossary

  • Group Login — login mode where a staff member has access to multiple restaurants; the FE may represent this as loginAsGroup === true
  • Branches Field — new multi-select dropdown on the Create Package form, reusing SelectMultipleBranch.vue
  • All Branches — shortcut that resolves to every restaurant in userStore.restaurants at submit time
  • Shared Package — one package record with more than one non-deleted RestaurantPackage
  • Single-Restaurant Staff — staff member with access to one restaurant; may view a shared package but may not mutate it
  • Package-Level Edit — an edit submitted from one accessible branch updates the shared package through the existing approval workflow

Cross-references

Final business decisions

AreaDecision
CreateGroup staff can select one or more accessible restaurants and create one shared package.
AtomicityThe package, all restaurant packages, and the one creation submission succeed or fail together.
Group editGroup staff can edit a shared package; the existing approval workflow applies the package-level change to all attached restaurants.
Single-staff accessSingle-restaurant staff can view a shared package, but edit and deactivate are blocked; the partner API has no package delete route.
Partial group accessA group staff member can edit the shared package even when they can access only some of its attached restaurants.
Active and expiry stateRemains per RestaurantPackage and follows the existing logic.
DefaultsExisting package-creation default resolution remains the source of truth. The staff default restaurant is the reference/fallback; no new per-restaurant payment or commission rules are introduced.
CurrencyMixed currency is not treated as a new multi-branch rule. Existing service/default behavior remains authoritative.
EmailAuto-approved creates do not enter the pending-review email flow. Existing edit notifications target the submitting staff member; a future create-confirmation must be sent once, not once per restaurant.
Submission statusNew package submissions remain auto-approved; edits remain in the existing approval workflow.

Explicitly not part of this version

  • batch_id migration or batch-level submission UI.
  • A partner package delete route.
  • Partial-success behavior; create is one transaction.
  • A restaurant selector on the Edit Package form.
  • Broadcast email to every staff member in a restaurant group.
  • Mobile package creation.

Status

  • Source-of-truth PRD: ClickUp PRD. Final business decisions are recorded above.
  • Implementation: the backend contract was merged into the local hh-engineering checkout on Sep 23, 2026; the focused hh-server RSpec suite passed before that merge. This KB update is not a release record.
  • Figma: Reviewed Sep 09, 2026 — covers Branches field on Create Package form header.