Statuses & roles¶

Danbyte ships no statuses or roles - following the zero pre-filled data rule, you define exactly the ones your network uses. Both live as small catalogs you manage yourself, and both drive defaults and behaviour elsewhere in the app.

Statuses¶

A status describes the operational state of an object - for example Active, Reserved, or Deprecated. Each status has a name, a color (shown as a badge wherever the status appears), and an optional description. The statuses list shows the badge and, beside it, a Color column with the raw hex value, sortable, so the exact value can be read or copied off the table.

Statuses are shared across object types: one Active row can be made available to devices, prefixes, IP addresses, racks, … so it reads identically (same color) everywhere. Each status picks which objects it applies to:

IP-specific flags still apply when a status is available to IP addresses:

Maintenance & outage events carry their workflow semantics the same way - as flags on the row, so renaming a status never changes what it does:

The built-in statuses your tenant had in use (Active, Reserved, …) are seeded on upgrade and merged - so the Active you used on IPs becomes the Active your devices and prefixes use too. Manage them all under Statuses.

Naming a monitoring check state¶

A check always ends in one of six states - Up, Degraded, Down, Unknown, Stale, Skipped. Those are what alert rules, escalation and the Outposts run on, and they never change. What you call them is yours: tick Speaks for a check state on a status, pick the state, and that status's name and colour replace the shipped ones everywhere monitoring is shown - the Monitoring column and its split badge, the roll-up on a device or prefix, the filter rail, and the charts on the Monitoring dashboard. Call Down "Critical" in your own red and the whole product says Critical.

Two rules follow from what actually gets stored:

• One status per state. A check records the state, not the status, so a second claimant would be indistinguishable after the fact. The form says which status already has a state when you try to take it.
• The state is still what travels. Webhook payloads, the notification digest and the API keep sending down - the name is presentation, so a script you wrote against Danbyte doesn't break when somebody renames a status.

A status that speaks for a state also becomes pickable wherever a check state is - mapping Zabbix severities onto Danbyte statuses, for one, which then reads in your vocabulary rather than ours.

IP roles¶

An IP role describes the functional purpose of an address - for example Gateway, Loopback, or VIP. Like statuses, each role has a name, a color, an optional icon, and a description.

Roles carry their own flags:

Finding a setting¶

Settings opens on a grid of every page you can reach, grouped by what a setting is about - Identity & access, Integrations, Notifications, Your data, Devices & polling, This install - rather than by which admin tier owns it. Monitoring, for one, sits under Devices & polling beside the SNMP profiles and sensors: most of its page is about polling and discovery, and alerting is one card on it. Which tier a setting belongs to is a control on the page itself: a page that exists at more than one scope, like Email or Directory, carries a Deployment / This tenant / This site switch, and a card that is inheriting shows the value it would fall back to.

The search box above the sidebar filters both the grid and the rail as you type, and matches individual settings as well as pages: type "session timeout" and the result is the Sessions card, not a list of pages to go hunting through. Picking one opens its page scrolled to that card. It matches a name, its description and its keywords, so "relay", "587" or "starttls" all find the mail server.

The global search reaches the same catalog, so you can type "session timeout" from anywhere without opening Settings first.

Every page and card is declared once in frontend/src/lib/settings-catalog.json - JSON because two languages read it: the SPA builds both navigations and both searches from it, and the assistant answers "where do I change X" from the same file. A page cannot appear in one and be missing from another, and a test fails the build if a card is renamed there without being renamed in the page that draws it.

Managing the catalogs¶

Both catalogs work the same way: a list page (filterable by their flags), plus create, edit, and delete. The form gives you a color picker, the flags above, and a sort weight to control display order. When you delete a status or role that's in use, Danbyte warns you how many addresses reference it first.

Display preferences¶

Separately, your own Preferences page controls how Danbyte looks and behaves for you. It is a set of small cards - Appearance, Tables, Dates and times, Navigation, Task emails, Space map - each with its own Save button; a card shows Unsaved changes until you press it. Only Appearance applies as you change it: theme and link styling live in the browser, not on your profile. Below the cards, Table layouts lists every table grouped by area, with a filter, and a Reset per table to drop your own column layout back to the tenant default.

These are saved to your own profile, so they follow you and don't affect other users. Each acts as a personal override on top of the tenant default.

Date format, clock, and timezone default to Auto (tenant default): they follow the Date & time card under Settings → Tenant policy, which in turn inherits the deployment default (Settings → Branding & identity → Date & time) until a tenant admin overrides it. Pick an explicit value to override just for yourself; set it back to Auto to inherit again. Date pickers across the app display dates in whatever format resolves for you (the value stored is always ISO).

See also¶

• Gateway autospawn - how the gateway role is used.
• VLANs, VRFs & route targets - the other IPAM catalogs.
• Tags & custom fields - attach your own attributes.