Initial commit
This commit is contained in:
+88
@@ -0,0 +1,88 @@
|
|||||||
|
1. Introduction & Purpose
|
||||||
|
This document outlines the specifications for a web-based application built on the LAMP (Linux, Apache, MySQL, PHP) stack. The primary purpose of this application is to manage DJs, their profiles, and their event schedules (including radio shows, club gigs, special events, etc.). A key output will be an aggregated list of all upcoming events, formatted for easy integration into a WordPress website front page via a widget. The system will allow DJs to manage their own profiles and add their own individual events/gigs, while Administrators will have overarching control, including the ability to manage users, event types, and complex recurring schedule assignments (like a weekly radio show roster with specific constraints).
|
||||||
|
2. Target Audience
|
||||||
|
• DJs (Users): Will use an invitation link to complete registration, log in to manage their profile information, view their assigned schedule, add their own individual events/gigs, request removal from assigned events, and mark their unavailability.
|
||||||
|
• Administrator(s): Will manage the system, initiate DJ invitations, manage DJ accounts, define event categories, oversee all schedules, approve/deny DJ removal requests (optionally triggering re-assignment), and use advanced tools for assigning DJs to recurring slots. Multiple admin accounts are supported.
|
||||||
|
• Website Visitors: Will view the upcoming events widget on the WordPress site and click through to see individual DJ profiles.
|
||||||
|
3. Core Features Overview
|
||||||
|
• User Authentication (Login/Logout for DJs and Admin).
|
||||||
|
• Admin-initiated DJ Invitation and DJ Self-Registration/Profile Completion.
|
||||||
|
• DJ Profile Management (Display Name, Cropped Photo/Logo Upload, Flexible Social Links, Password Change).
|
||||||
|
• DJ Availability Management (Marking unavailable dates).
|
||||||
|
• Individual Event Creation/Management by DJs.
|
||||||
|
• Admin Management of DJs, Event Types, and All Events.
|
||||||
|
• DJ Request mechanism for removal from Admin-assigned events (requires Admin approval, can trigger auto-reassignment).
|
||||||
|
• Admin creation and management of recurring "Schedule Templates" (e.g., Weekly Radio Show).
|
||||||
|
• Advanced Admin tool for assigning DJs to recurring schedule slots, considering:
|
||||||
|
o DJ availability/frequency limits (max 2 times/calendar month).
|
||||||
|
o DJ eligibility for specific days/slots.
|
||||||
|
o DJ marked unavailability dates.
|
||||||
|
o Randomized assignment option with rotation logic (prioritizing DJs not scheduled in the previous calendar month).
|
||||||
|
• Aggregated Upcoming Events Feed/Widget data source (Public API).
|
||||||
|
• Public-facing DJ Profile Pages linked from the event feed.
|
||||||
|
• Support for Multiple Administrator roles.
|
||||||
|
• Admin notifications (Email & In-App) for pending DJ requests.
|
||||||
|
4. System Architecture
|
||||||
|
• Platform: LAMP Stack (Linux, Apache, MySQL, PHP). Must be compatible with standard shared hosting environments like Hostinger running PHP 8+ and MySQL.
|
||||||
|
• Database: MySQL (or MariaDB).
|
||||||
|
• Backend Logic: PHP. Use of a modern, well-maintained PHP framework (e.g., Laravel, Symfony, CodeIgniter) is strongly recommended for structure, security, performance, maintainability, and compatibility with standard hosting.
|
||||||
|
• Frontend: HTML, CSS, JavaScript (Likely using a framework like Bootstrap or Tailwind for styling, and JavaScript libraries for features like date pickers and image cropping).
|
||||||
|
• WordPress Integration: The application will provide data via a dedicated public API endpoint outputting JSON to be consumed by a custom WordPress widget or plugin.
|
||||||
|
5. Detailed Functional Specifications
|
||||||
|
5.1. User Management & Authentication
|
||||||
|
* Roles: Admin, DJ.
|
||||||
|
* Admin Functionality: Initiate DJ Invitation (Name, Email -> sends secure registration link); View, Edit, Deactivate/Reactivate DJ accounts; Reset DJ passwords; Manage Admin Roles (Grant/Revoke Admin privileges).
|
||||||
|
* DJ Functionality: Register via invitation link (Set Password, initial profile fields); Log in; Change password.
|
||||||
|
* Security: Secure password hashing (password_hash()); Secure sessions; Expiring/single-use invitation links.
|
||||||
|
5.2. DJ Profile Page (Managed by DJ)
|
||||||
|
* Access: DJs edit own profile; Admins edit any profile.
|
||||||
|
* Fields: Display Name (req); Profile Photo/Logo (upload JPG/PNG/GIF, max 2MB, interactive crop tool); Social Media Links (flexible Label + URL pairs, add/remove); Password Change (Current, New, Confirm).
|
||||||
|
* Availability Management: Interface (e.g., calendar) for DJs to mark unavailable dates/ranges.
|
||||||
|
* Public View: Read-only version (no password/availability) linked from event list.
|
||||||
|
5.3. Event Management
|
||||||
|
* Event Creation Form (DJs & Admins): Event Name (req), Event Type (req, Admin list), Date (req), Start Time (req), End Time (req), Location/Venue Name (req), Location Address (optional, for map), Short Comment/Description (optional).
|
||||||
|
* DJ Permissions:
|
||||||
|
* CRUD operations on own self-added events.
|
||||||
|
* View Admin-assigned events.
|
||||||
|
* (Revised) Submit "Removal Request" for an assigned event, including an optional note. Cannot directly edit/delete assigned events.
|
||||||
|
* Admin Permissions:
|
||||||
|
* CRUD operations on all events.
|
||||||
|
* (Revised) Manage Removal Requests: Interface to view pending requests. Admins receive notifications (Email and In-App indicator on Admin login/dashboard). Can Approve (removing DJ from the event) or Deny (notifying DJ). If Approved, the system should provide an option or automatically attempt to re-assign another eligible DJ to the now-vacant slot using the assignment logic.
|
||||||
|
* Map Link: Generate Google Maps link if Address provided.
|
||||||
|
* Event Status: Implied statuses like "Confirmed," "Pending Removal Request," "Vacant Slot".
|
||||||
|
5.4. Admin Area
|
||||||
|
* Dashboard: Overview, (Revised) display of pending removal requests/notifications.
|
||||||
|
* User Management: Invite DJs, manage accounts, manage Admin roles.
|
||||||
|
* Event Type Management: CRUD for event categories.
|
||||||
|
* Master Event List: View/Filter/Search/Edit/Delete all events.
|
||||||
|
* Pending Requests Queue: Interface to manage DJ removal requests (Approve/Deny).
|
||||||
|
* Schedule Template Management: Create/Edit/Delete named templates with slots (Day, Start, End).
|
||||||
|
* DJ Availability/Preferences Management: Define max frequency (e.g., 2/calendar month); Define Slot Eligibility; View DJ unavailability.
|
||||||
|
* Schedule Assignment Tool:
|
||||||
|
* Select Template & Date Range.
|
||||||
|
* Option to "Assign DJs". Algorithm must:
|
||||||
|
1. Identify eligible DJs per slot (Eligibility rules).
|
||||||
|
2. Exclude DJs unavailable on the slot date.
|
||||||
|
3. Check "Max frequency per calendar month" limit.
|
||||||
|
4. (Revised) Prioritize DJs not scheduled within the previous calendar month for better rotation. Randomize among equally eligible/rotated candidates.
|
||||||
|
* Display proposed schedule for Admin review/override/confirmation.
|
||||||
|
* Saving creates Event entries linked to DJs.
|
||||||
|
* (Revised) The core assignment logic should also be callable to fill single vacant slots resulting from approved removal requests.
|
||||||
|
5.5. Upcoming Events Widget (Data Source)
|
||||||
|
* Functionality: Provide aggregated list of future events, sorted chronologically.
|
||||||
|
* Data Provided: Date, Start/End Time, Event Name, DJ Name (linked to profile URL), Location Name (linkable), Event Type, Comment.
|
||||||
|
* Format: (Revised) Public API endpoint returning JSON. No authentication required for this specific endpoint.
|
||||||
|
* Example Endpoint: https://your-app-domain.com/api/upcoming-events?limit=10
|
||||||
|
* JSON structure remains as previously defined.
|
||||||
|
6. Non-Functional Requirements
|
||||||
|
• Usability: Clean, intuitive interface.
|
||||||
|
• Performance: Efficient handling of 60+ DJs, events. Optimized queries.
|
||||||
|
• Security: Standard web security practices (Input validation, XSS/SQLi prevention, CSRF protection, secure auth/sessions).
|
||||||
|
• Maintainability: Well-organized, commented code, preferably using a recommended PHP framework.
|
||||||
|
• Portability: Deployable on standard LAMP shared hosting (e.g., Hostinger) with PHP 8+/MySQL.
|
||||||
|
7. WordPress Integration Strategy
|
||||||
|
• Independent application exposing a (Revised) public API endpoint.
|
||||||
|
• A separate WordPress plugin/widget fetches data from the public API and displays it on the WordPress site.
|
||||||
|
8. Next Steps
|
||||||
|
1. This finalized proposal serves as the detailed requirements specification.
|
||||||
|
2. Proceed with development based on this document.
|
||||||
Reference in New Issue
Block a user