Staff — проверка + одобрение / отклонение запросов ригир

Участники подают ригир в #Запросить ригир; всё, что они подают, приземляется здесь, в #Проверка запросов, для сортировки staff. Эта страница проходит по очереди проверки сквозным образом.

Права

Нужно право Approve Regear Requests (в секции Regear в Edit Role → Permissions), чтобы видеть этот канал и действовать с запросами. Большинство гильдий выдают это пресетам ролей Regear Staff / Regear Manager / Manager. Полная таблица — в Справочник прав.

Очередь проверки

Открой #Проверка запросов из секции КОМАНДА ригир в боковой панели.

Верх страницы:

• Вкладки — Pending / Approved / Rejected. Pending — рабочая очередь; остальные две — аудит-виды.
• Тулбар (на вкладке Pending):
  • Чекбокс Select all — для пакетных действий.
  • Фильтр Type — All / Deaths / Overcharge.
  • Фильтр War Role — сузить до конкретной вар-роли (полезно, когда одна роль доминирует в CTA).
  • Search — принимает имя жертвы ИЛИ #event_id (9-значный event ID Albion с префиксом #, например #475568182). Event ID — то же число, которое используют death-лента и URL event-ссылок Albion; когда участник пишет тебе в Discord с kill-ссылкой и спрашивает «этот прошёл?» — скопируй последнее число, добавь #, вставь, и очередь отфильтруется до одной строки. Тот же поиск по #event_id работает в #Задачи выдачи, чтобы проследить одну смерть от очереди проверки до пакера.

Каждая карточка в очереди — один запрос:

• Верхняя строка — имя участника + персонаж + бейдж вар-роли (Outcomers / FreezDawnera / Riderr на скриншоте).
• Середина — ссылка на событие смерти (eventID) + сетка экипировки 3×4 с потерянными предметами + бейджи валидации по слотам:
  • 🟢 OK — слот совпадает с лоадаут-ом роли на ожидаемом тире.
  • 🟡 Under-tier — предмет ниже тиром, чем требует роль.
  • 🔵 Over-tier — предмет выше тиром.
  • 🔴 Invalid — предмет вообще не в лоадаут-е роли.
• Нижняя строка — кнопки действий + метаданные (UTC-время смерти + fame).

Три действия на запрос

✅ Approve

Одобряет запрос. Что произойдёт дальше — зависит от режима ригир гильдии:

• Item-режим — запрос переходит в состояние approved; зелёная кнопка называется Create Cut-off Task (одиночное + пакетное). Кликни, чтобы упаковать запрос в задачу паковки в #Задачи выдачи. См. Item-режим — выдача + шкафчик.
• Silver-режим — запрос переходит в состояние approved; зелёная кнопка называется Payout (одиночное + пакетное). Кликни, чтобы зачислить silver на кошелёк Банк silver участника. См. Silver-режим — выплата из Банк silver.

Одно и то же действие Approve, разная вторая кнопка в зависимости от настройки гильдии. Между одобрением и реальным движением денег/предметов намеренно есть разрыв — см. Двухшаговый цикл ниже.

❌ Reject

Отклоняет запрос полностью. Открывается запрос причины — введи причину (например, «Wrong war role — not assigned for this CTA»), подтверди. Участник видит отказ + причину в #Мои запросы.

После отклонения запрос терминален — он не возвращается в очередь. Если участник возражает, может подать новый запрос с исправленными данными.

📁 Archive

Убирает запрос из очереди Pending без одобрения или отклонения — переносит в вид Archived. Используй, когда участник подал дубликат, старый запрос, который больше не актуален, или всё, что хочешь скрыть, не принимая решение.

Гейтинг по политике валидации

Что валидатор делает с проблемами under-tier / over-tier / invalid — решает Regear Policy гильдии (Настройки → Regear Policy). Три слота политики, каждый независимо настроен как:

• Auto-reject — запрос отклонён при подаче; никогда не попадает в эту очередь.
• Allow — запрос проходит к staff с отмеченной проблемой, но кнопка Submit участника не блокируется.
• Staff decision (по умолчанию) — запрос попадает в очередь; staff видит проблему + решает по запросу.

Если гильдия использует "Staff decision" для invalid-слотов, ожидай запросы с 🔴 бейджами, по которым решать всё равно тебе. Информация по слоту помогает выбрать между Approve (простить), Reject (отказать) или Approve-with-override (например, выбрать другую вар-роль при одобрении, которая совпадает со снаряжением).

Переопределение вар-роли при одобрении

Кликни по бейджу вар-роли в верхней части карточки запроса, чтобы изменить вар-роль для этого конкретного запроса. Это перезапускает валидацию против лоадаут-а новой роли — полезно, когда:

• Участник промахнулся при выборе вар-роли при подаче.
• Потерянное снаряжение фактически соответствует лоадаут-у другой роли (например, Holy Healer играл Lifecurse).
• Хочешь применить другой silver cap (в режиме War Role — Capped by actual применяется cap выбранной роли при Payout).

Переопределение записывается в журнал действий для прозрачности.

Пакетные действия мульти-выбора

Отметь чекбокс Select all (или чекбоксы на карточках) → тулбар покажет пакетные кнопки Approve / Reject / Archive.

• Bulk Approve — одобряет N запросов одним вызовом. Каждый запрос всё ещё проходит логику режима — item-режим создаёт по одной задаче выдачи на запрос (без объединения); silver-режим зачисляет N выплат подряд, но как одно пакетное действие.
• Bulk Reject — открывает запрос причины; одна и та же причина применяется ко всем выбранным. Используй для очевидных нарушений («Все они провалили проверку вар-роли»).
• Bulk Archive — убирает всё выбранное из pending. Без запроса.

Двухшаговый цикл

Почему одобрение и доставка — разные клики:

• Silver — реальная валюта. Approve = «да, это валидная претензия». Payout = «да, двигаем silver». Stripe / payroll / PayPal — все делят это.
• Окно отмены. Если заметил ошибку между одобрением и оплатой, отклони строку до движения денег. Компенсационные записи не нужны.
• Пакетирование для payday. Staff может накопить неделю одобренных и оплатить их все в один Payday — одна запись в журнале действий, одно уведомление в Discord.
• Pending — режим-агностично. Ожидающим запросам всё равно, в каком режиме гильдия сейчас. Если гильдия переключает режим (item → silver), ожидающие не требуют миграции — они привяжутся к новому режиму при одобрении.

В item-режиме шаг объединения ещё заметнее: approve → запрос ждёт → объединение в задачу выдачи → пакер делает работу. Задача выдачи и есть фактическая передача — одобрение — это всего лишь зелёный свет.

Что видят участники

Как только ты действуешь с запросом, участник видит обновление в #Мои запросы (его личный трекер):

• Approved → полоса прогресса переходит к шагу 2 из 5.
• Rejected → строка краснеет с твоей причиной.
• Archived → строка исчезает из его вида Pending.

Полоса прогресса продолжает двигаться по мере выполнения задачи выдачи / Payout. Полные детали стороны участника — в Участники — подача ригир.

Связанные страницы

• Обзор процесса ригир — режимы + развилка
• Участники — подача ригир — upstream-поток подачи
• Item-режим — выдача + шкафчик — что происходит после Approve в item-режиме
• Silver-режим — выплата из Банк silver — что происходит после Approve в silver-режиме
• Настройки — Regear Policy — политика валидации + выбор режима
• ригир участника — per-member audit-вид