SoloDB Documentation version 0.1-DEV Help

Service

System: Equipment and Service Management

1. Purpose

The Equipment and Service Management System is designed to manage reservations, services, and associated components for equipment and modules. It provides functionality for reservation handling, service property management, user permissions, notifications, and email communication.

This document outlines the key functional elements, dependencies, and workflows of the system based on its codebase.

2. Scope

The document covers the following modules and services:

  1. Service Module (/module/service)

    • ServiceService: Manages service operations tied to equipment and service properties.

3. Feature Description

3.1 Equipment Reservation (ReservationService)

The system provides advanced reservation management for equipment.

Functionalities

  • Setting up services

Key Entities and Attributes

  • Events:

    • Each intance of a service (execution, planning) is called a service event

3.2 Service Handling (Service Service)

Manages core operations related to service and its components.

Functionalities

  1. Service Management:

    • CRUD Operations: Adding, retrieving, parsing, and updating services.

    • Handles related components such as events and checklists.

    • Method: findServiceById(int $id): ?Service

  2. Property Management:

    • Retrieves visible service properties for display, filtered by type.

    • Assigns properties to services, correctly mapping property type to expected data.

    • Methods:

      • updateServiceProperties(Service $service, array $formDetails): void

      • parseServiceProperties(Service $service): array

  3. Deletion Validations:

    • Prevents deletion of services or properties that are in use, providing reasons.

    • Method: cannotDeleteServiceReasons(Service $service): array

4. Dependencies

Internal Dependencies:

  1. Equipment Module:
    Primary relationships between SerivceService and EquipmentService:

    • Fetch equipment

  2. Entity Management:
    All modules rely on Doctrine ORM:

    • Entities such as Service, Event, and Team are persisted and retrieved using repositories.

  3. Services:

    • ServiceService: For managing reservation-related queue impacts.

    • EventService: For emails related to reservation approvals or rejections.

External Dependencies:

  1. Email Service:

    • Used extensively for sending transactional emails, invitations (iCal), and notifications to impacted users.

    • Service: EmailService.

  2. TypeScript APIs:

    • Frontend interaction with reservations and modules handled by APIs (e.g., getService.ts).

5. Non-Functional Requirements

  • Performance:

    • Reservation query operations handle multiple date ranges and equipment filters efficiently using optimized database queries.

  • Scalability:

    • System allows dynamic addition of modules, properties, and categories.

    • Robust scheduler integration ensures handling of high volumes of overlapping jobs or queues.

  • Security:

    • User access controlled through permission levels (edit, view, approve).

    • Email addresses validated before sending notifications.

6. Open Issues & Future Enhancements

  1. Conflict Resolution Enhancements:

    • Refine overlapping reservation handling for scenarios involving multiple users and schedules.

  2. Logging & Auditing:

    • Implement detailed logging for reservation status changes, including emails sent and user actions.

7. Key API Endpoints

  1. Reservation Endpoints:

    • POST /new/service/event: Create a new service event.

    • GET /service/event/:id: Retrieve service event by ID.

This document provides an overview of the functional requirements and behavior of the equipment and service management system. Further refinements can be made as the system evolves.

12 June 2025
EquipmentCheck code style