|
<< Click to Display Table of Contents >> Glossary |
  
|
|
<< Click to Display Table of Contents >> Glossary |
|
Jargon:
The specialized or technical language of a trade, profession, or similar group.
When something is complex it tends to generate its own vocabulary to try to communicate specific, detailed meaning in an unambiguous way. This is unavoidable and Cimera is no exception. The glossary will try to demystify what may initially appear as gibberish.
These relate to the history (or audit) of items. Every time a user does something (create, update, delete, promote) to an Item or a Relationship then Cimera records who did what, to what and when. And if a reason object was given then "why" is also recorded.
An Activity is a single task that a user carried out. For example Create an Item
Each Activity will have one or more corresponding Actions.
An Action is a task that Cimera carries out in response to an Activity.
Example1: An Activity Create Project Risk RSK-001 may have two Actions, one to create the new Project Risk and one to link it to the Project that was specified in the Item Details window.
Example2: An Activity Delete Product Contax may be accomplished by multiple Actions:
| • | For each version of the product delete all relationships and delete the version itself |
| • | Delete the relationships to the product |
| • | Finally delete the product itself |
If an item is a Workflow item then the Assignee field will be set to the Group or Group\User who is now required to perform some action on that item.
A quality or characteristic of an Item Type. An attribute is a field and has as Attribute Type.
An Item Type specifies which Attributes every Item of that Item Type will have.
This describes the type of data than an attribute can hold such as text, a number, a date, a Boolean value (two states such as Yes or No) or a list of attached files.
See Attribute Types for a full list.
A logical grouping, or categorisation, of related Item Types.
A Bucket "contains" a group of Item Types
An Item Type must be in at least one Bucket, but can be in many. Items of that Item Type will also be in one of those Buckets.
As well as providing a visual grouping of Item Types in the Item Explorer, Buckets allow security rules to be defined on a group of Items.
A collection of User Queries that are arranged and sized for executing and displaying as an atomic unit.
See Dashboards
Bespoke code that extends Cimera's features and can be used to automate repetitive tasks. They can be set to execute whenever an item of a particular Item Type is created, updated, deleted or promoted.
Exits execute on the Cimera Server whereas PlugIns run on the client computer.
See PlugIns
See Custom Reports, Helpers & PlugIns
The ability to dynamically navigate the relationships between Items. See Relationship Explorer
How an attribute is defined in the Process Modeller. An Item Type will have a field defined on it for every attribute that items of that item type will possess.
A Group is a collection of Users. It allows security rules to be set for related Users and for Items to be assigned or owned by, say, a team or department as opposed to by an individual.
A complete audit of everything that has happened to an Item. See History (Actions) Window
Inherit
Shorthand for Item Type Inheritance
Cimera Integration allows data maintained outside Cimera to be reconciled with data maintained inside
See Cimera Administration Guide for details
A 'thing' that you want to manage. An Item is simply another name for a thing. A server, a person, a bit of software and a meeting room are all examples of things. Each item is a specific instantiation of an Item Type.
| The directory in the file system where Cimera stores file attachments. |
See Cimera Installation Guide for details.
An Item Type specifies what kind of thing an Item is.
| For example | 'Dave' is an Item which has an Item Type of 'Person' |
| 'Ford Mondeo Diesel Estate 1.8TD' is an Item which has an Item Type of 'Car Model'. |
| 'PR-12345' is an Item which has an Item Type of 'Problem'. |
The Attributes and Lifecycle that each item of a particular Item Type will have are defined on the Item Type
The ability for Item Types to inherit the attributes of another Item Type.
A Lifecycle is the ordered series of states that an item progresses through during its lifetime. Lifecycles help ensure consistent processing of items such as changes, problems and software releases. Each Item Type must have a Lifecycle. The current status of an item is used to determine which attributes are mandatory and which are read-only. The current status may also be used in security rules to determine access to items and attributes.
Lifecycles have a series of transitions, pairs of "from" and "to" statuses, that determine the path an item must follow through its Lifecycle. When an item is at a particular state it can only legally progress to other states as defined by the transitions.
The process of changing states, as defined by the transitions, is called a promote
Example:
The Lifecycle for a problem contains the following normal path: Open -> Assigned -> Diagnosed -> Resolved -> Closed
Additional transitions may be defined to allow the problem to go from Assigned back to Open and from Diagnosed back to Assigned.
As all Item Types must have a Lifecycle defined those that genuinely only have a single state are assigned the system defined Lifecycle of Single State which has a single state of Exists which cannot be changed.
An administrator operating in Admin Mode can promote an item to any state in its Lifecycle regardless of the defined transitions.
The Object Spec of an item defines how it is described when referred to anywhere other than when it is being viewed on the Item Details screen.
For example
Assume Item Type A has a relationship with B
When a list of all A's is displayed, say in an Item List, then the details of A's child B is presented by showing B's Object Spec
On the Item Details screen for A there will (if required) be a reference to B and its ObjectSpec will be used.
Similarly when B is displayed then the ObjectSpec for A will be used.
| The format of the Object Spec is configurable, but defaults to : | [Name of the Item Type] Name of the item (current status) |
Bespoke code that extends Cimera features, for example adding menu options, automating repetitive tasks, adding custom actions.
PlugIns run on the client computer as opposed to Exits which execute on the Cimera Server.
See Exits
See Custom Reports, Helpers & PlugIns
The Status of an Item is changed by Promoting it. The status cannot be changed by updating its attribute displayed in the Item Details window.
The current state can only be changed to one of a predefined list of states as configured by your administrator.
See Lifecycle for more information
See Also Promote an Item (changing its status)
When an item is changed an option is provided to enter a reason for the change. Whilst the Audit History records what has changed, the reason provides the ability to say why it changed.
See Also Give a Reason for an Activity
Two Items can be linked together by creating a relationship between them
The Cimera Administrator will define the "rules" of the Relationship
| • | Which Item Type(s) are allowed to be at the "Parent" end of the Relationship |
| • | Which Item Type(s) are allowed to be at the "Child" end of the Relationship |
| • | What Statuses must the Parent and Child be in for a Relationship to be created. |
| • | The description of the relationship, i.e. what text describes the Relationship attribute on the Item Details Window & what text appears in the Relationship on the Relationship Explorer Window |
| • | (Optional) any Attributes that are associated with the Relationship. |
e.g. a Person may have a relationship booked with a Meeting Room.
Two attributes of that Relationship would be Start Time and End Time which would have an Attribute Type of "Date and Time"
See Relationship
When a User is put in a Group he is assigned a Role on that Group.
This models the situation where, within a team, different people have different functions and therefore need different security requirements.
Security is granted to a user, a group or a role on a group.
For example, with Group "MyDepartment" the assigned Roles "Manager" or "Administrator" may have more security privileges than the person with the Role of "User".
Permitted Roles.
A Group does not have a list of applicable Roles - Roles are maintained separately. A User could be assigned any Role on any Group. It is down to the Cimera Administrator to decide whether this is sensible.
Common names for roles would include 'user' for the most common role, but also 'Team Leader', or 'Admin', or 'Manager' for roles that grant additional security access.
A task or job that is scheduled to execute at predefined times. For example an External Data Source could be scheduled to reconcile data from a Third Party tool with Cimera Items 4 times a day on weekdays.
If an Item is defined as being versionable (i.e. it can have different versions) then the Stem holds the information that is common to all of the versions. A Versionable Item comprises of the Stem and its Versions (zero or more). The Stem and its Versions have attributes defined for them separately and relationships are similarly defined to be with a Version or with a Stem.
A position of an item in its Lifecycle
A shorthand for Item Type
See Item Type
A person who has been set up to be able to use Cimera by the Cimera Administrator.
A rule which define which Items can be related to which other Items. See Relationship
For example :
Valid Link "VLK:1" may say that a relationship can be created between Items with Item Type "A" at one end, and "B" or "C" at the other.
Valid Link "VLK:2" may say that a relationship can be created between Items with Item Type "E" or Version "F" at one end, and Version "G" or Stem "H" or Item Type "I" or "J" at the other.
The meta-data for Item Types A..C will say whether or not VLK:1 relationships are to be shown or hidden when items of that Item Type are displayed or listed
The meta-data for Item Types E..J will say whether or not VLK:2 relationships are to be shown or hidden when items of that Item Type are displayed or listed
Each Item Type can be defined as versionable or non versionable. A versionable item comprises of a Stem and zero or more versions. The Stem holds the information that is common to all Versions. Both the Stem and Versions can have user-defined attributes and relationships to other non-versionable items, stems or versions.
Versions are most commonly used to hold information about software.
For example:
A versionable Item Type Software Product is created.
The Stem of the Software Product would have attributes shared by all the versions. Like supplier and a high level description of the product.
The Version part of the Software Product would have attributes specific to each version. Like version number, release date, release note, new features
Cimera supports Workflow. Lifecycle states can be set to indicate that when an item is in that state then an action is required by the User or Group that it is assigned to.
See Workflow