Kinetic Data – Attributes

Video Transcript

My name is Rodney Holmes and I’m here to discuss attributes within the kinetic platform. Here at kinetic. We use attributes as a way to extend our different components like forums, caps, users and teams.

You can think of attributes like variables or tags. They can be used to enhance form logic, implement security policies or drive specific behavior within portals and workflows.

Attributes are commonly used by kinetic Platform Developers as a way to expose data so that non developers can then affect it and enable a change in the system behavior without changing the underlying code.

Here’s a quick example. A developer creates an attribute on the space or cap level that stores a URL for the background image that gets displayed within a portal. Inside the portals HTML and CSS.

The developer then references this attribute allowing a non developer to change the background image without having to change any of the front end code. Before we can use an attributes value, we must first create it and define its type.

Attributes for spaceflight components, like users and teams are defined at the space level of a project and require space admin permissions to create or modify them. attributes.

For cap level components like forms and categories, or the cap itself are defined at the cap level. They can only be created or modified by users with access to that cap. Every attribute that we define will have the following settings a name field, which is how the attribute will be referenced within the system.

After it’s created a description field, which will define how the attribute is intended to be used. This will help others that are also managing the system better understand the purpose of and leverage this attribute, and last and allow multiple attributes checkbox. If this is set, the attribute can be given multiple values.

An example use case would be creating an attribute called keyword to act as a tag for a form. With multiple values, it could hold multiple keywords that could all relate to that specific form. Now let’s dive into the different attribute types. We have space attributes that are defined at the top level by space admins to help with the administration of the entire space.

Common examples include variables like color, and image URLs to enable non developers to enact simple changes to the space without needing to access the code base. There are user attributes which are also defined at the space level and are used to extend a user record within the system.

These attributes are defined by space admins and not the users themselves, but can then be applied to users records by anyone with user modification privileges. A common example would be a user attribute named manager.

We could then use this within a workflow to assign approvals to a users manager. Because these attributes are not changeable by the end user unless they have user modification privileges.

These attributes are a safe and convenient way to store this type of information. User Profile attributes are similar to regular user attributes, except that they are modifiable by the end user.

Common examples of user profile attributes could be a phone number, or address. Since this data is safe for the end user to update whatever it does change, we would use the user profile attributes as opposed to the user attributes. Next, we have team attributes which are configured to extend a team’s similar to how user attributes extend to users.

They are defined by space admins at the space level and can be applied to a team by anyone with the team modification privileges.

To use a common example, a team attribute could be named manager and then populated with the team’s manager’s name or ID information. This could then be used within workflows to escalate or notify the manager when workflows have completed or failed to meet deadlines.

Data Store form attributes are configurations used to extend data store forms within the system. They are defined at the space level by space admins, and can be applied to a data store form by anyone with you guessed it for modification privileges, a common data store form attribute could be named owning team, which may be then leveraged within a security policy definition to determine which team is able to create or modify data store records in that particular instance.

Drilling down to level we have cap attributes defined and modified at the cap level by those with CAP modification privileges. A common cap attribute might be named description, and contain information detailing the purpose of the cap, which could then be displayed to the end user. This attribute could easily be changed by anyone with modification privileges, if the description ever needed to be updated.

Drilling down even further category attributes are configurations used to extend the functionality for a category within a cap, defined and set by anyone with CAP modification privileges within the categories respective cap. These attributes are commonly used to build hierarchical relationships between categories and then represent them as such within the end user portal form attributes extended the form component within individual caps. They are defined by those with CAP modification privileges, and modifiable by those with form modification privileges to that respective form. A common form attribute could be named icon, which could then be used by the portal developer to display the Forms icon or logo within the portal based on that attributes value. It’s pretty common within kinetic to use attributes in a hierarchical fashion.

Lower level attributes from components like forms and categories can be used to override identically named higher level attributes from the cap, or even the space level. And that’s a quick overview of attributes how they’re defined, modified and used within the kinetic platform.