Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/EdgarJr30/proyecto-de-grado-cms/llms.txt

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

​
Overview

Work Requests is where all incoming maintenance requests are collected and reviewed before being converted into work orders. This module provides a centralized view of all pending requests that haven’t been accepted yet.
Work Requests are tickets with is_accepted = false. Once accepted and assigned, they become Work Orders.

​
Key Features

​
Kanban Board View

Work Requests are displayed in a Kanban-style board that provides:
  • Visual organization of unaccepted maintenance requests
  • Quick overview of request details including title, description, location, and priority
  • Attached images for visual context
  • Real-time updates when new requests are created

​
Advanced Filtering

The Work Requests page includes a powerful filter bar that allows you to narrow down requests by:

Search

Search by ticket ID, title, description, or requester name

Location

Filter by facility location

Priority

Filter by priority level (Baja, Media, Alta)

Date Range

Filter by creation date range

Image Status

Show only requests with attached images

Status

Filter by acceptance status

​
Accepting Requests

Before a work request becomes an active work order, it must be:
  1. Reviewed - Examine the request details, location, and priority
  2. Assigned - Assign a primary responsible technician
  3. Accepted - Mark as accepted to convert to a work order
1

Select requests to accept

Use checkboxes to select one or multiple work requests from the board.
2

Assign responsible technician

Choose a primary assignee for each request. This is required before acceptance.
3

Accept requests

Click the “Accept” button to convert the selected requests into work orders.
Work requests cannot be accepted without a primary assignee. The system will validate that each request has a responsible technician before acceptance.

​
Data Model

Work requests are stored in the tickets table with the following key fields: 
interface WorkRequest {
  id: number;
  title: string;
  description: string;
  location_id: number;
  location_name?: string;
  priority: 'Baja' | 'Media' | 'Alta';
  requester: string;
  created_by: string; // User ID
  incident_date: string;
  image?: string; // Comma-separated image paths
  is_accepted: false; // Always false for work requests
  is_archived: boolean;
  created_at: string;
}

​
Service Integration

Work Requests functionality is powered by several service methods:

​
Loading Requests

import { getTicketsByFiltersPaginated } from '@/services/ticketService';

// Fetch filtered work requests (server-side filtering)
const { data, count } = await getTicketsByFiltersPaginated(
  {
    q: 'search term',
    location_id: 1,
    priority: ['Alta', 'Media'],
    created_at: { from: '2024-01-01', to: '2024-12-31' },
    has_image: true
  },
  page,
  pageSize
);
See ~/workspace/source/src/services/ticketService.ts:452 for implementation details.

​
Accepting Requests

import { acceptTickets } from '@/services/ticketService';

// Accept multiple requests with assignees
await acceptTickets([
  { id: 101, assignee_id: 5 },
  { id: 102, assignee_id: 7 }
]);
See ~/workspace/source/src/services/ticketService.ts:331 for the acceptance logic.

​
Real-time Updates

The Work Requests board automatically refreshes when:
  • New requests are created
  • Requests are accepted (removed from the board)
  • Request details are updated
  • Data invalidation events are triggered
// Subscribe to data changes
import { onDataInvalidated } from '@/lib/dataInvalidation';

useEffect(() => {
  return onDataInvalidated('tickets', () => {
    // Reload work requests
    loadWorkRequests();
  });
}, []);

​
UI Components

​
WorkRequestsPage

Main page component at ~/workspace/source/src/pages/WorkRequestsPage.tsx:11 Key features:
  • Filter bar with advanced search options
  • Kanban board for visual organization
  • Smooth animations and transitions
  • Responsive layout for mobile and desktop

​
WorkRequestsBoard

Board component that renders the Kanban view at ~/workspace/source/src/components/dashboard/workRequest/WorkRequestsBoard.tsx Responsibilities:
  • Fetching and displaying work requests
  • Handling request selection
  • Managing acceptance workflow
  • Pagination and infinite scroll

​
WorkRequestsFiltersBar

Filter component at ~/workspace/source/src/components/dashboard/workRequest/WorkRequestsFiltersBar.tsx Features:
  • Search input with debouncing
  • Location dropdown
  • Priority multi-select
  • Date range picker
  • Image filter toggle

​
Permissions

Access to Work Requests requires appropriate permissions:
  • View: Users can view work requests assigned to their location
  • Accept: Users with tickets:manage permission can accept requests
  • Assign: Users with tickets:manage permission can assign technicians
Row-level security (RLS) policies enforce permission checks at the database level. UI-only permission checks are not sufficient.

​
Best Practices

​
For Administrators

  1. Regular Review - Check work requests daily to ensure timely response
  2. Appropriate Assignment - Assign requests to technicians with relevant skills
  3. Priority Management - Verify priority levels match actual urgency
  4. Image Review - Review attached images before assignment

​
For Requesters

  1. Clear Titles - Use descriptive titles that explain the issue
  2. Detailed Descriptions - Provide sufficient context for technicians
  3. Attach Images - Include photos when they help clarify the issue
  4. Accurate Location - Select the correct facility location
  5. Appropriate Priority - Set priority based on actual impact

​
Troubleshooting

​
Requests not appearing

  • Check filter settings - clear all filters to see all requests
  • Verify the request hasn’t been accepted already
  • Confirm the request is not archived
  • Check location permissions

​
Cannot accept requests

  • Verify you have tickets:manage permission
  • Ensure a primary assignee is selected
  • Check that the assignee exists and is active
  • Confirm the request hasn’t been accepted by another user

​
Filter performance

  • Use specific filters to reduce result set
  • Date range filters are processed server-side for optimal performance
  • Search queries require minimum 2 characters

Build docs developers (and LLMs) love

Get started for freeTalk to us