Attribute store

Telefakt has a comprehensive key-value store called the Attribute store which you will learn more about in this chapter.

A dynamic set of attributes and values can be connected to any object in the Telefakt database – e.g. Businesses, Lines, Invoices, Connection-Ids's, and Products. All attributes can be created/destroyed and attached/re-attached real-time, without code changes. These allow management of attributes and values by users ,primarliy a product manager job, without the need for programming effort.

Attribute types

A attribute is a key-value pair where the name of the attribute is the key. The values of the pairs can be either free-text or an option from a list. These are normally referred to as literal and enumerated attributes respectively, these are the only types of attributes Telefakt allows. When the attribute is created, or any time after, the list of enumerations for that attribute can be modified by the user, when doing this the user can also decide on the ordering of the enumeration options when they are shown in the UI. A default value can also be specified both for literal and enumerated values.

Attribute groups

The link between products and attributes works using attribute groups not attributes directly. The attribute groups make it easy to collect attributes that have some semantic connection together. The attributes that are in these groups and which groups a product "uses" is, as with most things related to attributes, controlled by the users and they can manage these themselves. For example a user might want to define some usage attributes about ip-addresses, in that case they might want to have attribute for ip-address, one for the net-mask and one for default gateway. The user always want these three attributes to be used together, and so creates an attribute group called IP-Config and put these tree attributes in that group. Now any product that wants to store a ip-address also can store the net-mask and default gateway.

Validation types

Even though you can think of literal attributes as having a free-text field they can actually be configured with a validation type. Existing validation types, and variations on these, can be applied and used on any attribute by the user. New validation types that are not based on Regex will require some work in Telefakt to actually ensure the validation is correct, if they are based on regex the validation will work without further work. Currently Telefakt supports validations checking;

  • The value is a number
  • The value is text
  • The value is a valid IPv4 address
  • The value is a valid IPv6 address
  • The value is a valid subnet mask
  • The value is a valid CIDR notation

Controller attribute

While attributes are used for lots of different things in Telefakt, and different systems, one special type of attribute is the controller attribute. These attributes are used to control the behaviour of other attributes. The most used type of these is the Number of VLANs attribute, which defines how many VLANs a particular port on a router/switch is configured with. If a port is configued with three VLANs the Number of VLANs attribute should have a value of three, that will automatically create three instances of the attributes controlled by this controller. In this case that means we get three VLAN ID attributes, each of them capable of holding a numberic VLAN id.

Required

Sometimes users might want decide that the value of a attribute is required before the order can progress. In these cases the attribute should be set as required, this will make it so that users can't progress without filling in the value. Any attribute can be a required attribute, and this can also be modified after the attribute is created.

Was this page helpful?