CMS · App button manager (MOFs)

Configures the mobile app’s navigation buttons: their type, label (per language), image, position, date window, visibility, access requirements and audience targeting — covering both the fixed standard menu and custom buttons, including groups of buttons.

AreaCMS
Routescms.mofs · cms.mofs.index
Centre modulescms
Staff levelsroot · admin · manager · weboperator
Modelscampaign · category · language · mof · mof-language
UI labeltitle.header.cms.mofs / menu.navbar.cms.mof
Coverage7 use cases · 3 happy · 11 failure

How it works

The most configuration-dense screen in the app (750-line controller) because each of ~21 button types changes which fields are relevant. Two top-level kinds: custom buttons and menu_static (the app’s standard menu entries — home, search, loyalty, events, news, stores, profile, info, plan your visit, services, commerces map), and for menu_static the model deliberately drops the start/end date requirements (attrsToValidate.pop() twice). Type-conditional required fields: URL types need a url; stores/proposals need a categoryId; lotteries/booking_appointment/loyalty_qr_commerce need a campaignId; group needs mofsCount. A long list of canShow…/canEdit… getters decides field visibility per type and role. Uniqueness rules are enforced in the controller, not the model: at most one cashback button (cms.mofs.only-one-cashback-type) and one fidcard button (cms.mofs.only-one-fidcard-type), and a button already inside a group cannot be grouped again (cms.mofs.mof-already-grouped). Buttons can require dni or email_validated before opening, and can target or exclude a user type (selectedUserTypeId / selectedUserTypeNegativeId). Positions are managed against persistedPositions/availablePositions. Relationship loads are defensive (relationship.load().catch(() => null)), so a broken reference degrades rather than crashes.

Use cases

Why someone opens this (7)

  • Adding a ‘Digital games’ button to the app home that opens a specific game.
  • Pointing a button at a store or proposal category so it opens a filtered list.
  • Gating a loyalty button so only users with a VAT number or a validated email can open it.
  • Grouping several buttons under one entry to keep the home screen clean.
  • Scheduling a seasonal button to appear and disappear on set dates.
  • Reordering the standard menu for a particular centre.
  • Showing a button only to a given user type, or hiding it from one.

Path map

flowchart LR
    F(["App button manager MOFs"]):::feat
    F --> H1["Custom URL button published"]:::ok
    F --> H2["Button group created"]:::ok
    F --> H3["Standard menu adjusted"]:::ok
    F -.-> X1["Core fields missing"]:::bad
    F -.-> X2["Start date after end date"]:::bad
    F -.-> X3["URL type without a URL"]:::bad
    F -.-> X4["Category type without a category"]:::bad
    F -.-> X5["Activity type without an activity"]:::bad
    F -.-> X6["Group without buttons"]:::bad
    F -.-> X7["Duplicate singleton type"]:::bad
    F -.-> X8["Button already in a group"]:::bad
    F -.-> X9["Save fails"]:::bad
    F -.-> X10["Delete fails"]:::bad
    F -.-> X11["Broken relationship"]:::bad
    classDef feat fill:#6a4a8f,stroke:#6a4a8f,color:#ffffff,font-weight:bold
    classDef ok fill:#e3f1ea,stroke:#0d6b42,color:#0d4a2e
    classDef bad fill:#f7e6e2,stroke:#9a2d1c,color:#6e1f13

Happy paths

Custom URL button published

  1. User creates a custom button, picks a URL type and enters the URL.
  2. Uploads the button image and sets the label for each language.
  3. Sets start and end dates and a free position.
  4. Optionally adds an access requirement and a user-type target.
  5. save passes validates() and the button appears in the app.

Button group created

  1. User creates a group button and selects the buttons to nest (groupableMofs).
  2. mofsCount is non-zero so validation passes.
  3. The group is saved and the app shows one entry that expands.

Standard menu adjusted

  1. User switches the view type to menu_static and picks a sub-type.
  2. Because the standard menu is permanent, the date requirements are dropped.
  3. Position and label are set and the standard entry is updated.

Failure paths

QA checklist

Tick these off while regression-testing this feature. The boxes are plain Markdown, so progress is visible in git diffs.

  • ✅ Custom URL button published
  • ✅ Button group created
  • ✅ Standard menu adjusted
  • ⛔ Core fields missing
  • ⛔ Start date after end date
  • ⛔ URL type without a URL
  • ⛔ Category type without a category
  • ⛔ Activity type without an activity
  • ⛔ Group without buttons
  • ⛔ Duplicate singleton type
  • ⛔ Button already in a group
  • ⛔ Save fails
  • ⛔ Delete fails
  • ⛔ Broken relationship

Implementation


Generated from doc/feature-inventory.json · id cms-mofs · commit 276788ca6