Request feature

[remdui]

Is your feature request related to a problem? Please describe.
We missen een generiek in-game request-systeem waarmee spelers aanvragen kunnen indienen en staff die kan beoordelen/verwerken. Er is behoefte aan:

• Config-gedefinieerde requesttypes met eigen velden.
• Staff-workflow (inzien, beoordelen, afhandelen).
• Permanent archief per speler van verwerkte aanvragen.
  Concreet use-case: structures aanvragen (bijv. max. 2 Ocean Monuments per speler), handmatig goedkeuren/toewijzen door staff en blijvend zichtbaar voor alle staff.

Describe the solution you'd like

• Config-gedreven types & velden

  • In config.yml per type: sleutel, naam, beschrijving, velden (tekst, keuze, locatie/coords, getal), validatie, optionele quota (limiet per speler), en cooldown.
  • Voorbeeldtype “structures”: limiet (bijv. 2), keuzelijst van toegestane structures, optioneel wereld/coords.

• Commands & GUI

  • Speler:

    • /request new <type> → GUI/formulier voor invullen velden
    • /request my → openstaande/eerdere aanvragen
    • /request history → volledig persoonlijk archief (read-only)

  • Staff:

    • /request staff list [status|type|player]
    • /request staff view <id> (alle gegevens + audittrail)
    • /request staff approve <id> [opmerking]
    • /request staff deny <id> [reden]
    • /request staff fulfill <id> [gegevens] (eindstap; bij structures: toegewezen structure + locatie)
    • /request staff quota <player> <type> set|add <n>

  • Duidelijke status-updates (chat/actionbar) en een overzichtelijke staff-GUI (tabs per status: OPEN / IN_REVIEW / APPROVED / DENIED / FULFILLED).

• Workflow & statussen

  • OPEN → IN_REVIEW → APPROVED/DENIED → (optioneel) FULFILLED.
  • Auditlog met wie/wat/wanneer en notities.
  • Quota-handhaving per type bij indienen en bij FULFILLED (bijv. structures telt pas bij fulfillment mee).

• Persistent archief

  • Altijd alle requests bewaren (soft-delete nooit zichtbaar voor spelers, maar audit blijft).
  • Per speler een tijdlijn + filters (type/status).

• Permissions (indicatief)

  • Spelers: request.use
  • Staff: request.staff.view, request.staff.process, request.staff.fulfill, request.staff.quota, request.admin

• Notificaties (optioneel)

  • Bij nieuwe OPEN request: ping naar staff-kanaal; bij statuswijziging: melding aan speler.

Additional context

• Config-schets

  requests:
    types:
      structures:
        name: "Structures aanvragen"
        description: "Vraag een structure aan tot je limiet."
        quota:
          per_player: 2          # hard limiet, telt bij FULFILLED
        fields:
          - key: "structure"
            label: "Welke structure?"
            type: "select"
            options: ["ocean_monument", "woodland_mansion", "ancient_city"]
            required: true
          - key: "world"
            label: "Wereld"
            type: "select"
            options: ["world", "world_nether", "world_the_end"]
            required: true
          - key: "coords"
            label: "Coördinaten"
            type: "location"     # GUI laat huidige positie kiezen of handmatig invullen
            required: false
        cooldown_seconds: 0
      custom_form:
        name: "Algemene aanvraag"
        description: "Vrij formulier met eigen velden."
        fields:
          - key: "omschrijving"
            type: "text"
            max_length: 500
            required: true

• DB-schema (compact, uitbreidbaar)

  CREATE TABLE request_type (
    key VARCHAR(64) PRIMARY KEY,
    name VARCHAR(128) NOT NULL
  );
  
  CREATE TABLE request (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    player_uuid BINARY(16) NOT NULL,
    type_key VARCHAR(64) NOT NULL,
    status VARCHAR(16) NOT NULL,           -- OPEN, IN_REVIEW, APPROVED, DENIED, FULFILLED
    created_at DATETIME(3) NOT NULL,
    updated_at DATETIME(3) NOT NULL,
    FOREIGN KEY (type_key) REFERENCES request_type(key)
  );
  
  CREATE TABLE request_field_value (
    request_id BIGINT NOT NULL,
    field_key VARCHAR(64) NOT NULL,
    value TEXT NOT NULL,
    PRIMARY KEY (request_id, field_key),
    FOREIGN KEY (request_id) REFERENCES request(id)
  );
  
  CREATE TABLE request_history (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    request_id BIGINT NOT NULL,
    actor_uuid BINARY(16) NULL,            -- NULL = systeem
    from_status VARCHAR(16) NULL,
    to_status VARCHAR(16) NOT NULL,
    note TEXT NULL,
    created_at DATETIME(3) NOT NULL,
    FOREIGN KEY (request_id) REFERENCES request(id)
  );
  
  -- Optioneel: quota cache per speler × type (voor snelle checks)
  CREATE TABLE request_quota (
    player_uuid BINARY(16) NOT NULL,
    type_key VARCHAR(64) NOT NULL,
    fulfilled_count INT NOT NULL DEFAULT 0,
    PRIMARY KEY (player_uuid, type_key),
    FOREIGN KEY (type_key) REFERENCES request_type(key)
  );

• Structures use-case

  • Speler dient “structures” in; staff keurt goed en zet daarna op FULFILLED met ingevulde gegevens (bijv. structure id/coords).
  • request_quota.fulfilled_count ++ → zichtbaar in staff-GUI per speler (“heeft 2/2 structures gekregen”).
  • Andere staff ziet in één oogopslag welke structures en wanneer aan een speler zijn toegewezen.

• Acceptatiecriteria

  1. Admin kan via config nieuwe requesttypes en velden definiëren zonder codewijziging.
  2. Speler kan een request indienen via GUI/command; staff kan inzien, beoordelen en afhandelen.
  3. Permanent archief per speler met volledige audittrail en filtermogelijkheden.
  4. Quota voor “structures” werkt: max. toekenningen per speler bewaakt op FULFILLED.
  5. Geen console-errors; duidelijke meldingen voor spelers en staff; performance OK bij grote archieven.