RackCode language

Tags

The language operates on "tags", which are plain text strings, most commonly single words much like blog post tags. A tag usually indicates a fact of belonging to certain class or group, or it may express, that certain boolean predicate is true. In RackTables, for example, several objects can be tagged with "development" and this will show their functional assignment. Some of those objects could be tagged with "room 112" to reflect their location. Tags may have parent tags. The "room 112" tag (and perhaps some others) could have "main building" as its parent, altogether corresponding to building plan.

Tags serve dual purpose: to classify entities for easier browsing or asset management and to form security context. Autotags are added into the context automatically and have dollar sign prepended to their ID. Lettercase in tag names sometimes matters: one can't create two tags, whose names only differ in case, but tag names referenced in the RackCode are searched in the security context with case preserved. IOW, if some entity is tagged with "Dogs", a {dogs} tag test will never return true.

Tag chain

A tag chain is just an unordered set of tags with an important extension: if a tag is present on the chain, all its parent tags, up to the topmost one, are always present too. This is true for each tag on the chain.

Predicates

A predicate is a boolean non-recursive function, which returns either true or false. The function is referenced by its symbolic name and may use both tags and other predicates to build boolean expressions. The order of definitions matters, i.e. the predicate must be declared at the moment of a grant rule evaluation, if the rule is referencing it (this is verified automatically). Subsequent definitions cancel previous definitions of the same predicate.

BNF/regexp

CODETEXT ::= CODESENTENCE | CODETEXT CODESENTENCE
CODESENTENCE ::= DEFINITION | GRANT
GRANT ::= DECISION EXPRESSION
DEFINITION ::= DEFINE EXPRESSION
DEFINE ::= define PREDICATE
DECISION ::= allow | deny
EXPRESSION ::= BOOLCONST | TAG | PREDICATE | not EXPRESSION | (EXPRESSION) | EXPRESSION BOOLOP EXPRESSION
BOOLCONST ::= true | false
BOOLOP ::= and | or
TAG ::= {ID} // identifier in curly braces
PREDICATE ::= [ID] // identifier in brackets
ID ::= ^[[:alnum:]]([\. _~-]?[[:alnum:]])*$

Comments

Comments last from the first # to the end of the line and are filtered out automatically.

Automatic tags

Autotags aren't shown by default, this may be changed on the "user interface" config page. Below is the list of currently used autotags.

$page_something

Always set; "something" is the name of the current page.

$tab_something

Always set; "something" is the name of the current tab.

$op_something

Only set when an operation (change request) "something" is being processed, usually immediately after hitting some kind of "submit" control. Everything happens behind the scenes, then the user is redirected to some view (often, but not always the same he arrived from) and a message log is displayed on the top of the page.

$any_op

Set, if any operation is being processes. Having this autotag in a deny rule should (not finished yet) block all modifications to the database.

$id_000

When operating on a rack object (asset), this tag is always set with 000 being its database ID.

$typeid_000

Same as above, but for the ID of the type of the operated object. E. g., servers produce $typeid_4.

$cn_somename

If an object has such a common name "somename", which makes the above string be a valid tag name, this autotag is added to the context.

$any_object

Always present in all views for objects (isn't it equivalent to $page_object?).