Overview

End-to-end QA testing of the Timelyst Inventory & Booking application. Many recent tickets involve foundational changes (refactoring, data schema migrations, architectural improvements) that are not individually QA-testable. Since Timelyst has no production traffic yet, this ticket consolidates full-stack validation into a single QA effort covering data sync, facility discovery, and booking workflows.

Environments:

Timelyst API (Dev): https://timelyst.dev.golfnow.io
Timelyst API (Stg): https://timelyst.stg.golfnow.io
Hangfire Dashboard (Dev): timelyst-hangfire-dev.golfnowdmz.local/hangfire/recurring (accessible via AWS Workspace)
Hangfire Dashboard (Stg): timelyst-hangfire-stg.golfnowdmz.local/hangfire/recurring (accessible via AWS Workspace)
API Docs: Swagger / Scalar available at the API base URL

Test Steps

Step 1 — Configure Interface in CRM

In the CRM database, create (or verify) an interface configuration for a golf course with a USC and/or CCH provider.
Ensure the InterfaceAttribute collection has the correct API URL and credentials for the chosen provider(s).
- Note: CCH credentials are stored in the MongoDB InterfaceAttribute collection (synced from CRM via InterfaceAttributeSyncJob), NOT in GCCourseCode.

Step 2 — Wait for CRM → MongoDB Data Sync

Wait approximately 1 hour for the recurring Hangfire jobs to auto-sync data from the CRM database to the MongoDB Timelyst database.
Monitor sync progress on the Hangfire recurring jobs dashboard: http://timelyst-hangfire-dev.golfnowdmz.local/hangfire/recurring
Verify that Facility, Offering, Service, and InterfaceAttribute data has been synced into MongoDB.

NOTE: Full-sync jobs will attempt to fetch the full CRM table and sync into Mongo, which should be used for initialization. Incremental-sync jobs will only compare the TimeStamp field with the last sync time and only sync records with the updated TimeStamp field.

Step 3 — Create Interface Configuration via API

Using the Timelyst Management API, create interface configurations for USC and CCH providers (if they don't already exist from the sync).

Action	Method	Endpoint
List existing configs	`GET`	`/api/v1/management/interfaceconfiguration`
Create new config	`POST`	`/api/v1/management/interfaceconfiguration`
Get config by ID	`GET`	`/api/v1/management/interfaceconfiguration/{id}`
Update config	`PUT`	`/api/v1/management/interfaceconfiguration/{id}`
Delete config	`DELETE`	`/api/v1/management/interfaceconfiguration/{id}`

Validation: Confirm configs are created with correct provider type, facility mapping, and enabled status.

Step 4 — Create Product Verticals & Assign to Offerings

Product verticals classify offerings (e.g., "Golf", "Simulator", "Fitting"). The Value is auto-incremented — no need to pass it in the request body.

4a — Create Product Verticals

Action	Method	Endpoint
List product verticals	`GET`	`/api/v1/management/productvertical`
Get by ID	`GET`	`/api/v1/management/productvertical/{id}`
Create product vertical	`POST`	`/api/v1/management/productvertical`
Update product vertical	`PUT`	`/api/v1/management/productvertical/{id}`
Delete product vertical	`DELETE`	`/api/v1/management/productvertical/{id}`
Activate	`POST`	`/api/v1/management/productvertical/{id}/activate`
Deactivate	`POST`	`/api/v1/management/productvertical/{id}/deactivate`

Create request body: { "name": "Simulator" } (Value auto-assigned as max + 1)

Validation:

Confirm Value is auto-incremented (1, 2, 3, ...)
Confirm Name must be unique
Confirm Value is immutable after creation (not editable via update)

4b — Assign Product Vertical to Offering

Assigns a product vertical to an existing offering using the ProductVertical's integer Value and the Offering's CRM GolfCourseID.

Action	Method	Endpoint
Assign to offering	`POST`	`/api/v1/management/productvertical/{value}/assign/{offeringCrmId}`

Example: POST /api/v1/management/productvertical/1/assign/12951

Validation:

Confirm the response returns the updated OfferingDto with productVerticalType set
Confirm assigning an inactive product vertical returns 400
Confirm non-existent Value or CRM ID returns 404
Verify the offering in MongoDB shows updated ProductVerticalType field

Step 5 — Create Service Categories & Assign to Services

Service categories use a power-of-2 bitmask pattern (CategoryId = 1, 2, 4, 8, 16...) to support multi-category assignment on services. Create categories first, then assign them to services synced in Step 2.

5a — Create Service Categories

Action	Method	Endpoint
List categories	`GET`	`/api/v1/management/servicecategory`
Get category by ID	`GET`	`/api/v1/management/servicecategory/{id}`
Create category	`POST`	`/api/v1/management/servicecategory`
Delete category	`DELETE`	`/api/v1/management/servicecategory/{id}`
Activate category	`POST`	`/api/v1/management/servicecategory/{id}/activate`
Deactivate category	`POST`	`/api/v1/management/servicecategory/{id}/deactivate`

Example: Create categories like "FullBag" (CategoryId=1), "Irons" (CategoryId=2), "Putter" (CategoryId=4).

Validation:

Confirm CategoryId must be a unique power of 2
Confirm Name must be unique
Confirm categories cannot be modified after creation (immutable — only activate/deactivate/delete)

5b — Assign Categories to Services

Action	Method	Endpoint
Assign categories	`POST`	`/api/v1/management/service/{id}/categories`

Request body: { "serviceCategoryIds": [1, 2] }

Multiple categories are combined via OR bitmask (e.g., assigning IDs 1 & 2 sets CategoryId = 3, Category = "FullBag & Irons").

Validation:

Confirm the service response shows the combined categoryId bitmask and concatenated category name
Passing an empty array clears category assignments
Verify assigned categories persist by re-fetching the service via GET /api/v1/management/service/{id}

Step 6 — Bootstrap & Run Reconciliation Jobs

Trigger the cm-interface-config-bootstrap job in the Hangfire recurring jobs dashboard and refresh the page.
Verify that two new recurring jobs are created: cm-recon-cch and cm-recon-usc.
Run each cm-recon-* job. This should create facility-specific jobs following the pattern: cm-usc-f{facilityId}-c{courseId}-d{day}-{sequence} (e.g., cm-usc-f2134-c12951-d0-1).
- These jobs are only created if the CRM golf course is configured with the corresponding interface provider.
Manually trigger these facility-specific jobs to sync inventory data with the upstream provider (Club Champion or USchedule).
Verify that after the jobs complete, resource availability data is populated in MongoDB.

Step 7 — Rebuild Discovery Documents & Verify ServiceCategory in Search

After categories are assigned (Step 5) and inventory is synced (Step 6), trigger the Hangfire job that rebuilds the FacilityDiscovery documents so that category data is indexed for search.

Trigger the facility-discovery-rebuild job (or equivalent) from the Hangfire dashboard.
Verify the FacilityDiscovery documents in MongoDB contain ServiceCategoryIds arrays on the service entries:
- Each service should list the decomposed power-of-2 category IDs (e.g., bitmask 7 → [1, 2, 4])
Test search with serviceCategoryIds filter:

#	Action	Method	Endpoint	Key Validations
1	Search by category	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/search?serviceCategoryIds={id}`	Only facilities with services matching the category are returned
2	Search by multiple categories	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/search?serviceCategoryIds={id1}&serviceCategoryIds={id2}`	Facilities with services matching ANY of the provided categories are returned
3	Detail search by category	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/search/detail?serviceCategoryIds={id}`	Full search with services filtered to matching categories; verify `serviceCategoryIds` array in response
4	Search without filter	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/search`	All facilities returned regardless of category

Validation:

Services in the response include serviceCategoryIds arrays with correct decomposed values
Filtering by a category that no service has returns zero results
The category string field on services shows the human-readable concatenated name

Step 8 — Test Client API (Facility Discovery)

Test the 5 client-facing facility discovery endpoints and validate responses.

#	Action	Method	Endpoint	Key Validations
1	Search facilities	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/search`	Returns facilities matching search/geo criteria; check `latitude`, `longitude`, `productVerticalType` filters
2	Get facility summary	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/facilities/{facilityId}/summary`	Returns basic facility info (amenities, operating hours, timezone); no offerings/services
3	Get facility detail	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/facilities/{facilityId}/detail`	Returns full hierarchy (offerings → services); no date-specific availability
4	Get facility availability	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/facilities/{facilityId}/availability?date={yyyyMMdd}`	Returns services with availability calendar for the specified date; verify timeslots are present
5	Search with detail	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/search/detail`	Full search with services, rate sets, and timeslots; validate pricing and availability

Validation: Confirm that facilities synced in Steps 2–6 appear in search results with correct offerings, services, and availability data.

Step 9 — Test Booking & Cancellation

#	Action	Method	Endpoint	Key Validations
1	Get supported providers	`GET`	`/api/v1/channels/{channelId}/management/booking/providers`	Returns list of supported providers (USC, CCH)
2	Make a reservation	`POST`	`/api/v1/channels/{channelId}/management/booking/reserve?provider={USC\\|CCH}`	Booking succeeds; confirmation number returned
3	Verify booking reflected	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/facilities/{facilityId}/availability?date={yyyyMMdd}`	The booked timeslot shows as unavailable / reduced capacity
4	Cancel the reservation	`POST`	`/api/v1/channels/{channelId}/management/booking/cancel?provider={USC\\|CCH}`	Cancellation succeeds using confirmation number
5	Verify cancellation reflected	`GET`	`/api/v1/channels/{channelId}/client/facilitydiscovery/facilities/{facilityId}/availability?date={yyyyMMdd}`	The previously booked timeslot is available again

Validation: After booking, the availability endpoint should reflect the consumed timeslot. After cancellation, the timeslot should be restored.

Acceptance Criteria

[ ] CRM → MongoDB data sync completes successfully via Hangfire jobs
[ ] Interface configurations can be created/read/updated/deleted via the Management API
[ ] Product verticals can be created (with auto-incremented Value), listed, updated, activated, deactivated, and deleted
[ ] Product verticals can be assigned to offerings via the assign endpoint using Value and CRM ID
[ ] Service categories can be created, listed, activated, deactivated, and deleted
[ ] Service categories can be assigned to services and the bitmask/name is correctly computed
[ ] Bootstrap job creates the expected reconciliation jobs (cm-recon-cch, cm-recon-usc)
[ ] Reconciliation jobs create facility-specific sync jobs and successfully sync upstream provider data
[ ] FacilityDiscovery documents contain ServiceCategoryIds after rebuild
[ ] Search endpoints correctly filter by serviceCategoryIds query parameter
[ ] All 5 client facility discovery endpoints return correct data including category information
[ ] Booking endpoint successfully creates a reservation and timeslot availability is updated
[ ] Cancellation endpoint successfully cancels a reservation and timeslot availability is restored

Priority

Components

QA