Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/astrxnomo/eventify-app/llms.txt

Use this file to discover all available pages before exploring further.

Every event in Eventify is tagged with two orthogonal pieces of metadata: a category that describes the type of event, and a status that reflects its current availability. Categories help attendees discover events by interest, while statuses are managed partly by the system and partly by admins to communicate whether tickets are still on sale or the event has concluded.

​
Categories

Categories classify what kind of event is being offered. The application ships with six seeded defaults defined in CategoryTableSeeder:
CategoryDescription
MusicalConcerts, live music performances, and music festivals
TeatroTheatre productions, plays, and stage performances
DeportivoSporting events, competitions, and athletic activities
CulturalArt exhibitions, heritage events, and cultural gatherings
FamiliarFamily-friendly activities and children’s events
GastronómicoFood festivals, culinary events, and gastronomic experiences
These categories are inserted when the seeder is run: 
Category::create(['name' => 'Musical']);
Category::create(['name' => 'Teatro']);
Category::create(['name' => 'Deportivo']);
Category::create(['name' => 'Cultural']);
Category::create(['name' => 'Familiar']);
Category::create(['name' => 'Gastronómico']);
The category model exposes a hasMany relationship back to events, and the Event model resolves the inverse with belongsTo(Category::class).

​
Admin Management

Categories are managed exclusively by admins through the dashboard. The full CRUD interface is available under /dashboard/admin/categories:
ActionMethodRouteDescription
List all categoriesGET/dashboard/admin/categoriesDisplays all categories
Show create formGET/dashboard/admin/categories/createRenders the create form
Store new categoryPOST/dashboard/admin/categoriesSaves a new category
Show edit formGET/dashboard/admin/categories/{id}/editLoads a category for editing
Update categoryPUT/dashboard/admin/categories/{id}Persists the updated name
Delete categoryDELETE/dashboard/admin/categories/{id}Removes the category
The controller logic is intentionally simple — the only editable field is name: 
// Storing a new category
public function store(Request $request)
{
    $category = new Category();
    $category->name = $request->name;
    $category->save();

    return redirect()->route('categories.index');
}

// Updating an existing category
public function update(Request $request, string $id)
{
    $category = Category::find($id);
    $category->name = $request->name;
    $category->save();

    return redirect()->route('categories.index');
}
Deleting a category sets category_id to null on all associated events (enforced at the database level via onDelete('set null')). Existing events will lose their category assignment. Consider reassigning events to a different category before deleting one.

​
Statuses

Statuses communicate an event’s current availability to attendees. Three statuses are seeded by StatusTableSeeder:
IDNameMeaning
1DisponibleTickets are available for purchase
2AgotadoAll tickets have been sold; the event is sold out
3FinalizadoThe event has concluded; manually set by an admin
The seeder populates these in order, which is why their IDs are predictable and referenced directly in the application code: 
Status::create(['name' => 'Disponible']); // id = 1
Status::create(['name' => 'Agotado']);    // id = 2
Status::create(['name' => 'Finalizado']); // id = 3

​
Admin Management

Statuses are managed exclusively by admins through the dashboard under /dashboard/admin/status:
ActionMethodRouteDescription
List all statusesGET/dashboard/admin/statusDisplays all statuses
Show create formGET/dashboard/admin/status/createRenders the create form
Store new statusPOST/dashboard/admin/statusSaves a new status
Show edit formGET/dashboard/admin/status/{id}/editLoads a status for editing
Update statusPUT/dashboard/admin/status/{id}Persists the updated name
Delete statusDELETE/dashboard/admin/status/{id}Removes the status
The controller follows the same pattern as categories, with name as the only mutable field: 
// Storing a new status
public function store(Request $request)
{
    $statu = new Status();
    $statu->name = $request->name;
    $statu->save();

    return redirect()->route('status.index');
}
The statuses table uses onDelete('set null') for events. Deleting a status record will set status_id to null on all associated events. The three default statuses should not be deleted, as their IDs (1, 2, 3) are hardcoded into the event creation and ticket purchase logic.

​
How Status Affects Events

Status transitions happen through a combination of automatic system logic and manual admin overrides. The full lifecycle of an event’s status looks like this:
1

Event created with available capacity → Disponible

When EventController::store() saves a new event, it checks the initial capacity value and assigns the status accordingly:
if ($event->capacity > 0) {
    $event->status_id = 1; // Disponible
} else {
    $event->status_id = 2; // Agotado
}
An event created with any positive capacity starts as Disponible. An event created with a capacity of 0 starts immediately as Agotado.
2

All tickets sold → Agotado

Each time a ticket purchase is processed by TicketController::store(), the remaining capacity is decremented. Once it reaches zero, the status transitions automatically:
$event->capacity  -= $request->quantity;
$event->attendees += $request->quantity;

if ($event->capacity == 0) {
    $event->status_id = 2; // Agotado
}

$event->save();
This ensures the event detail page and explore listing always reflect real-time availability without any manual intervention.
3

Event concludes → Finalizado (manual)

The Finalizado status is not set automatically by the system. An admin must navigate to the event edit form (GET /dashboard/events/edit/{event}) and manually select Finalizado from the status dropdown. This is the appropriate action after an event’s end_date has passed and the organizer wants to communicate that no further activity is expected.
Because status id = 1 (Disponible) is the default value defined in the events table migration ($table->unsignedBigInteger('status_id')->default(1)), newly created events will fall back to Disponible at the database level even if status_id is not explicitly set in the application code.

​
Status Transition Summary

TriggerFromToActor
Event created, capacity > 0—DisponibleSystem
Event created, capacity == 0—AgotadoSystem
Ticket purchase depletes capacityDisponibleAgotadoSystem
Admin marks event as concludedAnyFinalizadoAdmin
Admin manually overrides statusAnyAnyAdmin

Build docs developers (and LLMs) love

Get started for freeTalk to us