<?php

namespace App\Services\Moodle;

/**
 * Qué le está pidiendo el Manager al Moodle del cliente.
 *
 * **Por qué existe esta clase y no dos servicios.** `MoodleSyncService` sabe hacer una
 * cosa difícil: llamar hacia fuera y traducir las nueve formas distintas en que eso puede
 * fallar —certificado autofirmado, DNS, servicios web apagados, token caducado, respuesta
 * que no es JSON, rechazo del plugin…— a una frase que dice qué hacer. Todo eso es igual
 * para cualquier función de servicio web que se le pida.
 *
 * Lo único que cambia entre pedir un inventario y pedir los datos de uso es **la función
 * que se llama y cómo se cuenta**. Duplicar el servicio para eso habría duplicado las
 * nueve traducciones, que es exactamente el tipo de copia que se acaba arreglando en un
 * sitio y no en el otro (MGR-024 fue eso mismo con siete copias).
 *
 * Las dos tareas programadas del plugin tienen su función de servicio web para poder
 * dispararlas a mano: `sync_plugins_task` → `tip::sync()` y `sync_stats_task` →
 * `tip::stats()`. Eso es lo que hay aquí.
 */
final readonly class QueSeLePide
{
    private function __construct(
        /** Función de servicio web del plugin. */
        public string $funcion,

        /** Sufijo del cerrojo, para que pedir una cosa no bloquee la otra. */
        public string $clave,

        /** Cómo se llama esto en un mensaje: «la sincronización», «los datos de uso». */
        public string $nombre,

        /** Lo que se dice cuando sale bien. */
        public string $exito,

        /** Código del log del panel al lanzar, y al fallar. */
        public string $codigoOk,
        public string $codigoFallo,

        /**
         * Qué se responde cuando el sitio no ha dado su token.
         *
         * Se explica aparte porque **no es un error de red ni una avería**: es que ese
         * sitio nunca nos lo ha enviado, y la acción a tomar es otra.
         */
        public string $sinToken,
    ) {}

    /** El inventario de plugins: `sync_plugins_task` del plugin. */
    public static function sincronizacion(): self
    {
        return new self(
            funcion: 'local_tresipunt_auth_sync',
            clave: 'sync',
            nombre: 'la sincronización',
            exito: 'Sincronización lanzada. El Moodle ha respondido correctamente.',
            codigoOk: '16005',
            codigoFallo: '16006',
            sinToken: 'Este entorno no ha enviado su token de servicios web. Solo se puede '
                . 'lanzar desde el Manager cuando el sitio ha sincronizado al menos una '
                . 'vez con una versión del plugin que lo envíe.',
        );
    }

    /**
     * La foto diaria de uso: `sync_stats_task` del plugin.
     *
     * **El caso que lo pedía.** La pantalla «Uso del entorno» sale vacía y dice «último
     * dato recibido: nunca», y hasta ahora la única salida era esperar a la madrugada
     * —la tarea del plugin corre sobre las 02:00— o entrar al Moodle del cliente a
     * lanzarla a mano. Con esto se pide y se ve en el momento.
     *
     * **Ojo con lo que devuelve.** El Moodle contesta que ha aceptado el encargo, no los
     * datos: quien manda la foto al Manager es el propio Moodle, en una llamada aparte a
     * nuestra API. Así que «respondido correctamente» significa «lo va a mandar», y la
     * pantalla tiene que recargar para verlo.
     */
    public static function datosDeUso(): self
    {
        return new self(
            funcion: 'local_tresipunt_stats_data',
            clave: 'stats',
            nombre: 'los datos de uso',
            exito: 'Datos de uso pedidos. El Moodle los está enviando.',
            codigoOk: '16032',
            codigoFallo: '16033',
            sinToken: 'Este entorno no ha enviado su token de servicios web, así que el '
                . 'Manager no puede pedirle nada. Guárdalo en «Conexión con el Moodle» y '
                . 'vuelve a intentarlo.',
        );
    }
}