Business information, schedule, and reviews
Customer App can conditionally open separate Business Information and Reviews modals from a business page. They can share one returned business graph while loading, media, map, provider, and review-list states settle independently.
:::warning Important boundary
Opening Information or Reviews is not guaranteed to be read-only. Information can mount remote media, map, or external-provider content, and Reviews can start a separate business read.
:::
Information and Reviews are separate
| Surface | Current visible scope | What it does not prove |
|---|---|---|
| Business Information | Returned address/notes, schedule, photos, videos, and optional location presentation | Serviceability, legal accuracy, provider trust, contact completion, or current business availability |
| Reviews | Returned rating summary and review items, or a separate review read | Moderation, publication, reviewer identity, full count, complete history, or submission eligibility |
The visible open or closed state records presentation only. Opening can also begin review, media, map, or provider work; neither the visible state nor closing proves that work settled or was cleaned up.
Returned business fields and configuration
Information and Reviews depend on the current business projection plus project, business, theme, language, and provider configuration. Theme gates govern the location, address, schedule, image, and video sections inside Information. The header defines Information and Reviews action flags but does not use them in the current action rendering: Information is available after header loading, while Reviews visibility depends on returned rating state.
The app should receive purpose-minimal fields for each surface. Missing, malformed, stale, differently typed, protected, or filtered configuration must fail closed without exposing internal values, exact provider settings, or a private business relation.
Information section states
| Section/state | Safe interpretation |
|---|---|
| Address or notes | Returned business text for one revision; not geocoded, legal, or serviceability authority |
| Schedule | Returned weekly intervals; not a promise that the business is open, accepting orders, or available at a future time |
| Location map | Provider-backed presentation can mount when current configuration allows it |
| Photos | Remote image references can load from external sources |
| Videos | Embedded WebView content can load scripts, media, storage, and subresources |
| Section hidden | Theme/config/result did not render it; provider/data absence is not established |
| Read more/less | Local text expansion only |
Schedule labels can differ from business/server time because timezone, clock, day boundary, daylight-saving behavior, and data revision remain separate.
Reviews list states
| State | Current source boundary |
|---|---|
| Supplied reviews | Existing business review rows can be sorted and filtered locally |
| Separate read | When supplied rows are absent, the controller can request the business reviews projection |
| Rating summary | One returned aggregate is formatted as an average; its source revision can differ from the visible list |
| Review item | The current card shows score, comment-or-placeholder, and date; reviewer identity is not required for this presentation |
| Loading | Controller starts loading, but the current modal has no dedicated loading presentation |
| Empty | No visible review rows are shown; loading, filtering, error, or true empty can overlap |
| Error | A generic error can render while the empty message also remains visible |
| Pagination | The current modal does not expose an accepted pagination or completeness contract |
A rating, visible row count, list length, or empty message is not an authoritative review count or complete-publication receipt.
Reviewer projection and publication
Customer-facing review cards should use a purpose-minimal, moderated, enabled projection. Reviewer account, contact, order, payment, address, location, student, gift, message, provider, and other linked data are not needed for the visible score/comment/date state.
Review creation, eligibility, moderation, publication, editing, deletion, analytics, and grouped submission belong to the separate review contract. This page documents only the returned review-list presentation and makes no claim that a visible review was verified, anonymous, complete, or currently eligible for publication.
Remote media, maps, and provider boundaries
Information can render remote images, a provider-backed map, and embedded video content. A social-link implementation exists, but the current business-header caller omits the required business data, so it does not establish a currently visible social action. Any future or different caller that supplies that data would create an external-provider handoff.
- Remote sources must be allowlisted, minimized, bounded, and replaceable with safe local placeholders.
- Embedded content must restrict origins, scripts, forms, storage, subresources, navigation, downloads, and messages.
- Map/location display must use a reviewed purpose and consent boundary.
- External destinations require approved schemes/hosts and informed confirmation.
- A missing image, map, video, or external app is not a reason to enable a provider, grant permission, or paste another link as a test.
Dormant contact and external-link implementation
The source includes an external-link control that can open returned social values, but its current caller supplies loading state without the business data the control expects. Treat it as dormant implementation, not as a current visible contact or social feature.
If a future caller makes any call, message, social, map, browser, or media action reachable, treat it as a separate provider handoff. A visible control would not prove that the destination is safe, current, business-owned, supported, or completed. Do not publish real contact or location values.
Unknown outcomes and safe troubleshooting
| Situation | Safe response |
|---|---|
| Information loads but Reviews does not | Treat the surfaces as different revisions; do not infer review absence |
| Rating changes but list does not | Aggregate and item projections are inconsistent |
| Error and empty both appear | Preserve the read failure; do not interpret it as zero reviews |
| Schedule conflicts with open/closed styling | Business/server time authority is unresolved |
| Map or media is missing | Use the safe placeholder; do not activate a provider to diagnose |
| A future caller exposes an external link | Treat it as a new provider handoff requiring recertification; current reachability is not established |
| Account, project, business, or language changes | Reject prior media, review, map, and external callbacks |
Support reports should use only value-free state classes such as “review list unresolved” or “information and review revisions differ.” Do not include business, reviewer, contact, location, review, media, account/order identifiers, links, provider details, or private screenshots.
Privacy and accessibility
- Business and review content can reveal location, interests, routines, contact, order context, and reviewer text. Keep real values out of evidence and logs.
- Information and Reviews controls and modals need distinct accessible names, modal isolation, close behavior, focus return, and loading/error/empty states.
- Schedule rows, rating summary, review cards, read-more controls, maps, photos, videos, and external links need purpose-specific labels and alternatives.
- Do not rely on stars, color, images, map markers, modal position, or missing content alone.
- Large text, keyboard, screen reader, switch, safe-area, Back, reduced-motion, provider-denied, and no-media behavior require current-platform verification; this guide does not certify them.
Recertification triggers
Revalidate after changes to Information/Reviews modal entry, business DTO or configuration filtering, address/notes/schedule, rating/count aggregation, review filtering/loading/error/empty/pagination, minimal reviewer projection, review-publication ownership, remote images/video WebViews, maps/location, social/contact/external handoffs, account/project/language cleanup, privacy, or accessibility.
Also recertify after changes to API deployment authority, moderation/enabled policy, provider origin controls, consent, stale-response cleanup, or error mapping.