81 lines
2.2 KiB
Markdown
81 lines
2.2 KiB
Markdown
# 06. Admin Console
|
|
|
|
## Purpose
|
|
|
|
Define the back office screens and admin actions needed to run the business.
|
|
|
|
## Scope
|
|
|
|
- Secure admin login.
|
|
- Property management.
|
|
- Image management.
|
|
- Amenity management.
|
|
- Pricing management.
|
|
- Availability management.
|
|
- Booking management.
|
|
- Payment record view.
|
|
- Enquiry management.
|
|
- Content page management.
|
|
- Testimonial management.
|
|
- Site settings.
|
|
|
|
## Proposed Admin Structure
|
|
|
|
### Core Admin Areas
|
|
|
|
- Dashboard / overview
|
|
- Properties
|
|
- Availability and pricing
|
|
- Bookings
|
|
- Payments
|
|
- Enquiries
|
|
- Content pages
|
|
- Testimonials
|
|
- Site settings
|
|
|
|
### Admin Actions
|
|
|
|
- Create, edit, publish, unpublish, and archive properties.
|
|
- Upload, reorder, and remove property images.
|
|
- Add and assign amenities.
|
|
- Set and override pricing rules.
|
|
- Add availability blocks and exceptions.
|
|
- Review bookings and payment records.
|
|
- Read and manage enquiries.
|
|
- Edit static pages and testimonials.
|
|
- Update site-wide settings and defaults.
|
|
|
|
### Admin Guardrails
|
|
|
|
- Admin login is required for all back office actions.
|
|
- Sensitive changes should be scoped by role or privilege if roles are added later.
|
|
- The admin cannot silently break the booking/payment truth model.
|
|
|
|
## What Needs to Be Done
|
|
|
|
- Define the admin navigation and main screens.
|
|
- Define CRUD operations for each managed entity.
|
|
- Define admin permissions and safe defaults.
|
|
- Define which screens need audit or status history.
|
|
- Define what the admin can override and what they cannot.
|
|
- Define which booking/payment states are editable versus read-only.
|
|
- Define whether audit history is required for important admin changes.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- Every admin requirement from the spec is mapped to a screen or action.
|
|
- The admin surface is grouped in a way that matches day-to-day usage.
|
|
- Sensitive changes have clear rules and boundaries.
|
|
- The admin plan supports future implementation without redesigning the workflow.
|
|
- The admin model does not conflict with booking, payment, or availability rules.
|
|
|
|
## Dependencies
|
|
|
|
- Content architecture and data model.
|
|
- Booking, availability, and pricing.
|
|
- Payments and notifications.
|
|
|
|
## Notes
|
|
|
|
- Any admin override needs a clear rule to avoid conflict with booking or payment state.
|