Enums

Document Purpose

This document defines the shared enum vocabulary intended for Tripinger's relational database layer. It exists so schema design, API behavior, partner workflows, admin tooling, and frontend state handling can use the same approved status language instead of drifting into inconsistent field values across modules.

The root documentation map already reserves this file as the dedicated reference for shared enum definitions inside docs/database/. That makes this document the canonical place to describe lifecycle values, role values, and constrained status sets that recur across identity, listings, bookings, payments, reviews, and operational workflows.

Why Enums Matter

Tripinger is planned as a multi-surface platform with a public traveler application, partner portal, admin dashboard, and shared backend API. Because the same business entities move through onboarding, approval, publication, booking, payment, moderation, and support flows across all of those surfaces, the platform needs a consistent status language that can be enforced at the schema level and understood at the application level.

The architecture and API direction both emphasize explicit workflow state, auditability, and role-aware operations. Shared enums help support those goals by making lifecycle transitions visible, constrained, and predictable instead of leaving core business state to loosely typed strings or undocumented conventions.

Enum Design Rules

The following rules should guide enum design throughout the database module.

• Prefer enums for stable business vocabularies that are reused across services or UI surfaces.
• Use descriptive values that reflect business meaning, not UI wording or color labels.
• Keep enum names singular and uppercase in documentation, while allowing implementation naming to follow the ORM or SQL conventions chosen later.
• Add values conservatively, because enum growth affects schema changes, API contracts, validation logic, analytics, and admin tooling.
• Document every enum change alongside migration changes and ERD changes when relationships or workflow meaning are affected.
• Treat enums as shared product language, not only database implementation details.

Enum Usage Guidance

Not every constrained field must be an actual database enum type. In some cases, a check constraint, lookup table, or application-layer validation model may be more appropriate depending on change frequency and reporting needs. This document still defines the approved business vocabulary even when the final physical implementation differs.

A practical rule for Tripinger is:

• use enums for stable workflow states and roles,
• consider lookup tables for admin-managed or frequently expanding taxonomies,
• and avoid duplicating near-identical status sets under slightly different names across modules.

Shared Enum Catalog

The following enums are the recommended baseline for the current documented platform scope. They reflect the workflows already implied by the platform overview, architecture, admin app, partner portal, and API documents.

USER_ROLE

Defines broad platform access roles used for authorization and operational separation. The API direction already identifies traveler, partner, admin, and internal staff style roles, while the admin and partner application documents further refine internal and partner access patterns.

ACCOUNT_STATUS

Defines the state of a user account at the identity and access layer. This should be distinct from partner approval state or listing publication state so authentication logic does not become entangled with marketplace workflow state.

PARTNER_ACCOUNT_STATE

Defines where a partner sits in the supply-side lifecycle. The partner portal explicitly describes account states such as invited, registered, onboarding, pending verification, approved, and suspended, making this one of the clearest enum candidates in the current documentation set.

PARTNER_TYPE

Defines the supply-side business category associated with a partner organization or owner profile. The platform scope and partner portal both describe multiple provider classes, including hotels, vehicle owners, restaurants, guides, activities, and broader local experiences.

VERIFICATION_STATUS

Defines the review result for compliance-sensitive records such as partner applications, documents, and trust-related checks. The admin and partner docs both rely on clear verification visibility and approval workflows.

LISTING_STATUS

Defines the publication state of supply-side inventory such as hotels, vehicles, activities, or restaurants. This should remain separate from verification status because a verified listing may still be unpublished, paused, or archived for business reasons.

AVAILABILITY_STATUS

Defines slot or inventory availability states used by hotels, vehicles, restaurants, and activities. The partner portal and product scope both depend on availability management as a core workflow.

BOOKING_STATUS

Defines the booking lifecycle. Booking state is one of the most important workflow vocabularies in the platform because the architecture centers booking creation, validation, payment confirmation, cancellation, and downstream notifications around it.

PAYMENT_STATUS

Defines the lifecycle of a payment record. The platform uses PayHere for local flows and Stripe for international flows, and the architecture stresses that booking state transitions should follow verified payment outcomes rather than frontend callbacks alone.

PAYOUT_STATUS

Defines the state of partner payout processing. Both the admin and partner documentation mention payout visibility, settlement awareness, and finance-related review workflows.

REVIEW_STATUS

Defines moderation and publication state for user reviews. Verified reviews and moderation workflows are central to the trust model described across the project documents.

MODERATION_STATUS

Defines the internal moderation state for reviews, posts, listings, or reported content. The admin app expects dedicated moderation workflows, including flag handling, visibility changes, abuse review, and appeal notes.

SUPPORT_CASE_STATUS

Defines the lifecycle of internal or user-facing support cases. The admin app explicitly includes support searches, internal notes, escalation handling, and safe support workflows.

INCIDENT_SEVERITY

Defines the severity level for safety, fraud, compliance, or operational incidents. The platform documents mention complaint records, safety report intake, emergency escalation flags, and high-risk booking visibility, which supports a severity-based classification model.

NOTIFICATION_CHANNEL

Defines outbound communication channels used for transactional and operational messaging. The platform architecture includes email, SMS or WhatsApp, push notifications, and related notification workflows.

Separation Rules

Several enums may look similar but should remain distinct because they describe different business concerns.

• ACCOUNT_STATUS is about whether an account can use the platform.
• PARTNER_ACCOUNT_STATE is about where a supplier sits in onboarding or approval.
• VERIFICATION_STATUS is about the review result for a document, identity item, or trust-sensitive submission.
• LISTING_STATUS is about whether inventory is drafted, approved, visible, or blocked.
• BOOKING_STATUS is about reservation lifecycle.
• PAYMENT_STATUS is about money movement and gateway outcome.

Keeping these vocabularies separate prevents the common mistake of overloading one status field to represent multiple kinds of business state at once.

Implementation Notes

The final schema implementation may use native PostgreSQL enums, ORM-managed enum types, check constraints, or reference tables depending on the migration strategy and ORM selection used in the repository. The API documentation currently suggests a NestJS backend with a relational database setup and a likely Prisma-based workflow, but exact implementation details should remain aligned with the committed codebase once scaffolding is finalized.

Regardless of the physical implementation, the following should remain true:

• enum names and meanings should be documented here first,
• migration changes should preserve backward compatibility where feasible,
• API response and validation conventions should reuse the same status vocabulary,
• and admin or partner interfaces should not invent parallel labels for the same business state without explicit translation rules.

Change Management

Any enum change can affect schema migrations, seed data, API validation, filters, analytics, dashboards, and role-based behavior across the public web app, admin dashboard, and partner portal. For that reason, enum changes should be treated as cross-cutting changes rather than minor local edits.

When adding or changing an enum:

• update this file,
• update docs/database/MIGRATIONS.md if rollout guidance changes,
• update docs/database/ERD.md if entity relationships or state meaning are affected,
• and verify that application-facing documentation remains aligned where relevant.

Current Status

This enum catalog defines the recommended shared vocabulary for the current documented scope of Tripinger. It should evolve as concrete schemas and workflows are committed, but it should continue to preserve a clear principle: stable business states need shared names, shared meanings, and shared rules across the entire platform.