Staff — przegląd + zatwierdź / odrzuć wnioski regear

Członkowie zgłaszają regear na #Request Regear; wszystko, co zgłaszają, ląduje tutaj, w #Review Requests, do triażu przez staff. Ta strona omawia kolejkę przeglądu od początku do końca.

Uprawnienia

Potrzebujesz uprawnienia Approve Regear Requests (w sekcji Regear w Edit Role → Permissions), żeby widzieć ten kanał i działać na wnioskach. Większość gildii daje to szablonom ról Regear Staff / Regear Manager / Manager. Zobacz Referencję uprawnień dla pełnej tabeli.

Kolejka przeglądu

Otwórz #Review Requests z sekcji REGEAR TEAM paska bocznego.

Górna część strony:

• Zakładki — Pending / Approved / Rejected. Pending to kolejka pracy; pozostałe dwie to widoki audytu.
• Toolbar (per zakładka Pending):
  • Checkbox Select all — dla bulk multi-select.
  • Filtr Type — All / Deaths / Overcharge.
  • Filtr War Role — zawęż do wniosków konkretnej war role (przydatne, gdy jedna rola dominuje w CTA).
  • Search — akceptuje imię ofiary LUB #event_id (9-cyfrowy event ID Albion poprzedzony #, np. #475568182). Event ID to ten sam numer, którego feed śmierci Albion i URL-e eventów używają, więc gdy członek pisze do ciebie na Discordzie z linkiem do zabójstwa pytając "czy ten przeszedł?" — skopiuj końcowy numer, poprzedź #, wklej, a kolejka filtruje się do tylko tego wiersza. Ten sam search #event_id działa w #Zadania rozliczeniowe, więc możesz śledzić jedną śmierć od kolejki przeglądu aż do strony packera.

Każda karta w kolejce to jeden wniosek:

• Górny wiersz — imię członka + postać + odznaka war role (Outcomers / FreezDawnera / Riderr na zrzucie).
• Środek — link do eventu śmierci (eventID) + siatka wyposażenia 3×4 pokazująca utracone itemy z odznakami walidacji per-slot:
  • 🟢 OK — slot pasuje do loadout roli w oczekiwanym tier.
  • 🟡 Under-tier — item jest niższego tier niż wymaga rola.
  • 🔵 Over-tier — item jest wyższego tier.
  • 🔴 Invalid — item w ogóle nie jest w loadout roli.
• Dolny wiersz — przyciski akcji + metadane (znacznik czasu śmierci UTC + fame).

Trzy akcje per wniosek

✅ Approve

Zatwierdza wniosek. Co dzieje się dalej, zależy od trybu regear gildii:

• Tryb item — wniosek przechodzi w stan approved; zielony przycisk ma etykietę Create Cut-off Task (single + bulk). Kliknij, żeby zebrać wniosek w zadanie pakowania w #Cut-off Tasks. Zobacz Tryb item — cut-off + locker.
• Tryb silver — wniosek przechodzi w stan approved; zielony przycisk ma etykietę Payout (single + bulk). Kliknij, żeby kredytować silver na portfel Bank silver członka. Zobacz Tryb silver — wypłata z Bank silver.

Ta sama akcja Approve, inny drugi przycisk w zależności od konfiguracji gildii. Celowo jest przerwa między approve a faktycznym ruchem pieniędzy/itemów — zobacz Dwukrokowy cykl życia poniżej.

❌ Reject

Odrzuca wniosek od razu. Otwiera się prompt powodu — wpisz powód (np. "Zła war role — nie przypisana do tego CTA"), potwierdź. Członek widzi odrzucenie + powód na #My Requests.

Po odrzuceniu wniosek jest terminalny — nie wraca do kolejki. Jeśli członek się sprzeciwia, może złożyć nowy wniosek z poprawionymi danymi.

📁 Archive

Usuwa wniosek z kolejki Pending bez zatwierdzenia ani odrzucenia — przenosi do widoku Archived. Użyj, gdy członek zgłasza duplikat, stary wniosek już nie jest do działania albo cokolwiek, co chcesz ukryć bez zobowiązania się do decyzji.

Bramkowanie polityką walidacji

To, co walidator robi z problemami under-tier / over-tier / invalid, jest decydowane przez Regear Policy gildii (Ustawienia → Regear Policy). Trzy sloty polityki, każdy niezależnie ustawiony na jeden z:

• Auto-reject — wniosek jest odrzucany przy zgłoszeniu; nigdy nie dociera do tej kolejki.
• Allow — wniosek przepływa do staffu z odnotowanym problemem, ale przycisk Submit nigdy nie blokuje członka.
• Staff decision (domyślnie) — wniosek dociera do kolejki; staff widzi problem + decyduje per wniosek.

Jeśli twoja gildia używa "Staff decision" dla invalid slotów, spodziewaj się widzieć wnioski z odznakami 🔴, które wciąż są twoim wyborem. Info per-slot pomaga ci zdecydować między Approve (wybacz), Reject (odmów) lub Approve-z-nadpisaniem (np. wybór innej war role przy zatwierdzeniu, która pasuje do gearu).

Nadpisanie war role przy zatwierdzeniu

Kliknij odznakę war role na górze karty wniosku, żeby zmienić war role dla tego konkretnego wniosku. Powoduje to ponowną walidację względem loadout nowej roli — przydatne, gdy:

• Członek źle kliknął war role przy zgłoszeniu.
• Stracony gear faktycznie mapuje się do loadout innej roli (np. Holy Healer grał Lifecurse).
• Chcesz zastosować inny silver cap (w trybie War Role — Capped by actual cap z wybranej roli jest tym, co stosuje się przy Payout).

Nadpisanie jest zapisane w dzienniku audytu dla transparentności.

Akcje bulk multi-select

Zaznacz checkbox Select all (lub checkboxy per-karta) → toolbar pokazuje bulk przyciski Approve / Reject / Archive.

• Bulk Approve — zatwierdza N wniosków w jednym wywołaniu. Każdy wniosek wciąż idzie przez logikę per-tryb — tryb item tworzy jedno zadanie cut-off per wniosek (bez bundlingu); tryb silver kredytuje N wypłat jedna po drugiej, ale jako pojedyncza akcja batch.
• Bulk Reject — otwiera prompt powodu; ten sam powód stosowany do wszystkich zaznaczonych. Użyj dla jasnych naruszeń ("Wszystkie te oblały sprawdzenie war role").
• Bulk Archive — przenosi wszystkie zaznaczone z pending. Bez promptu.

Dwukrokowy cykl życia

Dlaczego approve i deliver to oddzielne kliknięcia:

• Silver to prawdziwa waluta. Approve = "tak, to ważne roszczenie." Payout = "tak, rusz silver." Stripe / payroll / PayPal wszystkie to oddzielają.
• Okno wycofania. Jeśli zauważysz błąd między approve a pay, odrzuć wiersz, zanim pieniądze się ruszą. Bez kompensacyjnych wpisów księgowych.
• Batching na wypłatę. Staff może zebrać tydzień zatwierdzonych i wypłacić wszystkie w jeden Payday — jeden wpis Audit log, jedno powiadomienie Discord.
• Mode-agnostic pending. Oczekujące wnioski nie obchodzi, w jakim trybie gildia jest. Jeśli twoja gildia przełącza tryby (item → silver), oczekujące wnioski nie potrzebują migracji — zatwierdzają się do nowego trybu po approve.

Dla trybu item krok bundlingu jest jeszcze bardziej widoczny: approve → wniosek czeka → bundle do zadania cut-off → packer robi robotę. Zadanie cut-off jest faktycznym przekazaniem — approve to tylko zielone światło.

Co widzą członkowie

Po twojej akcji na wniosku członek widzi aktualizację na #My Requests (jego osobistym trackerze):

• Approved → pasek postępu przesuwa się do kroku 2 z 5.
• Rejected → wiersz robi się czerwony z twoim powodem.
• Archived → wiersz znika z jego widoku Pending.

Pasek postępu kontynuuje, gdy zadanie cut-off / Payout idzie dalej. Pełne szczegóły strony członka w Członkowie — zgłoś regear.

Powiązane strony

• Przegląd procesu regear — wyjaśnione tryby + rozgałęzienie
• Członkowie — zgłoś regear — wyższy przepływ zgłaszania
• Tryb item — cut-off + locker — co dzieje się po Approve w trybie item
• Tryb silver — wypłata z Bank silver — co dzieje się po Approve w trybie silver
• Ustawienia — Regear Policy — polityka walidacji + wybór trybu
• Raport regear członka — widok audytu per-członek