Approvals

Route: /approve · Menu: Approve · Page permission: tokenRequest:R

The approval page is review-only. It lists pending requests raised elsewhere in the system — most often a device asking to register — and gives you exactly two decisions: Approve and Reject. There is no create, no edit, no delete and no separate detail page.

What you can do here

• As a reviewer, I want to see every pending request in the tenant, so that nothing waits unnoticed.
• As a reviewer, I want to read the full contents of a request, so that I can judge it on evidence rather than a label.
• As a reviewer, I want to approve or reject a request, so that the requester can proceed or be stopped.
• As a reviewer, I want to decide many requests at once, so that a batch of joiners does not take an afternoon.
• As a reviewer with read-only access, I want to see the queue without being able to change it, so that I can monitor without authority.

1. The approval list

1.1 Columns

Turn the hidden columns on, or reorder any column, from the gear in the operation column header. The setting is stored per browser.

1.2 Statuses

1.3 Filtering and sorting

Clicking a sortable header cycles ascending → descending → default (created time, newest first). Applying a filter resets to page 1, and filters are written into the URL so a view can be shared.

1.4 Paging

10 / 20 / 50 / 100 per page. The footer reads 共 {total} 筆 — approvals have no quota, so no limit is shown.

1.5 Row shortcuts

Single-clicking a row body toggles selection once at least one checkbox is ticked. There is no double-click shortcut here because approvals have no detail page.

2. Approving or rejecting one request

Permission: tokenRequest:U

1. Find the pending row.
2. Select Approve or Reject.
3. Confirm in the dialog. The list refreshes.

The buttons appear only on PENDING rows. If you hold tokenRequest:R but not tokenRequest:U, you see the whole queue and no decision buttons at all — the operation column renders empty.

3. Reading a request

Select the view button in the Resource column. The dialog lays the content out according to its structure — labelled fields, nested sections indented — rather than dumping raw JSON.

Four shapes turn up in practice:

Presentation details worth knowing:

• Field order follows the payload; nothing is re-ordered.
• Timestamps are rendered in your timezone preference.
• Empty values, nulls and empty collections all show as -.
• Serial number and fingerprint carry a copy button that copies the raw value. Paste it back into the list’s keyword search to find every historic request from the same machine.

3.1 How to read a device-registration payload

Every field in the payload is asserted by the client and can be forged. It is not proof of anything. Its value is that it can be reconciled against a source the client cannot tamper with — your asset inventory, directory, or MDM. Merak therefore presents it neutrally: there is no “verified” badge, no green tick, no shield icon, because none of it is verified.

One pairing matters especially: fingerprint is always displayed together with fingerprint source. A fingerprint derived from a hardware identifier is worlds apart in strength from one derived from a MAC address list — the latter means only “the same set of network cards”. Showing the hash alone would invite you to read a weak match as a strong one.

3.2 Oversized or malformed payloads

• Structures nested more than 8 levels deep are truncated at that branch.
• Payloads over 20,000 characters are not parsed at all; the dialog says so and does not dump the raw JSON.
• If rendering fails, only the dialog’s contents break — the list itself stays usable, and the next row you open starts clean.

4. Deciding many requests at once

Permission: tokenRequest:U

1. Tick the checkbox on each row you want (the header checkbox selects the whole page; it shows a partial state when only some rows are ticked).
2. The toolbar swaps to Clear all and Review selection (N).
3. Open Review selection. The dialog lists what you picked and lets you remove rows one by one; emptying it closes the dialog.
4. Select Approve or Reject.

Rules:

• Every selected row must be PENDING for the button to be enabled. If only some qualify, the button reads M/N eligible and offers Keep only eligible to trim the selection in one click.
• Requests are decided one by one. A single failure does not abort the rest.
• All succeeded → a success toast, the dialog closes, the selection clears.
• Some failed → the dialog stays open listing successes and failures with reasons, automatically dropping the successful ones so you can retry only what failed.

Your selection survives paging and re-sorting within the same search. It is cleared when you run a new search, when a single-row decision succeeds (so a stale pending snapshot cannot be re-used), and after a batch action completes.

Approvals have no export. There is no export button in the toolbar and no “export selection” in the review dialog.

5. Permission summary

Next

• Trace what happened after a decision: 07 · Logs
• Manage the devices a decision admitted: 02 · Members §7