Hiding Information

Teams / Skills / Roles and Visibility

Not all data in all projects should be visible to all users and roles. Hiding information in Cradle can be done in a number of ways.

Classification

A hierarchical access control is provided with Item Classifications. These Classification values restrict a user’s ability to see an item based on their clearance level. The values are a sequenced list, those users with a higher classification will be able to see items equal or at a lower classification than the level they hold. The classification is set on an item by item basis.

Screenshot of user privileges dialog
Classifications

Item Types

Entire item types can be hidden from users based on their skill. If you don’t want some users to see finance information, then ensure you create a finance item type. Create and assign a finances skill to this item type and then only give the skill to those who warrant it.

Read Only Items

The same mechanism that controls complete access to an item type can also be used to assign RO accessibility. Regardless of the item’s state (draft/baselined etc.) users are only allowed RO access based on the skill they possess.

Read Only Categories

You can protect certain bits of information within an item from alteration by setting a skill which prevents updates by those without the skill.

Frame Access Control

Frames are used to hold larger blocks of data within an item. These could be paragraphs of text,  binary documents (such as a spreadsheet) or just a date. Access to individual frame types can be controlled by a skill. Users without the skill will either not see the frame at all or will see it Read Only.

Privileges

The privileges a user holds can control whether they can see information based on ownership. The normal pattern being users and the teams they belong to being able to see items owned by the users and their team. Access to information owned by teams to the side, above or below the current user is controlled by the User’s Privileges

Screenshot of user privileges dialog
User Privileges
Article Updated 04/02/2019 – Added images

Controlling Tree Labels

Trees

Trees are a common way to explore the information in a database and controlling tree labels is important as:

• Any query’s results can be shown in Tree style
• Trees are available for each item type from the Project sidebar
• The Phase hierarchy can contain nodes that run queries whose result item are shown as nodes in the phase hierarchy tree

A default tree view can be set for individual items. This view is used to construct the text label whenever a tree node is added for an item of that type. Any frames, linked items, discussions are ignored.

As shown in the screenshot below, “REQ-1” in the DEMO project as the top level item, using the tree view you can see all items which are linked to REQ-1

Screenshot showing the Requirement hierarchy tree from a query in the DEMO project
Requirement hierarchy tree from a query

Cradle has a default for the labels of the nodes in these trees. This default uses an item’s Identity, Name, Key, Version and Draft attributes. This label may not be what you want to see, particularly if:

• Your items are auto-numbered, so the Identity is generated by Cradle and is not important to you,
• If most of this type of item do not have anything in their Name attributes

You can control the contents of labels in tree nodes. To do this:

1. Login to WorkBench as a user who can modify the schema and can create project-wide views
2. Define a new view that lists the attributes that you want to appear in the labels. This view can include any attributes except calculations and frames. Only the first row in the view will be used. Save the view with Project scope, to ensure that everyone can use it.
3. Start Project Setup from the Project tab, set Options to Item Definitions and select the Item Types tab
4. Select the item type whose tree labels are to be set and choose your view from the Tree view: drop-down list
5. Save the schema and close Project Setup

Now when any user sees any items of this type in any tree, the labels for these tree nodes will only contain the information defined by the view.

Setting up tree labels for item types can be a very efficient tool when using Cradle to help your team save time when browsing through the tree nodes for items types, as this will only show the pre determined information the user is looking for.

Article Updated  – 04/02/2019 – Added image and conclusion

 

Cradle-7.1 – SysML Videos

Our 3SL colleagues in the US have posted a series of videos demonstrating the SysML support in Cradle-7.1. This is a single demonstration, split into a series of parts:

You can access these demonstration videos here:

https://www.youtube.com/channel/UCdnZeLWcaufRjC0MBX1iuuQ

Please look at these videos and see how SysML models can be built in Cradle and how these models can be integrated into other information, including requirements, tests, test cases, defects, issues and risks.

At 3SL we believe that MBSE is the ideal approach (whichever notations you choose to use) but only if it is integrated into all of the other information in your project.

MBSE in isolation is just a bunch of pretty pictures!

Show Link Types in HIDs with Colour

Looking for a way to brighten up your day?!

What better way than using Hierachy Diagrams (HIDs) that show link types in colour!

Hierarchy Diagrams (HIDs) are an excellent way to show the relationships between items in your database. The boxes in the diagrams are the items and their connecting lines are the cross references.

You can define a colour for each cross reference link type in the schema. If you do, then these colours are used to draw the cross references in HIDs.

This means that you can easily interpret the connections shown by the HID as, for example ‘has child’ or ‘is satisfied by’, or ‘allocated to’ relationships.

If you have not tried setting colours for your cross reference link types, please try it and see how this will transform the ease with which your HIDs can be interpreted!

Screenshot showing Example Hierarchy Diagram
Example Hierarchy Diagram

Controlling External Commands’ Access to Usernames and Passwords

External commands

As you may know, there are many opportunities to extend Cradle’s functionality, including using external commands. These commands can be triggered from user-defined start pages, or the user-defined phase hierarchy, or when you work with attributes inside items.

Commands can be made variable using Command Directives. Some of these can access the username, password and project code of the current user.

For example, the Command Directive $LOGIN is replaced by the string -login user,pwd,pcode where username is the current user’s Cradle username, pwd is the current user’s plain text password and pcode is the project code of the database that the current user is logged-in to.

The Command Directives $CUSER, $PASS and $PROJC are available for each of these components.

Because of the sensitivity of this information, you can control whether or not these Command Directives are active.

You do this using the file:

eci_config

Whis is found in the admin directory of the Cradle installation on the server (so the eci_config file that may exist in Cradle client installations on end users’ computers is ignored).

You can enable / disable various ‘sensitive’ Command Directives by editing this file in the Cradle installation on your ‘Cradle server’.

Note that many of the sensitive Command Directives are enabled by default, but $LOGIN is one of those that is not enabled!

Article updated 04/02/2019 – Added image

Missing api-ms-win-crt-stdio-l1-1-0.dll

Recently, we have received reports from some customers who have been installing Cradle-7.1, or upgrading to Cradle-7.1, and have seen messages saying that the file:

api-ms-win-crt-stdio-l1-1-0.dll

is missing or is not available.

These messages have been seen in installations on Windows 7 and Windows Server 2012, but could potentially affect other versions of Windows. The messages have only been seen in a small number of Cradle installations. If you want to see more detail, please search for this filename in your favourite search engine, such as DuckDuckGo, Yandex, Baidu, Bing, Yahoo or Google.

In all cases, the solution to these problems is to install Windows updates. Sometimes, you may have to do this more than once, since installing Windows updates may install a pre-requisite for a later Windows update. So, please repeatedly install Windows updates and reboot and keep doing this until there are no more updates to install.

When you have installed the Windows updates, uninstall the Cradle-7.1 that you were trying to install and install it again.

Everything will then be OK.

We apologise for any inconvenience that this may cause.

Describe Your Schema to Help Your Users

Schema

The structure of each Cradle database is defined by it’s schema. This contains many parts, but the most fundamental are the ‘item types‘ for the types of information that Cradle will manage and the category and frame attributes of these item types.

Item Types, Categories and Frames

When you define the schema, you can specify a ‘description‘ for all of these parts, including:

  • Item types
  • Category codes
  • Each value in a category code that is a pick-list of value(s)
  • All frames
Setting schema descriptions in Cradle for categories and their values
Schema Descriptions

Setting Schema Descriptions

These descriptions are very useful to end users, because Cradle will display them as tooltips in the UI (User Interface). For example, when the user moves to set a category value, Cradle will display:

showing descriptions within tooltips for categories, their values and frames
Category and Frame Tooltips
  • The description of the category
  • The description of the current category value

When a user moves into the heading for a frame, the UI will display the description of that frame as a tooltip.

Link Rules

A comment as to the purpose of the link rule can be added to the schema. This is a useful aide-mémoire to those editing the rules. However, if a certain action is prohibited by the rules, then the user is shown why.

In this example two rules have been set up, one to allow user Alan to modify sub-part to component links and another to prevent all users modifying the same link. Because of the top-down sequence of rule matching this has the effect of allowing only Alan to modify cross references of this type. The example shows Dewi trying to modify the link attributes between the Pump parent component and the Pump housing linked as a sub-component. The warning shows why this alteration was prevented. The text from the schema is shown in the dialog.

documenting the link rule purpose in the schema allows the user to be shown the reason an action was rejected
Link Rule Documentation

Groups

Within Cradle item types can have a number of different categories. Some item types may share the same categories, others may use unique values.

The Group field is available across the whole project. When the schema contains a number of entries for the Group field, these can be applied to any item type. If the project defines values for the Group, selection is only from the defined list. If no pick-list is defined, it is simply a free-form text field, to use as the user wishes.

Showing the setup of group descriptions in the schema and tooltips in a form
Group Descriptions

This example shows three types of assets, Capital, Inventory and Liquid. Some item types may only fall into one group, in this example a physical bedroom is going to be a capital asset, the guest supplies are liquid assets. However, when it comes to fittings, the light is being grouped with the Capital assets and the bed and so on in the Inventory group.

However you choose to use this cross item categorisation, the descriptions given to the group show as tooltips when hovering over the group field in a form.

Article updated 17/09/2018 – Cleaned up post

Rationale for RM and SE Tools

We are pleased to release a new presentation that discusses the need and role for requirements management (RM) and systems engineering (SE) tools and the need for a change in paradigm from document-based processes to data-based processes.

It is available here:

https://www.threesl.com/downloads/download.php?version=v7.1&section=presentations&filename=rr01106-UK_SE_Tool_Rationale.pptx

And as a short link here:

http://ow.ly/4nfxU1

Please visit the Resources section of our website: www.threesl.com for this and many other useful resources!

We hope that this presentation is helpful to those considering RM and SE tools!

Role and Representation of User Requirements in Systems Engineering

We are pleased to announce the second in our a new series of white papers that will discuss the role of different types of information in systems engineering processes, and how to deploy each of them in Cradle.

The second white paper in this series discusses user requirements. It is available here:

https://www.threesl.com/downloads/download.php?version=v7.1&section=whitepapers&filename=ra00701-User_Requirements_in_Systems_Engineering.pdf

And as a short link here:

http://ow.ly/4n6nHO

Visit the Resources section of our website: www.threesl.com for this and many other useful resources!

We hope that this white paper is interesting, the next one will appear quite soon!

Role and Representation of Needs in Systems Engineering

We are pleased to announce a new series of white papers that will discuss the role of different types of information in systems engineering processes, and how to deploy each of them in Cradle.

The first white paper in this series discusses needs. It is available here:

https://www.threesl.com/downloads/download.php?version=v7.1&section=whitepapers&filename=ra00601-Needs_in_Systems_Engineering.pdf

And as a short link here:

http://ow.ly/4mXDvY

Visit the Resources section of our website: www.threesl.com for this and many other useful resources!

We hope that this white paper is interesting, the next one will appear quite soon!

UPDATED: April 2020 – Meta data