Trip listings

Overview

Listings are the trips, charters, hunts, or packages your outfitter sells and operates in Mallard Bay. From Listings you build your catalog: marketing copy and photos, location and trip details, availability and pricing, payment expectations, and operational details (for example guides and guest-facing documents). Each listing can be in progress until you complete enough setup and publish it. After publishing, the listing can appear in guest-facing surfaces (such as your public listing page and flows that use that listing).

The dashboard splits work into two levels:

1. Catalog view — /manage-listings — see all listings, create a new listing (account owners only), reorder how listings are ordered, and open any listing.
2. Single listing — /manage-listings/<listing-id> — edit one listing using labeled sections. Section URLs use hash fragments (for example #core-listing-setup) so you can bookmark or share a link to a specific section after you are already on that listing’s page.

Prerequisites

• An outfitter context must be active in the dashboard (the app is built around managing a selected outfitter).
• Create listing is available only to the account owner (the dashboard restricts “action” controls such as create, duplicate, and delete to the owner role). Other team members can open listings and use many editing tools, but they will not see those owner-only actions.
• If Mallard Bay internal admin tooling is in play without impersonation, the UI may require you to select an outfitter before list content loads.

Step-by-step usage in the dashboard

Open Listings and review your catalog

1. Go to Listings (/manage-listings).
2. Use the table: each row shows title, location, status, and a high-level availability indicator.
3. Click a row to open that listing’s full editor (/manage-listings/<listing-id>). You can also use the row menu for quick actions such as Share (guest-facing listing link) or Calendar (opens calendar scoped to that listing).

Status column: In the implementation, a listing shows as Listed when it is published; otherwise it appears as in progress (unpublished).

Create a new listing (account owners)

1. On /manage-listings, choose Create listing.
2. Complete the creation form (including initial lodging selections where the form asks for them) and submit.
3. After success, the app navigates you to the new listing’s management page so you can continue setup.

Reorder listings

When you have more than one listing, Reorder listings is available on the catalog page so you can control display order (for example on surfaces that respect listing order).

Work inside a single listing

On /manage-listings/<listing-id>, the layout uses a section navigator (on smaller screens it behaves like navigation between sections). Selecting a section updates the URL hash.

Customer-facing section groups:

Deep links: To open a section directly, use the pattern:

/manage-listings/<listing-id>#<fragment>

The hashes above are the ones defined in the app. Fragments only apply on the single-listing URL; putting #availability-pricing on /manage-listings alone does not switch sections, because the navigator exists on the per-listing page.

Internal-only: A fifth section, Admin Settings (#admin-settings), appears only for Mallard Bay internal admin users, not for standard outfitter accounts.

Progress and publishing

While you edit, a progress summary can appear showing checklist-style completion for items such as basics, description, location, photos, lodging, species, amenities, pricing, add-ons, post-booking payments, and availability—so you can see what still needs attention across marketing, availability, and money workflows.

When the listing is not published, and core readiness rules are satisfied (in code: listing basics, description, and photos marked complete), a Ready to Publish banner can appear with Publish listing. Using it sets the listing to published so guests can find and book it where your Mallard Bay surfaces expose published listings.

Actions from the listing header (menu companions)

Depending on state and permissions:

• Copy link — copies the public guest listing URL (…/listing/<listing-id> on your Mallard Bay site root), not the dashboard URL. Shown when the listing is published.
• Duplicate listing, Go to calendar, Delete listing — owner-only actions in the UI.

Delete confirmation explains that the listing becomes unpublished and no longer discoverable in search or on the Mallard Bay website, that existing bookings stay on your account, and that you lose access to view or edit the listing after deletion.

Common pitfalls

• Hashes on the wrong page: Use /manage-listings/<id>#section, not /manage-listings#section, for section deep links.
• Expecting every team member to create listings: Only the account owner sees Create listing and other owner-gated actions such as duplicate/delete in this area.
• Publishing vs. full checklist: You may still see a long progress list; the Publish listing banner appears only when the app considers the minimum setup met (basics, description, photos), plus loading/error state allows it.
• Species section: For some listing types, the Species block is omitted entirely; that is intentional in the product logic.

Related workflows

• Bookings — Guests book against a listing; operational booking work (payments, forms, guest messaging) connects back to that listing.
• Availability — Listing availability & pricing determines when a listing is bookable; calendar tooling is separate but linked from list and row menus for schedule work.
• Website and booking widget — Published listings feed guest-facing website and booking widget experiences.
• Quotes and booking invites — Sales flows can attach a listing when packaging a quote or invite before a booking exists.
• Clients and leads — Listings attract interest; leads and clients are the people side of the funnel once they engage or book.

Unknown from this codebase alone: Exact backend rules for each “progress” checkbox, all conditions under which a listing appears on every third-party channel, and whether the GraphQL layer allows non-owners to publish (the banner does not itself check owner permission in the UI component; enforcement, if any, would be server-side). If publishing fails unexpectedly for a non-owner, treat that as a support or permissions investigation.