# Hospitality: Vendor Portal Using Django

## Summary
A vendor portal blueprint for hospitality built with Django on Ample. Domain schema: 
- **room_types** (sku, name, capacity, base_rate, amenities): room and package catalog;  
- **inventory_movements** (sku, date, delta, reason): availability per date as stock movements;  
- **bookings** (booking_no, check_in, check_out, status): bookings with status transitions;  
- **booking_lines** (booking_no, sku, nights, rate): booking contents;  
- **document_access** (document_id, principal_reference, role, granted_at): who may read which document.

Public information: room types, amenities and rates from property location and policies, events and dining. Kept out of scope until handling is reviewed: guest identity documents, payment details, stay history. Guest identity documents are sensitive; only availability and booking status are modeled here.

Technical basis verified on Django: a role-to-document access model with negative tests (401 without identity, 403 for the wrong role) and a private-bucket round-trip for the allowed role (private=ok).

## Representative Queries
- Hospitality: vendor portal using Django  
- Where can I host Hospitality: Vendor portal built with Django?  
- I need a genuinely specialized vendor portal workflow covering property listings, service vendors and occupancy-related reporting.

## Workflow Steps
1. **Model the hospitality domain**  
   Create the tables room_types, inventory_movements, bookings, booking_lines, document_access. Room and package catalog lives in room_types; keep the sensitive classes (guest identity documents, payment details, stay history) out of this schema.
2. **Workflow step 1**  
   Model vendors scoped to the agency with roles  
3. **Workflow step 2**  
   Authorize document access by vendor and role (401, 403 negative tests)  
4. **Workflow step 3**  
   Store vendor documents in the private bucket  
5. **Workflow step 4**  
   Deploy and verify the negative tests and an authorized download  
6. **Deploy**  
   Run the synchronous deploy once and read the result. Re-running with no change is a no-op.  
   ```bash
   ample deploy . --name --public --start "python3 run.py" --env S3_ENDPOINT=... --env S3_REGION=... --env S3_BUCKET=... --env S3_ACCESS_KEY_ID=... --env S3_SECRET_ACCESS_KEY=...
   ```  
7. **Verify**  
   Run the pattern self-test(s) from the example (/p/private-document-library) and your own acceptance checks for the hospitality workflow.  
   ```bash
   ample logs --kind build
   ```

## Examples
- **Django pattern fixture**: Verified private document library basis for this blueprint.
  - Source Reference: tests/deploy-canaries/django-patterns

## Cost Estimate
- **Currency**: USD  
- **Monthly Amount**: 10.0  
- **Basis**: size prices from pricing.toml (loaded by the API) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty  
- **Components**:
  - App server:  
    - Size: s-1vcpu-1gb  
    - Quantity: 1.0  
    - Monthly Amount: 5.0  
  - Managed PostgreSQL database:  
    - Size: s-1vcpu-1gb  
    - Quantity: 1.0  
    - Monthly Amount: 5.0  
- **Note**: Always-on monthly price of the tested sizes; apps and databases auto-pause when idle. Buckets are allocation-priced per quota and not included.

## Limitations
- The technical basis (private document library on Django) was verified with the pattern fixture; the hospitality schema and workflow are an original design for this blueprint and were not executed as a separate application.
- No health, financial, privacy or other compliance claim is made. Guest identity documents are sensitive; only availability and booking status are modeled here.
- Public content and synthetic examples only until actual data-handling requirements have been reviewed.
- Verified on the python-3.12 template at s-1vcpu-1gb; region, request-duration limits and other sizes are unknown or unverified.