Admin Portal

What staff use the portal for, how daily work is divided, and where important decisions belong.

The admin portal is the workplace for staff who run the boat membership service. It brings together daily booking work, member support, fleet records, communication, financial settings, and reports.

A normal day in the portal

An operator may use the portal to:

review booking and service requests that need attention;
check the fleet calendar and confirm which boats are free;
help a member create, change, or understand a booking;
record a boat problem or service visit;
check fuel information after a trip;
send a targeted message to affected members;
review a report or payment result.

The dashboard gives a short starting view of recent service requests, pending booking requests, and recent fuel information. It is a triage page, not a full live command centre. Open the related booking, boat, or member record before making a decision.

How the work is divided

Area	Why staff use it
Bookings	Plan boat use, find trips, and turn unresolved requests into confirmed bookings.
Members	Manage access, contact details, allowances, bookings, invoices, and subscriptions for one person.
Boats	Keep the operational record of each boat, its location, availability, description, issues, and service information.
Messages	Select an affected audience, send SMS or push, and inspect delivery results.
Reports	Answer defined questions about use, problems, fuel, members, and payments.
Settings	Maintain the shared choices used by other features: boat models, checklists, companies, services, facilities, issue categories, places, contacts, regions, tutorials, users, VAT, and app versions.
Integrations	Open configured connections such as Salesforce when enabled for the account.

Settings are business rules, not decoration

Many settings become choices or rules elsewhere. For example:

a boat model helps describe and group boats;
a checklist item becomes part of trip inspection;
a company and region determine ownership, access, currency, and tax context;
an extra service can be attached to bookings;
a Frog category standardizes issue reporting;
app-version settings tell clients whether an update is available or required.

Before deactivating or renaming a setting, check where it is already used. Historical bookings and issues must remain understandable.

Access levels

The portal uses three staff roles:

Role	Intended level of work
Viewer	Read operational information needed for normal viewing.
Manager	Perform the wider set of operational actions available to managers.
Admin	Manage the broadest set of actions and settings.

The interface hides controls that a user should not normally use, but the server also checks access. A hidden button is not the security system, and a visible button does not guarantee that a request will be allowed outside the user's company, region, or location scope.

Why one screen can use two backends

The portal was built over time. Some actions use the Symfony API and others still use the compatibility PHP/real-time services. From the operator's point of view this should feel like one product, but it matters during support: two similar buttons can fail in different services.

flowchart LR
    A[Operator action] --> B[Admin web portal]
    B --> C{Which service owns this action?}
    C --> D[Symfony API]
    C --> E[Compatibility API or real-time service]
    D --> F[(Shared business data)]
    E --> F

Feature guides

Technical reference

The current portal is under agapi-member-booking/agapi/admin. PHP loads the page and runtime configuration; Handlebars templates and JavaScript implement the screens. admin/js/api.js and admin/js/utils/api-utils.js decide whether a request goes to Symfony or to a compatibility service.