Staff — revisar + aprobar / rechazar solicitudes de regear

Los miembros envían regears en #Solicitar Regear; todo lo que envían aterriza aquí, en #Revisar solicitudes, para que el staff las triaje. Esta página recorre la cola de revisión de extremo a extremo.

Permisos

Necesitas el permiso Approve Regear Requests (bajo la sección Regear de Editar rol → Permisos) para ver este canal y actuar sobre las solicitudes. La mayoría de gremios conceden esto a los presets Staff de Regear / Regear Manager / Manager. Mira la Referencia de permisos para la tabla completa.

La cola de revisión

Abre #Revisar solicitudes desde la sección EQUIPO DE REGEAR de la barra lateral.

Parte superior de la página:

• Pestañas — Pendientes / Aprobadas / Rechazadas. Pendientes es la cola de trabajo; las otras dos son vistas de auditoría.
• Barra de herramientas (por pestaña Pendientes):
  • Checkbox Seleccionar todo — para acciones masivas por multiselección.
  • Filtro Tipo — Todos / Muertes / Overcharge.
  • Filtro Rol de guerra — limita a solicitudes de un rol concreto (útil cuando un rol domina en una CTA).
  • Buscar — acepta un nombre de víctima O un #event_id (el ID de evento de Albion de 9 dígitos con el prefijo #, p. ej. #475568182). El ID de evento es el mismo número que usa el feed de muertes de Albion y las URLs de enlace de evento, así que cuando un miembro te escribe en Discord con un enlace de baja preguntando «¿este llegó?» — copia el número final, ponle # delante, pégalo, y la cola filtra a solo esa fila. La misma búsqueda #event_id funciona en #Tareas Cut-off para que puedas rastrear una muerte desde la cola de revisión hasta el lado del empaquetador.

Cada tarjeta de la cola es una solicitud:

• Fila superior — nombre del miembro + personaje + badge del rol de guerra (Outcomers / FreezDawnera / Riderr en la captura).
• Centro — el enlace del evento de muerte (eventID) + una rejilla de equipo 3×4 mostrando los ítems perdidos con badges de validación por slot:
  • 🟢 OK — el slot coincide con el loadout del rol al tier esperado.
  • 🟡 Tier bajo — el ítem es de un tier menor del que pide el rol.
  • 🔵 Tier alto — el ítem es de un tier mayor.
  • 🔴 Inválido — el ítem no está en el loadout del rol en absoluto.
• Fila inferior — botones de acción + metadatos (timestamp UTC de la muerte + fama).

Las tres acciones por solicitud

✅ Aprobar

Aprueba la solicitud. Lo que pasa después depende del modo de regear del gremio:

• Modo ítem — la solicitud pasa a estado aprobada; el botón verde se llama Crear tarea Cut-off (individual + masivo). Haz clic para agrupar la solicitud en una tarea de empaquetado en #Tareas Cut-off. Mira Modo ítem — cut-off + locker.
• Modo silver — la solicitud pasa a estado aprobada; el botón verde se llama Pago (individual + masivo). Haz clic para acreditar silver en la cartera Silver Bank del miembro. Mira Modo silver — pago desde Silver Bank.

Misma acción Aprobar, botón de segundo paso distinto según la configuración del gremio. Hay un hueco deliberado entre aprobar y mover dinero/ítems — mira Ciclo de vida de dos pasos abajo.

❌ Rechazar

Rechaza la solicitud directamente. Se abre un prompt de motivo — escribe el motivo (p. ej. «Rol de guerra incorrecto — no asignado para esta CTA»), confirma. El miembro ve el rechazo + motivo en #Mis solicitudes.

Una vez rechazada, la solicitud es terminal — no vuelve a la cola. Si el miembro objeta, puede enviar una nueva solicitud con datos corregidos.

📁 Archivar

Quita la solicitud de la cola Pendientes sin aprobar ni rechazar — la mueve a la vista Archivadas. Úsalo cuando un miembro envía un duplicado, una solicitud antigua ya no accionable, o cualquier cosa que quieras esconder sin comprometerte a una decisión.

Restricciones de la política de validación

Lo que hace el validador con los problemas de tier bajo / tier alto / inválido lo decide la Política de regear del gremio (Configuración → Política de regear). Tres slots de política, cada uno configurado independientemente a uno de:

• Auto-rechazar — la solicitud se rechaza al enviar; nunca llega a esta cola.
• Permitir — la solicitud llega al staff con el problema anotado pero el botón Enviar nunca bloquea al miembro.
• Decisión del staff (por defecto) — la solicitud llega a la cola; el staff ve el problema + decide por solicitud.

Si tu gremio usa «Decisión del staff» para slots inválidos, espera ver solicitudes con badges 🔴 que aún son decisión tuya. La info por slot te ayuda a decidir entre Aprobar (perdonar), Rechazar (negar), o Aprobar-con-sobrescritura (p. ej. elegir un rol de guerra distinto en la aprobación que sí encaje con el equipo).

Sobrescritura del rol de guerra en aprobación

Haz clic en el badge del rol de guerra en la parte superior de una tarjeta de solicitud para cambiar el rol de guerra de esa solicitud concreta. Esto vuelve a ejecutar la validación contra el loadout del nuevo rol — útil cuando:

• El miembro se equivocó al elegir el rol al enviar.
• El equipo perdido se mapea de hecho a otro loadout de rol (p. ej. un Holy Healer llevó Lifecurse).
• Quieres aplicar un tope de silver distinto (en modo Rol de guerra — Tope sobre real, el tope del rol elegido es lo que aplica al Pago).

La sobrescritura se registra en el registro de auditoría por transparencia.

Acciones masivas por multiselección

Marca el checkbox Seleccionar todo (o checkboxes por tarjeta) → la barra de herramientas revela botones masivos de Aprobar / Rechazar / Archivar.

• Aprobar masivo — aprueba N solicitudes en una llamada. Cada solicitud sigue pasando por la lógica por modo — el modo ítem crea una tarea cut-off por solicitud (sin agrupación); el modo silver acredita N pagos uno tras otro pero como una sola acción por lotes.
• Rechazar masivo — abre un prompt de motivo; el mismo motivo se aplica a todas las seleccionadas. Úsalo para violaciones claras («Todas estas fallaron la verificación de rol de guerra»).
• Archivar masivo — mueve todas las seleccionadas fuera de pendientes. Sin prompt.

Ciclo de vida de dos pasos

Por qué aprobar y entregar son clics separados:

• El silver es moneda real. Aprobar = «sí, esta reclamación es válida». Pago = «sí, mueve el silver». Stripe / nómina / PayPal separan estos pasos igual.
• Ventana de reversión. Si detectas un error entre aprobar y pagar, rechaza la fila antes de que el dinero se mueva. Sin entradas compensatorias en el libro mayor.
• Lotes para día de pago. El staff puede acumular una semana de aprobadas y pagarlas todas en un único Día de pago — una entrada de auditoría, una notificación de Discord.
• Pendientes agnósticas al modo. A las solicitudes pendientes no les importa en qué modo esté el gremio. Si tu gremio cambia de modo (ítem → silver), las pendientes no necesitan migración — se comprometen al nuevo modo cuando se aprueban.

Para modo ítem el paso de agrupado es aún más visible: aprobar → la solicitud espera → agruparla en una tarea cut-off → el empaquetador hace el trabajo. La tarea cut-off es la entrega real — la aprobación es solo la luz verde.

Lo que ven los miembros

Una vez actúas sobre una solicitud, el miembro la ve actualizada en #Mis solicitudes (su rastreador personal):

• Aprobada → la tira de progreso avanza al paso 2 de 5.
• Rechazada → la fila se pone roja con tu motivo.
• Archivada → la fila desaparece de su vista Pendientes.

La tira de progreso luego continúa según avanza el flujo de tarea cut-off / Pago. Detalle completo del lado del miembro en Miembros — enviar un regear.

Páginas relacionadas

• Visión general del pipeline de regear — modos + bifurcación explicada
• Miembros — enviar un regear — el flujo de envío aguas arriba
• Modo ítem — cut-off + locker — qué pasa tras Aprobar en modo ítem
• Modo silver — pago desde Silver Bank — qué pasa tras Aprobar en modo silver
• Configuración — Política de regear — política de validación + selección de modo
• Regear de miembro — la vista de auditoría por miembro