Staff — regear-Anfragen prüfen + genehmigen / ablehnen

Mitglieder reichen regears in #Request Regear ein; alles, was sie einreichen, landet hier in #Review Requests, damit der Staff triagiert. Diese Seite führt durch die Prüf-Warteschlange durchgehend.

Berechtigungen

Du brauchst die Berechtigung Approve Regear Requests (unter der Sektion Regear unter Edit Role → Permissions), um diesen Kanal zu sehen und mit Anfragen zu agieren. Die meisten Gilden vergeben dies an die Rollenpresets Regear Staff / Regear Manager / Manager. Siehe Permissions-Referenz für die vollständige Tabelle.

Die Prüf-Warteschlange

Öffne #Review Requests in der Sidebar unter der Sektion REGEAR TEAM.

Oben auf der Seite:

• Tabs — Pending / Approved / Rejected. Pending ist die Arbeitswarteschlange; die anderen beiden sind Audit-Ansichten.
• Symbolleiste (pro Pending-Tab):
  • Select all-Kontrollkästchen — für Bulk-Aktionen mit Mehrfachauswahl.
  • Type-Filter — All / Deaths / Overcharge.
  • War Role-Filter — auf Anfragen einer bestimmten war role eingrenzen (nützlich, wenn eine Rolle in einer CTA dominant ist).
  • Search — akzeptiert einen Opfer-Namen ODER eine #event_id (die 9-stellige Albion-Event-ID mit #-Prefix, z. B. #475568182). Die Event-ID ist dieselbe Zahl, die Albions Death-Feed und Event-Link-URLs verwenden — wenn ein Mitglied dir in Discord einen Kill-Link schickt mit der Frage „Ist das durchgekommen?" — kopiere die Nummer am Ende, füge # voran, füge sie ein, und die Warteschlange filtert auf genau diese Zeile. Dieselbe #event_id-Suche funktioniert auch unter #Cut-off Tasks, sodass du einen Tod von der Prüfwarteschlange bis zur Packer-Seite verfolgen kannst.

Jede Karte in der Warteschlange ist eine Anfrage:

• Obere Zeile — Mitgliedsname + Charakter + war-role-Badge (Outcomers / FreezDawnera / Riderr im Screenshot).
• Mitte — der Tod-Event-Link (eventID) + ein 3×4-Ausrüstungsraster, das die verlorenen Items mit slotweisen Validierungs-Badges zeigt:
  • 🟢 OK — Slot passt zum loadout der Rolle im erwarteten Tier.
  • 🟡 Under-tier — Item ist in einem niedrigeren Tier als von der Rolle gefordert.
  • 🔵 Over-tier — Item ist in einem höheren Tier.
  • 🔴 Invalid — Item gehört überhaupt nicht zum loadout der Rolle.
• Untere Zeile — Aktionsschaltflächen + Metadaten (UTC-Tod-Zeitstempel + Fame).

Die drei Aktionen pro Anfrage

✅ Approve

Genehmigt die Anfrage. Was als Nächstes passiert, hängt vom regear-Modus der Gilde ab:

• Item-Modus — Anfrage geht in den Zustand approved; die grüne Schaltfläche heißt Create Cut-off Task (einzeln + bulk). Klicke darauf, um die Anfrage in einen Pack-Task in #Cut-off Tasks zu bündeln. Siehe Item-Modus — Cut-off + locker.
• Silver-Modus — Anfrage geht in den Zustand approved; die grüne Schaltfläche heißt Payout (einzeln + bulk). Klicke, um silver der Silver-Bank-Wallet des Mitglieds gutzuschreiben. Siehe Silver-Modus — Auszahlung aus der Silver Bank.

Dieselbe Approve-Aktion, andere Zweitschritt-Schaltfläche je nach Gildenkonfiguration. Zwischen Approve und dem tatsächlichen Geld-/Item-Fluss gibt es bewusst eine Lücke — siehe Zwei-Schritte-Lebenszyklus unten.

❌ Reject

Lehnt die Anfrage komplett ab. Eine Begründungs-Eingabeaufforderung öffnet sich — tippe die Begründung (z. B. „Wrong war role — not assigned for this CTA"), bestätige. Das Mitglied sieht die Ablehnung + Begründung in #My Requests.

Einmal abgelehnt ist die Anfrage terminal — sie kommt nicht zurück in die Warteschlange. Wenn das Mitglied widerspricht, kann es eine neue Anfrage mit korrigierten Informationen einreichen.

📁 Archive

Entfernt die Anfrage aus der Pending-Warteschlange, ohne sie zu genehmigen oder abzulehnen — verschiebt sie in die Ansicht Archived. Verwende es, wenn ein Mitglied eine Dublette einreicht, bei einer alten Anfrage, die nicht mehr handlungsfähig ist, oder bei allem, was du ausblenden willst, ohne dich auf eine Entscheidung festzulegen.

Validierungsrichtlinien-Gate

Was der Validator mit under-tier / over-tier / invalid-Problemen macht, entscheidet die Regear Policy der Gilde (Settings → Regear Policy). Drei Richtlinien-Slots, jeder unabhängig auf einen der folgenden Werte gesetzt:

• Auto-reject — Anfrage wird beim Absenden abgelehnt; erreicht diese Warteschlange nie.
• Allow — Anfrage geht zum Staff durch, mit Problemvermerk, aber die Submit-Schaltfläche blockiert das Mitglied nie.
• Staff decision (Standard) — Anfrage erreicht die Warteschlange; der Staff sieht das Problem + entscheidet pro Anfrage.

Wenn deine Gilde „Staff decision" für ungültige Slots verwendet, rechne mit Anfragen mit 🔴-Badges, die trotzdem deine Entscheidung sind. Die slotweisen Infos helfen dir, zwischen Approve (verzeihen), Reject (verweigern) oder Approve-mit-Override (z. B. eine andere war role beim Genehmigen wählen, die zur Ausrüstung passt) zu wählen.

War-role-Override beim Genehmigen

Klicke oben auf der Anfragekarte auf das war-role-Badge, um die war role für diese bestimmte Anfrage zu ändern. Das führt die Validierung gegen das loadout der neuen Rolle erneut aus — nützlich, wenn:

• Das Mitglied beim Einreichen die falsche war role geklickt hat.
• Die verlorene Ausrüstung tatsächlich zu einem anderen Rollen-loadout passt (z. B. ein Holy Healer hat Lifecurse gespielt).
• Du eine andere silver-Obergrenze anwenden willst (im Modus War Role — Capped by actual gilt beim Payout die Obergrenze der gewählten Rolle).

Das Override wird zur Nachvollziehbarkeit im Audit-Log festgehalten.

Mehrfachauswahl-Bulk-Aktionen

Hake das Kontrollkästchen Select all an (oder die Kontrollkästchen pro Karte) → die Symbolleiste zeigt Bulk-Schaltflächen für Approve / Reject / Archive.

• Bulk Approve — genehmigt N Anfragen in einem Aufruf. Jede Anfrage durchläuft weiterhin die modusspezifische Logik — Item-Modus erstellt einen Cut-off Task pro Anfrage (keine Bündelung); Silver-Modus schreibt N Auszahlungen nacheinander gut, aber als einzelne Bulk-Aktion.
• Bulk Reject — öffnet eine Begründungs-Eingabe; dieselbe Begründung gilt für alle ausgewählten Anfragen. Verwende es für klare Verstöße („Diese sind alle bei der war-role-Prüfung durchgefallen").
• Bulk Archive — verschiebt alle ausgewählten aus pending. Keine Eingabeaufforderung.

Zwei-Schritte-Lebenszyklus

Warum Genehmigen und Ausliefern getrennte Klicks sind:

• Silver ist echte Währung. Approve = „ja, das ist ein gültiger Anspruch." Payout = „ja, silver bewegen." Stripe / Payroll / PayPal trennen das alle.
• Korrekturfenster. Wenn du zwischen Approve und Pay einen Fehler bemerkst, lehne die Zeile ab, bevor Geld fließt. Keine ausgleichenden Buchungen nötig.
• Bündeln für den Zahltag. Der Staff kann eine Woche lang Approveds ansammeln und sie alle an einem einzigen Payday bezahlen — ein Audit-Log-Eintrag, eine Discord-Benachrichtigung.
• Modusagnostisches Pending. Pending-Anfragen kümmern sich nicht darum, in welchem Modus die Gilde ist. Wenn deine Gilde den Modus wechselt (item → silver), brauchen pending-Anfragen keine Migration — sie verpflichten sich beim Genehmigen auf den neuen Modus.

Für den Item-Modus ist der Bündelungsschritt noch sichtbarer: approve → Anfrage wartet → in einen Cut-off Task bündeln → Packer erledigt die Arbeit. Der Cut-off Task ist die eigentliche Übergabe — Approve ist nur das grüne Licht.

Was die Mitglieder sehen

Sobald du auf eine Anfrage reagierst, sieht das Mitglied die Aktualisierung in #My Requests (sein persönlicher Tracker):

• Approved → Fortschrittsleiste rückt auf Schritt 2 von 5 vor.
• Rejected → Zeile wird rot mit deiner Begründung.
• Archived → Zeile verschwindet aus seiner Pending-Ansicht.

Die Fortschrittsleiste setzt dann fort, während der Cut-off-Task / Payout-Flow voranschreitet. Volldetail auf Mitgliederseite unter Mitglieder — einen regear einreichen.

Verwandte Seiten

• Übersicht der regear-Pipeline — Modi + Aufteilung erklärt
• Mitglieder — einen regear einreichen — der vorgelagerte Einreich-Flow
• Item-Modus — Cut-off + locker — was nach Approve im Item-Modus passiert
• Silver-Modus — Auszahlung aus der Silver Bank — was nach Approve im Silver-Modus passiert
• Settings — Regear Policy — Validierungsrichtlinie + Modusauswahl
• Member Regear Report — die per-Mitglied-Audit-Ansicht