La caja de herramientas de Admin: suplantación, liberación forzada y flujos atascados
Botones con motivo obligatorio, radio de acción reducido y una fila de auditoría para los problemas de inquilino que la interfaz normal no puede resolver.
La caja de herramientas de Admin es la vía de escape controlada para los problemas de inquilino que la interfaz normal no puede resolver: un inquilino, una fila, un flujo atascado, con motivo obligatorio, evento de auditoría y el menor radio de acción posible. Nada de esto es una versión rápida del trabajo normal. Todo esto es romper el cristal, con un libro de registro al lado del cristal.
Suplantación con escritura bloqueada
La herramienta mayor. Desde la página de detalle de un usuario en /admin/users/[slug], el personal de plataforma inicia una sesión suplantada para ver la aplicación como la ve ese usuario del inquilino: se acabó el ping-pong de correos sobre qué botón está en gris. El inicio exige un motivo de al menos cinco caracteres, la sesión dura 30 minutos y es de solo lectura: durante la suplantación toda petición que mute algo se rechaza, las server actions se niegan a escribir y el banner lo dice. Iniciar una sesión nueva revoca automáticamente la anterior. El inicio y el fin se escriben los dos en el registro de actividad con el motivo, así que un inquilino que pregunta “¿alguien de la plataforma ha mirado nuestra cuenta?” recibe una fila, no una conjetura. Los clientes de Trade-In tienen su propia vía desde /admin/customers/[id], con el mismo motivo, el mismo reloj y el mismo bloqueo de escritura.
La única finalización forzada
Existe exactamente una finalización forzada, y es para las recogidas atascadas: una recogida encallada en un estado no terminal muestra en su página de detalle una salida de emergencia, solo para plataforma, que la empuja hasta completada y escribe la anulación en el registro de auditoría. Las sesiones de recepción, las etapas de flujo de trabajo y las ejecuciones de liquidación no tienen un botón así, a propósito; se resuelven por sus flujos normales, y un botón de forzar que nadie necesita es un botón de forzar que alguien acabará pulsando.
Superficies de administración de Escrow
La confirmación y cancelación ordinarias de depósitos en /admin/escrow/pending requieren dos propietarios de la plataforma. Las excepciones están disponibles para propietarios y personal de la plataforma: cancelar un depósito que siga pendiente tras al menos siete días con un motivo de al menos diez caracteres, o aprobar la propuesta de confirmación de otra persona con un motivo de al menos veinte caracteres. /admin/escrow/disputes contiene la revisión de disputas. /admin/escrow/force-release está reservado a propietarios: elegir vendedor, comprador o reparto, indicar un motivo de al menos treinta caracteres y repetir el número exacto de escrow. Las partes deben sumar el importe total.
Cada una de estas tres correcciones guarda conjuntamente el estado, la aprobación y los asientos que correspondan, el evento del expediente y la auditoría obligatoria. Un error conserva el estado anterior. El mismo actor que repite la misma instrucción no crea una segunda corrección; los asientos existentes no se sobrescriben. Se comprueban de nuevo los permisos actuales y una sesión activa de suplantación bloquea la acción. El motivo operativo permanece en el expediente. Registrar una liberación o un reembolso no inicia una transferencia bancaria; forzar una decisión financiera no resuelve automáticamente el fondo de una disputa existente.
Sincronización con Blancco, a demanda
La sincronización con Blancco por inquilino se ejecuta según una programación, pero un inquilino que acaba de conectar la integración no debería esperar al siguiente tic. La tarjeta de integraciones en /admin/organizations/[slug] muestra el estado de la conexión y la última sincronización, y un botón “Sincronizar ahora” ejecuta el mismo camino de código antes de tiempo.
Usuarios varados y correo sin verificar
La página de detalle de usuario es también el banco de recuperación. Muestra el estado de verificación del correo y el estado de la cuenta, y ofrece reenviar la invitación o el correo de verificación, restablecer la contraseña, suspender y reactivar, todo sin abrir antes el formulario de edición. Un usuario que se ha quedado sin un contexto de organización sano está varado; el personal de plataforma lo recupera hacia una organización nueva introduciendo un nombre y un slug. El borrado de una cuenta es una vía de eliminación, no un borrado de fila, y nunca está disponible para la cuenta propia.
Purga del almacenamiento de un inquilino
El botón más peligroso de /admin/storage es “Purgar almacenamiento”, y es solo para el propietario; cualquier otro rol de plataforma recibe un rechazo del servidor y no se toca nada. El diálogo carga primero una vista previa de exactamente lo que se iría —registros de documento sin enlazar, registros con fichero ausente y objetos huérfanos, con sus recuentos—, después pide el nombre exacto de la organización, y solo habilita el botón rojo cuando hay algo que purgar y el nombre coincide. Los documentos adjuntos a un registro de negocio vivo nunca se cuentan y nunca se eliminan. El resultado se registra en modo fail-closed con los recuentos; si el registro no se puede escribir, la purga no se ejecuta. No hay deshacer, y por eso hay vista previa.
audit_events es de solo añadir
La tabla audit_events tiene triggers de base de datos que rechazan UPDATE y DELETE, y cada fila está encadenada a la anterior con un hash que delata manipulaciones, de modo que un hueco o una reescritura se ven. Se pueden insertar filas nuevas; la original se queda. La caja de herramientas de Admin puede arreglar lo que está roto. No puede ordenar lo que quedó registrado.