feat(companion): show an asset's bookings on the asset screen - #2870
Draft
carlosvirreira wants to merge 2 commits into
Draft
feat(companion): show an asset's bookings on the asset screen#2870carlosvirreira wants to merge 2 commits into
carlosvirreira wants to merge 2 commits into
Conversation
Customer request (Richard Raiman, Raiman Production): a bookings section in the asset view, to check when a specific asset will be out and to see past bookings. This is not new product. Web has had it as a Bookings tab on the asset page since long before the companion existed. The phone could not ask the question at all: no screen, no endpoint, and even the bookings list endpoint cannot filter by asset. - new GET /api/mobile/assets/:assetId/bookings, scoped exactly like the workspace list it mirrors: organisation scoped, SELF_SERVICE and BASE see only bookings they hold, DRAFT bookings stay private to their creator, and the asset is proven to belong to the workspace before anything is reported - statuses match web's BOOKING_STATUS_TO_SHOW, so COMPLETE is included. Past bookings are half of what was asked for - collapsed section on the asset screen, fetched on expand, so the usual asset load is unchanged for visits that never open it - rows link through to the booking Verified on device against a local server: Repro Super Clamp shows Repro Booking, 07/08/2026, Carlitos Virreira (Owner), Overdue, with a count of 1.
🩺 React Doctor — webapp✅ No new findings on the files changed by this PR. Run locally with |
🩺 React Doctor — companionFindings on the files changed by this PR:
|
The status on each row was plain text, so an asset's bookings were the one place in the app where a booking status did not look like a booking status - no pill, no colour, nothing tying it to the same status shown on the bookings list, the booking detail or the calendar's day panel. It uses the shared `bookingStatusBadge` palette now, and the wording comes from `BOOKING_STATUS_LABELS` in @shelf/labels rather than the generic `formatStatus` helper, which is the same source web renders from. Kept as a small component rather than inlined so the three booking surfaces cannot drift apart again by someone editing one of them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a bookings section to the asset screen in the companion app, so you can see what an asset is committed to without leaving it.
Customer ask from a rental operation: they wanted to answer "what is this booked for" while holding the item.
How
New endpoint
GET /api/mobile/assets/:assetId/bookingsreturns the bookings that hold this asset, filtered to the same statuses the web asset page shows (BOOKING_STATUS_TO_SHOW), so the two surfaces cannot disagree about which bookings count.The section is collapsed by default and loads on first expand, so an asset screen does not pay for a query most visits do not need. Each row shows the booking name, its dates, the custodian and its status, and tapping one opens the booking.
Status colours and wording
The status renders with the shared
bookingStatusBadgepalette andBOOKING_STATUS_LABELSfrom@shelf/labels— the same pill and the same words as the bookings list, the booking detail and the calendar's day panel. It is a small component rather than inline markup so those surfaces cannot drift apart by someone editing one of them.Testing
Verified on an iOS simulator against a local server, signed in to a workspace with real bookings: the section loads on expand, shows the correct count, and renders an overdue booking as a red "Overdue" pill. Cross-checked against web's calendar for the same asset and the same booking, which reports it overdue too.
The other statuses go through the identical component and palette, so they are covered by construction rather than by a separate device check.