LuckPerms: permisos temporales para el equipo de un evento
Para dar permisos al equipo de un evento, utiliza un grupo específico de LuckPerms con una duración limitada, restringe dónde se aplica esa pertenencia y ensaya tanto la caducidad como la retirada anticipada. El trabajo termina cuando la persona puede realizar las tareas acordadas durante su turno y pierde esas capacidades adicionales al finalizar. Ver una cuenta atrás no basta para comprobarlo.
Esta guía está dirigida a responsables de comunidades y equipos de eventos que ya utilizan LuckPerms en un servidor Java. Presupone que un administrador puede revisar un grupo existente y ejecutar los comandos de LuckPerms. El ejemplo es una propuesta de ensayo, no una prueba realizada en tu servidor. Los accesos externos, como SSH, los roles de Discord o la cuenta del proveedor de infraestructura, requieren una revisión independiente.
Define el turno antes de asignar un rango
Anota las tareas reales de la persona: consultar avisos, sacar a un participante de un lugar donde se ha quedado atascado o manejar una función concreta del evento. Para cada tarea, identifica el plugin responsable, los nodos de permiso que documenta y sobre quién debe poder actuar. Un comando de teletransporte que permite mover a cualquier jugador puede superar lo necesario para ese puesto.
Utiliza un grupo dedicado, por ejemplo eventstaff, cuyos permisos y grupos heredados hayas revisado. No lo hagas heredar de un grupo de administradores para resolver un único comando que falta. Anota también varias capacidades que deben seguir bloqueadas, como gestionar permisos o utilizar herramientas de moderación ajenas al encargo. El responsable del evento debe dar el visto bueno a esta lista antes del ensayo técnico.
Prepara una ficha con estos campos:
- Identidad de la cuenta, preferiblemente con su UUID verificado, y persona que autoriza el acceso.
- Grupo, tareas permitidas, tareas excluidas y ámbito de servidor o mundo.
- Inicio del turno, final previsto con zona horaria y administrador que puede retirar el acceso antes de tiempo.
- Evidencias del ensayo y comprobación posterior al evento.
Este trabajo encaja en la preparación y los ensayos descritos en la página de eventos de Minecraft de Mineando. Acordad quién verifica los accesos junto con las instrucciones de entrada y el calendario del evento.
Comprueba qué significa el contexto de servidor
En este ejemplo, server=event debe coincidir con el valor server configurado en LuckPerms en el servidor de destino. No tiene por qué coincidir con el dominio ni con el nombre mostrado en el menú de servidores. La documentación de contextos de LuckPerms explica esta correspondencia.
Consulta el contexto del usuario conectado con /lp user EventHelper info. Sustituye EventHelper por la cuenta verificada. Haz la prueba en el servidor donde el plugin del evento procesa la acción. Una cuenta desconectada no tiene un contexto actual de jugador, por lo que consultarla sin conexión no sustituye la prueba dentro del juego.
En una red, enumera los destinos a los que puede desplazarse esa persona: servidor del evento, lobby y supervivencia habitual. Una pertenencia con contexto limita esa vía concreta de herencia. Los permisos globales existentes, otro grupo o el acceso de operador pueden seguir concediendo la misma capacidad. Si no puedes explicar los otros accesos de la cuenta, resuélvelo antes de añadir un rango más.
Los comandos siguientes utilizan /lp en el servidor de juego. Las instalaciones del proxy tienen sus propios alias y particularidades de contexto; no copies el ejemplo en la consola del proxy suponiendo que así compruebas los permisos del servidor de destino.
Asigna la pertenencia temporal de forma explícita
Con el grupo revisado y el contexto confirmado, un administrador podría asignar un turno de tres horas:
/lp user EventHelper parent addtemp eventstaff 3h deny server=event
/lp user EventHelper parent info
El nombre, grupo, duración y contexto son valores de ejemplo. Las tres horas empiezan cuando el comando se ejecuta correctamente, no cuando empieza el evento programado. Si lo lanzas durante la preparación de la mañana, podría caducar antes de una emisión por la tarde. Comprueba enseguida que la caducidad resultante coincide con la ficha del turno.
El modificador explícito deny rechaza un nodo temporal duplicado. Resulta útil cuando dos operadores podrían asignar el mismo acceso. Investiga un rechazo en lugar de ampliar el plazo sin revisar. LuckPerms también admite accumulate y replace; este último conserva la duración más larga, así que no debe darse por hecho que acorta el acceso. Consulta la referencia oficial de comandos de grupos heredados.
Ensaya con una duración breve y una cuenta normal
En un entorno de prueba controlado, usa una concesión corta, como 2m, y una cuenta sin OP cuyos permisos iniciales conozcas. Repite las comprobaciones con la cuenta que utilizará finalmente la persona del equipo para detectar permisos heredados de otros grupos. No pruebes comandos de moderación destructivos sobre participantes reales.
| Comprobación | Resultado esperado |
|---|---|
| Antes de conceder el grupo | La cuenta no puede realizar las tareas adicionales del equipo. |
| Concesión activa en el servidor del evento | Cada tarea acordada funciona sobre un objetivo de prueba. |
| Concesión activa en el lobby o en supervivencia | Las funciones adicionales del evento siguen bloqueadas. |
| Acción privilegiada ajena al puesto | Permanece bloqueada durante todo el turno. |
| Tras caducar, sin desconectarse | La tarea adicional se deniega al volver a intentarla. |
| Tras volver a entrar | Se mantiene la misma situación inicial de permisos limitados. |
Registra resultados reales, no solo si ha cambiado el prefijo del rango. Incluye las versiones y cualquier configuración del plugin que afecte a la acción. Si falla la prueba de caducidad, no uses ese grupo en el evento hasta entender la causa. Una función puede conservar un estado después de la comprobación de permiso que permitió activarla; revisa la interacción completa, además del comando inicial.
Ante un resultado inesperado, /lp user EventHelper permission check YOUR_PERMISSION_NODE ayuda a examinar la decisión de permisos. Sustituye YOUR_PERMISSION_NODE por el nodo real del plugin correspondiente. La documentación de comandos de permisos describe esta consulta.
Si hace falta, activa brevemente /lp verbose on EventHelper, reproduce una acción segura y termina con /lp verbose off. La documentación de verbose explica cómo observar comprobaciones filtradas. Guarda la evidencia útil en la ficha antes de detenerlo: off borra las coincidencias recopiladas. Este procedimiento básico no requiere subir una captura a un visor público.
Retira el acceso antes de tiempo y cierra el turno
Si la persona termina antes, elimina su pertenencia temporal con el mismo contexto:
/lp user EventHelper parent removetemp eventstaff server=event
Repite inmediatamente las pruebas previstas para después de la caducidad. Esto elimina la pertenencia temporal indicada; no retira todos los permisos que la cuenta pueda obtener por otras vías. Si una tarea sigue funcionando, revisa otras concesiones y el comportamiento del plugin. Evita borrar todos los grupos como arreglo improvisado: puede haber roles legítimos de la comunidad que deban conservarse.
Cierra la ficha con la hora de retirada o caducidad, quién la comprobó y cualquier excepción. Revisa por separado los otros sistemas de acceso. Si el ensayo descubre carencias más amplias de operación, adjunta la matriz de tareas y los resultados a una consulta sobre infraestructura gestionada. Mineando trabaja en proyectos de pago con alcance individual; el soporte continuado y la cobertura en directo se acuerdan por separado.
