Permission Nodes

Permission nodes are part of Archivian’s custom permission system: a list of text strings. Each node grants permission to something, and omitting it means no access by default. Permission nodes are given to titles or teams, not directly to staff.

Permission node

A single permission node is made up of sub-nodes, each separated by a dot (.). A sub-node can target a feature, a resource, an “ownership”, an action category, or an action within a category — and can also contain wildcards and extenders (covered below).

Some examples of nodes and sub-nodes:

• case — a sub-node targeting the Case feature.
• read — an action (or action-category) sub-node, letting you read something.
• update — another action/action-category sub-node, letting you update something.
• update.label — here update is an action category and label is the action. This is a valid node, but does nothing on its own — it isn’t specific enough to target anything.
• case.ban.own — a mix of feature (case), resource (ban), and ownership (own, i.e. something you created).
• entry.others.ban.own.update.edit — a highly specific node: feature (entry), ownerships (others, own), action category (update), and action (edit). It allows editing only other people’s entries (not your own) in a ban case you created.

Many features and actions are protected by a specific node — without the right node, a user can’t use them.

Wildcards and extenders

These are two special sub-node types. Neither can be used as the root sub-node (the first one) — in case.ban.create, case is the root.

Tip

Working with wildcards and extenders can be tricky at first. If you know the node you’re trying to match against, use the Permission Tester to check whether it matches as intended.

Wildcards

A wildcard is a single asterisk (*), used as a sub-node. It matches any single sub-node.

For example, instead of one node per case type:

case.note.create
case.warn.create
case.timeout.create
case.kick.create
case.ban.create

…you can use:

case.*.create

It works for ownership sub-nodes too. Instead of:

entry.own.ban.own.update.edit
entry.own.ban.others.update.edit
entry.others.ban.own.update.edit
entry.others.ban.others.update.edit

…use two wildcards — one for who created the entry, one for who created the ban case:

entry.*.ban.*.update.edit

Extenders

An extender is a double asterisk (**), used as a sub-node. Where a wildcard matches exactly one sub-node, an extender matches any sub-node and all sub-nodes after it, until a sub-node you place after the extender matches.

For a.**, it matches a.b, a.b.c, a.b.c.d.e, and so on indefinitely.

For a.**.create, it matches:

a.b.create
a.b.c.d.e.create
a.b.c.d.f.g.h.i.j.k.l.m.o.p.q.r.s.t.u.v.create

…but does not match:

a.b.update
a.b.c.d.create.item
a.b.c.d.read
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.create.item

The two most useful patterns are giving full access to a feature (case.** for everything case-related) or an action across a range (case.**.read to read any case created by anyone).

Sometimes an extender is faster than wildcards. Instead of:

entry.*.ban.*.update.edit
entry.*.kick.*.update.edit
entry.*.timeout.*.update.edit
entry.*.warning.*.update.edit
entry.*.note.*.update.edit

…or entry.*.*.*.update.edit, you can use:

entry.**.update.edit

Here ** matches e.g. *.ban.*, then stops on update, where normal matching resumes to match edit against edit.

See Permission System for how nodes fit into titles and permission sets.