Skip to content

Staff — tinjau + setujui / tolak permintaan regear

Anggota mengirim regear di #Request Regear; semua yang mereka kirim mendarat di sini, di #Review Requests, untuk staff lakukan triase. Halaman ini berjalan melalui antrean tinjauan dari ujung ke ujung.

Permission

Kamu butuh permission Approve Regear Requests (di bawah bagian Regear dari Edit Role → Permissions) untuk melihat channel ini dan bertindak atas permintaan. Sebagian besar guild memberikan ini ke preset role Regear Staff / Regear Manager / Manager. Lihat Referensi permission untuk tabel lengkap.

Antrean tinjauan

Buka #Review Requests dari bagian REGEAR TEAM di sidebar.

Antrean Review Requests menunjukkan 3 permintaan pending dengan grid perlengkapan penuh, badge war role, dan tombol Approve

Bagian atas halaman:

  • TabPending / Approved / Rejected. Pending adalah antrean kerja; dua lainnya adalah tampilan audit.
  • Toolbar (per tab Pending):
    • Kotak centang Select all — untuk aksi massal multi-pilih.
    • Filter TypeAll / Deaths / Overcharge.
    • Filter War Role — sempit ke permintaan war role tertentu (berguna saat satu role dominan di CTA).
    • Search — menerima nama korban ATAU #event_id (event ID Albion 9 digit dengan awalan #, mis. #475568182). Event ID adalah angka yang sama yang dipakai feed kematian Albion dan URL link event, sehingga saat anggota menghubungimu di Discord dengan link kill sambil bertanya "apakah yang ini sudah masuk?" — salin angka di akhir, tambahkan awalan #, tempel, dan antrean akan memfilter ke baris tersebut saja. Pencarian #event_id yang sama juga berfungsi di #Cut-off Tasks sehingga kamu bisa menelusuri satu kematian dari antrean tinjauan sampai ke sisi packer.

Setiap kartu di antrean adalah satu permintaan:

  • Baris atas — nama anggota + karakter + badge war role (Outcomers / FreezDawnera / Riderr di tangkapan layar).
  • Tengah — link event death (eventID) + grid perlengkapan 3×4 yang menampilkan item yang hilang dengan badge validasi per slot:
    • 🟢 OK — slot sesuai loadout role di tier yang diharapkan.
    • 🟡 Under-tier — item adalah tier lebih rendah dari yang dipanggil role.
    • 🔵 Over-tier — item adalah tier lebih tinggi.
    • 🔴 Invalid — item tidak ada di loadout role sama sekali.
  • Baris bawah — tombol Aksi + metadata (timestamp kematian UTC + fame).

Tiga aksi per permintaan

✅ Approve

Menyetujui permintaan. Apa yang terjadi selanjutnya tergantung mode regear guild:

  • Mode item — permintaan berpindah ke status approved; tombol hijau berlabel Create Cut-off Task (tunggal + massal). Klik untuk menggabungkan permintaan ke tugas pengemasan di #Cut-off Tasks. Lihat Mode item — cut-off + locker.
  • Mode silver — permintaan berpindah ke status approved; tombol hijau berlabel Payout (tunggal + massal). Klik untuk mengkredit silver ke dompet Bank Silver anggota. Lihat Mode silver — pembayaran dari Bank Silver.

Aksi Approve yang sama, tombol langkah kedua berbeda berdasarkan konfigurasi guild. Ada jeda yang disengaja antara approve dan perpindahan uang/item yang sebenarnya — lihat Siklus hidup dua langkah di bawah.

❌ Reject

Menolak permintaan langsung. Prompt alasan muncul — ketik alasan (mis. "War role salah — tidak ditugaskan untuk CTA ini"), konfirmasi. Anggota melihat penolakan + alasan di #My Requests.

Setelah ditolak, permintaan menjadi terminal — tidak kembali ke antrean. Jika anggota keberatan, mereka bisa mengirim permintaan baru dengan info yang dikoreksi.

📁 Archive

Menghapus permintaan dari antrean Pending tanpa menyetujui atau menolak — memindahkannya ke tampilan Archived. Gunakan saat anggota mengirim duplikat, permintaan lama yang tidak lagi dapat ditindaklanjuti, atau apa pun yang ingin kamu sembunyikan tanpa berkomitmen pada keputusan.

Pemerolehan kebijakan validasi

Apa yang dilakukan validator dengan masalah under-tier / over-tier / invalid diputuskan oleh Regear Policy guild (Settings → Regear Policy). Tiga slot kebijakan, masing-masing diatur independen ke salah satu dari:

  • Auto-reject — permintaan ditolak saat pengiriman; tidak pernah mencapai antrean ini.
  • Allow — permintaan mengalir ke staff dengan masalah dicatat tapi tombol Submit tidak pernah memblokir anggota.
  • Staff decision (default) — permintaan mencapai antrean; staff melihat masalah + memutuskan per permintaan.

Jika guild-mu menggunakan "Staff decision" untuk slot invalid, harapkan melihat permintaan dengan badge 🔴 yang masih menjadi keputusanmu. Info per slot membantumu memutuskan antara Approve (memaafkan), Reject (menolak), atau Approve-with-override (mis. memilih war role berbeda saat persetujuan yang cocok dengan gear).

Penggantian war role saat persetujuan

Klik pada badge war role di bagian atas kartu permintaan untuk mengubah war role untuk permintaan tertentu ini. Ini menjalankan ulang validasi terhadap loadout role baru — berguna saat:

  • Anggota salah klik war role saat pengiriman.
  • Gear yang hilang sebenarnya cocok dengan loadout role lain (mis. Holy Healer menjalankan Lifecurse).
  • Kamu ingin menerapkan silver cap berbeda (di mode War Role — Capped by actual, cap dari role yang dipilih adalah yang berlaku saat Payout).

Penggantian dicatat di log audit untuk transparansi.

Aksi massal multi-pilih

Centang kotak Select all (atau kotak per kartu) → toolbar menampilkan tombol massal Approve / Reject / Archive.

  • Bulk Approve — menyetujui N permintaan dalam satu panggilan. Setiap permintaan tetap melalui logika per mode — mode item membuat satu cut-off task per permintaan (tanpa penggabungan); mode silver mengkredit N pembayaran berturut-turut tapi sebagai satu aksi batch.
  • Bulk Reject — membuka prompt alasan; alasan yang sama diterapkan ke semua yang dipilih. Gunakan untuk pelanggaran yang jelas ("Semua ini gagal pemeriksaan war role").
  • Bulk Archive — memindahkan semua yang dipilih keluar dari pending. Tanpa prompt.

Siklus hidup dua langkah

Mengapa approve dan deliver adalah klik terpisah:

  • Silver adalah mata uang nyata. Approve = "ya, ini klaim yang valid." Payout = "ya, pindahkan silver." Stripe / payroll / PayPal semua memisahkan ini.
  • Jendela pembalikan. Jika kamu menemukan kesalahan antara approve dan pay, tolak baris sebelum uang berpindah. Tidak perlu entri ledger kompensasi.
  • Batching untuk payday. Staff bisa mengumpulkan seminggu persetujuan dan membayar semuanya pada satu Payday — satu entri Audit log, satu notifikasi Discord.
  • Pending tidak terikat mode. Permintaan pending tidak peduli mode mana yang dipakai guild. Jika guild-mu berganti mode (item → silver), permintaan pending tidak perlu migrasi — mereka berkomitmen ke mode baru saat disetujui.

Untuk mode item langkah penggabungan bahkan lebih terlihat: approve → permintaan menunggu → gabungkan ke cut-off task → packer melakukan pekerjaan. Cut-off task adalah serah terima sebenarnya — persetujuan hanya lampu hijau.

Apa yang dilihat anggota

Setelah kamu bertindak atas permintaan, anggota melihatnya diperbarui di #My Requests (pelacak personal mereka):

  • Approved → strip progres maju ke langkah 2 dari 5.
  • Rejected → baris menjadi merah dengan alasanmu.
  • Archived → baris hilang dari tampilan Pending mereka.

Strip progres kemudian berlanjut saat alur cut-off task / Payout maju. Detail sisi anggota lengkap di Anggota — kirim regear.