*If you will have the same users in the new project that are in the existing project.
To avoid the Personal and/or User definition files being part of this import, we would suggest the following:
Log in to the existing project as MANAGER
Select Project > Export
In the Export dialog set Owner to Everything and Info Type to ProjectSchema and User Profiles (if users are required, see comment above)
Press Export to create the export file and close the Export Status dialog but do NOT close the Export Information dialog:
In the Export Information dialog, change the Info Type to ONLY show Definition Files:
You will see that some new options appear – Definition Type and Location:
The Definition Type option allows you to specify the types of definition file to be included in the export. For this example, we will leave this as All:
The Location option defines which location you are exporting the definition files from.
Users may have created Personal or User definition files that might not be relevant to the new project. Personal and/or User definitions might only have been useful to an individual person rather than the project so could be omitted.
In this case, we would only need to select Team*, User Type* and Project
* It may only be necessary to select Project
Press the Export button again. This will present you with the option to Overwrite, Append or Cancel. Select Append:
Select Project > Import and set Owner to As in File and Overwrite to On:
You will see that your new project contains:
All the Project Setup information including the phase hierarchy and all supporting definition files
If you had NOT chosen to append the definition files, it is highly likely that the phase hierarchy from the existing project would not work in the new project and would produce errors.
These definition files are important to define the WorkBench environment.
Also, if you had chosen to export all the definition files, this may have resulted in numerous views, forms, queries, documents etc., that are not particularly relevant or accepted into project definitions.
A Fully Customisable Systems Engineering Environment
We use definition files to define your Cradle environment to your project’s needs.
Queries – how we filter items in the database
Views – how we view the lists of filtered items
Forms – how we see individual items
Matrices – how we view results of queries and linked items in rows and columns
Metrics – how we can see the numbers of items meeting a criteria
Reports – how we output exported tables containing a set of query results formatted according to a particular view and table style.
Dashboards – management summary that can define KPIs
Navigations – how we filter cross references
Startpages – how we provide a range of selectable actions, each of which either displays a PDF file, opens a specific page in the Cradle help, opens a particular dialog or runs a query, report or similar. The start page is displayed in the main working area of the WorkBench UI and is fully customisable
Sessions – store information about your required WorkBench environment such as window dimensions, current project, opened queries, reports etc. to be loaded upon login
Graphical Print Settings – how we print diagrams
Hierarchy Diagram Properties – style in which we show items
Capture Setups – how we are to capture items in Document Loader
Report Styles – styles available for reports which include font, alignment, underline, etc.
Graph Styles -styles available for graphs which include fonts, grid size, axes size, etc.
Export Formats – settings of exports to reuse at a later time
Import Formats – settings of imports to reuse at a later time
All of the above are available in WorkBench and subsets are available in other tools, e.g. you can run queries in WebAccess or use Import Formats with c_io
For more information on how to setup these definition file please see definitions section of our online help.
These definitions are stored in one of several areas:
Project – visible to all members of the Cradle project (PROJECT privilege is required)
User Type – visible to all users with your user type in this project
Team – visible to all members of your current team in this project
User – visible only to you when logged in as this Cradle username in this project
Personal – visible to a specific machine login username, across all projects to which he/she has accesses
Automatic – visible to all members of this Cradle project (you cannot save definitions with this scope). Automatic definitions are created as a starter set when an item type is defined. They are a good starting candidate for editing and then using ‘Save As‘
System – you cannot save definitions with this scope
WorkBench provides the ability to manage your Cradle environments via:
These allow you to copy, move or delete definition files through the WorkBench interface.
Using these methods to manage your definitions enables you to reduce the number of stored definitions within a project by allowing users to share definitions at the team-level as opposed to users having their own copies of the same definitions.
To reduce the amount of redundant definitions, it is possible for the user to create a User Definition opposed to creating a Project definition if it is for personal use. It is also possible to delete previous Definitions if they are no longer required.
A user could:
Move definitions from a user to that user’s team, or to the project, for everyone to use
Copy definitions from one team to anotherteam or a member of another team
Move definitions from a user to become accessible by all users of a specific user type
Updated Article 04/02/2019 – Added info on Redundant Definitions
Each Cradle database contains different sets of information. These can be imagined as layers, where each layer uses the data in the layers below it. For example, cross references cannot exist until the items exist whose relationships are shown by the cross reference. These layers are, highest to lowest:
1. Cross references – the links between the data
2. Items – the data
3. Definitions – how to find, view and report the data
4. User profiles – who can own and access the data
5. Schema – the structure of the data
You can export/import each layer individually, or in any combination, or all layers. You should only import a layer of information if the lower layers already exist in the database (unless you know that it is safe).
To initialise a new database from an existing database, you need as a minimum:
– The schema
User profiles are needed to use a database and may be needed for some parts of the schema (such as workflows and alerts) and definitions (user and personal scopes).