Features · Administration

Administration that scales

Roles, guards, audit log and rate limiting — control without ceremony.

Administration in this tracker is deliberately small and sharp. Roles work on two levels — global and per project — every sensitive change lands in an audit log, and rate limiting is on from the first request. Setup is zero-ceremony: the first account registered becomes the admin.

3 global roles · 3 project rolesFirst registered user becomes admin10 login attempts/min per IP (default)37 audit categories · 11 actions

What you get

  • Two-level roles — Global roles (admin, member, guest) govern the instance; project roles (admin, member, viewer) govern each project — viewers read, members write, project admins configure.
  • User management — Search users by name or email, rename them, change their role, and deactivate or reactivate accounts from a single admin screen.
  • Last-admin guard — You cannot demote or deactivate the last active admin, and you cannot remove the last project admin — the API refuses with a conflict, so your team is never locked out.
  • Audit log — Registrations, logins, SSO links, 2FA changes and admin user edits are recorded with actor, action, entity and timestamp, and are browsable from the admin screen.
  • Configuration audit trail — Every project-configuration change — workflows, automation rules, SLA policies, integrations and more — is recorded with who, when and what, filterable by project, category, action, actor and date range.
  • Built-in rate limiting — Bucket4j caps login attempts per IP, throttles public portal and webhook endpoints per IP, and caps the general API per user, answering excess traffic with HTTP 429 — every limit configurable.

Access checks that fail closed

Every project-scoped operation funnels through one central access gate with three checks: member (read), write member (viewers excluded), and project admin (configuration). The tenant check runs before the role check, so a user from another organisation is denied even if a stale membership row exists. A global admin passes all three; everyone else needs an explicit project membership.

A config change trail, not just a login log

The audit log does double duty. Alongside security events (registrations, logins, role changes), a shared config-audit service records every change to project configuration across 37 element categories — ticket types, workflow statuses, automation rules, SLA policies, integrations and more — with 11 action types from CREATE to MEMBER_REMOVED. Admins query it through a dedicated filterable endpoint, newest first.

Abuse resistance from the first request

Rate limiting is defence-in-depth with distinct budgets: by default 10 requests per minute per IP on the auth endpoints (brute-force protection), 60 on the public portal, 120 on inbound webhooks, and 240 per user on the general API. The X-Forwarded-For header is ignored unless you explicitly mark your reverse proxy as trusted — a spoofed header cannot mint fresh buckets. Limits are tuned via app.ratelimit.* properties.

In practice

GET /api/v1/admin/config-audit?projectKey=CORE&category=WORKFLOW_STATUS&action=UPDATE&from=2026-07-01T00:00:00Z

See Iskue on your own screen

A demo takes half an hour. A pilot runs on your servers, with your data, from day one.