Объекты сервера

Parent page: Designing with a Connected Workspace

Within a connected Workspace, each design entity that can be stored, managed, and reused, is represented as a specific type of Item. An Item is uniquely identified within the Workspace and can contain any number of Revisions, where a revision contains the data for that Item. Each time a change is made to the data contained within a revision – which for most Item types can be edited directly within an associated temporary editor – it is saved (or re-released) into a new revision of that Item, ensuring that no existing revision can ever be overwritten, and thereby ensuring the highest integrity.

Supported Content Types

Different Items are used to store and represent different types of data. One Item could represent a schematic symbol, another a PCB component model, while another could contain the generated fabrication data from a released board design. To declare the type of content an Item (or rather its revisions) will be used to contain, its Content Type property needs to be specified when creating or editing that Item. To put this another way, you are in essence specifying the Item Type.

The following table lists the various content types (Item types) that can be created manually by a user in a connected Workspace, along with their:

• Associated Folder Type – the purpose-made folder type, where available, in which to store the content of that type. This has no bearing on the content of the folder. It simply provides a visual 'clue' as to what is stored in a folder and can be beneficial when browsing a Workspace for particular content. The content can be stored in any type of folder, including the Generic Folder.
• Content Type Code – the code used when assigning the unique ID to a created Item of that content type, and the parent folder's Item Naming Scheme uses the entry $CONTENT_TYPE_CODE.
• Folder Type Code – the code used when assigning the unique ID to a created Item of that content type, and the parent folder's Item Naming Scheme uses the entry $FOLDER_TYPE_CODE.

Item Revisions

An Item can have any number of revisions, which are essentially an evolution of that Item over time. A change is made and the new data content is saved/uploaded/released into a new revision. The data stored in each revision of an item is therefore typically different. To identify between these different revisions of an Item, a revision identifier (ID) is used, which in combination with the Item ID creates a unique identifier for each release of an Item. This gives us the Item-Revision.

A full Item-Revision ID therefore simply identifies a specific revision of a parent Item. There will always be at least one revision of an Item (the first release), but there could be many, depending on how many times the data for that Item has been saved/uploaded/released. An important point to make here is that you can only release to a particular Item-Revision once. If there is a change, then a new Item-Revision must be created. This ensures the highest integrity, as the data contained in a given revision can never be overwritten by re-releasing to the same revision. To release again, a new Item-Revision must be used.

The simplest way to grasp the concept of an Item and its revisions is to think of a 'box', into which all the data for that particular revision of that particular Item is stored. When the Item is released, the data is put into the box and the box is closed. The Item ID and the Revision ID become labels on the side of that box – they allow instant recognition of what the contents of the box is used for. If the data needs to be updated and re-released then the Revision ID is incremented, creating a new box.

The Item-Revision 'Box' – labeled with the Item ID and Revision ID. The contents are the data required to build, or represent, that revision of that Item.
The act of releasing closes the box, preventing any other data being released to that revision in the future. The full Item-Revision ID, in this case, would be: D-820-1001-01.A.1.

The Lifecycle of an Item Revision

Main page: Defining Lifecycle Definitions for a Workspace

Another important aspect of an Item-Revision is its Lifecycle State. This is another identifier that can be used to quickly assess what stage that revision has currently reached in its life, and what designers are therefore authorized to do with it. Where the Revision reflects design changes made to the Item, the Lifecycle State reflects the state of the item from a business perspective, such as Planned, New From Design, For Production, Obsolete, and so on.

Initially, an Item-Revision will be in the Planned state – ready to receive (and store) the data generated by the applicable save/upload/release process. Once that process is complete, that revision is closed (data cannot be saved/uploaded/released to that same revision again), and the Lifecycle State is set to the next applicable state. While the data for this Item-Revision can not be modified, the Lifecycle State can be changed to reflect just where that Item-Revision is, in terms of its useful life.

Your Workspace provides different types of lifecycle management – from basic management, through simple management including states and state transitions, to fully structured management, where the states and state transitions are organized into distinct stages, with a link between those stages and the Revision ID. Based on these different lifecycle management strategies, a number of standard Lifecycle Definitions are defined, from which you can choose to model the state transitions that an Item-Revision may undergo over time.

An Item-Revision's lifecycle is managed manually and in accordance with company policies and practices. Consider a revision of a PCB Fabrication Data Item, containing the data to physically fabricate a bare board. Once the development team is happy with it, the Lifecycle State of that revision might be elevated to a state such as In Prototype and, all being well with the subsequently manufactured prototype, would then proceed to an In Production state. At a later date, another revision of the same Item might be needed (another box!) to introduce better functionality. Once released, this second Item-Revision would progress through prototyping to production, while the lifecycle of the previous Item-Revision passes through deprecation and finally to obsolescence. The point is that the lifecycle information shows how the contents of the 'Item-Revision box' can, or rather are, being used.

Example showing the 'life' of an Item-Revision. The revision was at one time authorized to go for prototype and on to production, but subsequently became deprecated and is now obsolete.

Creating an Item

The Items themselves are created directly within a connected Workspace, and all of the data needed to manufacture/represent an Item is then stored in that Workspace, against that Item number. Depending on the content type, an Item can be created manually, or automatically as part of a save/upload/release process. All content types can be created from within Altium Designer through the Explorer panel. When working with components, creation is also possible through the Components panel.

Once you have defined the required folders, you can proceed to create the content in the Workspace. To create an Item, select the appropriate folder, then right-click in the Items grid region of the panel and choose one of the commands from the Create Item sub-menu. Alternatively, if the folder is empty, use the Add an item control in the center of the region to access the menu.

The Create New Item dialog will appear, providing all controls necessary to fully define the Item.

Specify the details of the new Item in the Create New Item dialog.

For many content types, you have the option to edit and release the applicable design document into the initial revision of that content, after creation. To do so, enable the option Open for editing after creation, at the bottom of the Create New Item dialog (which is enabled by default). The Item will be created and the relevant temporary editor will open, ready for you to create the data for that Item. For more information on working with a particular content type, read its dedicated page, a link to which is provided in the table earlier in this document.

A Word About the Item ID...

An important aspect of the parent folder in which content is created is the Item Naming Scheme employed for it. This defines the format of the unique ID for each Item created in that particular folder. By defining the Item Naming Scheme at the folder level, content can be created quickly within that folder, while adhering to the correct ID naming scheme. This is especially the case when Items are being created automatically 'on-the-fly', rather than releasing to existing Items that have been manually created directly within the target Workspace.

Several default example schemes are available, utilizing the short-form code for either the folder type or the content type (refer back to the table earlier in this document for a list of codes). Using a default naming scheme, the software will automatically assign the next available unique ID, based on that scheme, having scanned the entire Workspace and identifiers of existing content.

Alternatively, should there be a need to have full, manual control over the naming of an Item, select the [NO ITEM NAMING SCHEME] entry. A unique Identifier must then be defined for an Item as part of its creation. Note that the system will not allow creation of an Item with a duplicated identifier, so manually assigning an identifier requires knowledge of which identifiers have been used.

The Item Naming Scheme of the parent folder is applied to the Unique ID for each Item created within that folder.

Irrespective of the setting for the Item Naming Scheme at the folder level, you are free to override any automatically determined ID at the Item level. Modify any such ID as required, through the Create New Item dialog.

Choosing a Scheme for Item IDs

There is an infinite number of possible name/numbering schemes that can be used for Items, the ones shown in images within the documentation are just examples. There are numerous discussions you can read about what is the best numbering scheme to use. Generally, the experts agree that a short, non-significant, numeric-only numbering scheme is best. Non-significant means that there is no information encoded into the numbering scheme, such as the product category, sub-category, location, etc, each new Item is simply issued the next number in the sequence.

The length is important because the longer the identifier, the greater the chance of a human making an error when they record or recall the Item ID. Experience and academic study have shown that data entry errors increase as the number of characters increase. Seven digits is believed to be the magic number in terms of being easily and reliably recalled by a human. Beyond a certain length errors increase at an increasing rate – at 15 characters, the error probability is close to 100%.

If it is important in your organization to create identity in the Item ID, then a composite identifier could be the answer. In this case, a simple alpha/numeric commodity prefix code is recommended. For example, consider the ID D-820-0001. Here the D in the code could denote Design, meaning this is an Item used for designs. In the next 3 digits, the first digit could denote the product category, such as Peripheral Boards, the second and third digits in the block of three could be used to denote bare boards (1X) or assemblies (2X and up). The final four digits in the Item ID are a simple, non-significant, next-in-the-queue type number.

Setting the ID for the Initial Revision of a Workspace Item

Changing from a local design paradigm to a Workspace one requires migrating existing data to a Workspace. Such data may well have passed through multiple iterations, and have revision numbering assigned that is recognized across the organization. For example, rev.3 of a Magno-Synthetic Digitizer board may well have passed out the door already, with enhancements to be delivered in rev.4. On releasing to the Workspace, having an initial revision that started back at 1 would be confusing to say the least – not just within the organization but, more importantly, to its customer base (who are expecting a later version than their current rev.3!).

To this end, Altium Designer provides the ability to manually set the ID for the initial revision of a newly-created Item in a Workspace.

Setting the Initial Revision's ID

Create the required new Item in the Workspace as usual. After creation, right-click on the Item and choose Properties – giving access to the Edit Item dialog. Click the button, to the right of the Revision ID field. The Set Initial revision Id values dialog will appear, from where you can set the ID to meet your requirements. Fields will be provided, as applicable, to modify the various levels of the ID, in accordance with the chosen Revision Naming Scheme.

To access project-related Items (PCB Fabrication Data, PCB Assembly Data, PCB Project Design) in the Explorer panel, ensure that you are viewing a project in its Classic View. You may need to manually switch over from Project View – commands are available from the menu associated to the button, at the top-right of the panel.

Uploading Data into a New Revision of an Item

Most content types support the creation of a new revision by uploading the applicable data file.

Uploading data into a new revision of an Item can be performed in a couple of ways.

Upload Menu

A file can be uploaded by right-clicking on the required Item in the Explorer panel and choosing the Upload command from the context menu. The Create New Revision dialog will appear, in which you can change Name, Description, and add release notes as required. Use the Sources region of the dialog to load the required file. This can be performed by dragging and dropping the file from Windows Explorer, onto the region. Alternatively, click the button – the Add Files dialog (a standard Windows open-type dialog) will appear. Use this to browse to, and open, the required file.

Example upload. In this case, manually specifying a 3D model file to be uploaded to a target 3D Model Item.

Once the desired file is dropped in, or selected and the Open button clicked, an entry for it will appear back in the Sources region.

For a content type that supports upload of multiple files into a revision of it, such as the Binary File, the chosen file(s) will be added, and listed, in the Sources region of the dialog. If you need to adjust the content of the list, add additional files or select and remove files (click the  button) as required. The Sources area supports selection of multiple files using standard multi-select techniques (Ctrl+Click, Shift+Click, and click-and-drag).

Proceed with the upload by clicking the OK button. As applicable to the content type, information regarding the uploaded file(s) will be presented on the Details and/or Preview aspect view tabs for the Item Revision, in the Explorer panel.

Browse the saved revision of the Item (shown here for a 3D Model Item), back in the Explorer panel. Switch to the Preview aspect view tab to see its graphical depiction (where applicable).

Drag and Drop from Windows Explorer

The relevant data file(s) can also be uploaded by dragging the selected file(s) from a source folder in your Windows Explorer and dropping onto the required target Item in the Explorer panel. The Create New Revision dialog will appear, with the dragged file listed in the Sources region. Add any Release Notes as required, then click the OK button.

For some content types, you will need to modify the Name (which will be the file name, including extension (for multiple files, entries will be separated by a semi-colon)) and Description (which will be in the format Uploaded from <FileNameandPath>, Size <FileSize>, Created on <FileCreationDate> (for multiple files, entries will be separated by a semi-colon)). For those content types that support multiple files, if you need to add additional files this can be done by clicking the button, and browsing for the file(s), or by dragging and dropping file(s) onto the Sources area. If you need to remove files, select them in the list and click the  button.

Uploading using the drag and drop method, shown here for a 3D Model.

Item Revision Naming Schemes

Main page: Defining Naming Schemes for a Workspace

To provide the greatest level of flexibility, a Workspace comes with a number of pre-defined Revision Naming Schemes, and also supports user-defined Naming Schemes. The Revision Naming Scheme is specified at the Workspace level, and applied when an Item is created. To specify the naming schemes for the Workspace to which you are currently connected:

1. Open the Data Management – Servers page of the Preferences dialog.
2. Click the Properties control, at the far right of the Active Server's entry.
3. Choose the Naming schemes command from the associated menu.

The Edit Revision Naming Schemes dialog will appear.

The revision naming scheme applied is chosen at the individual Item level, when creating an Item. Different Items can therefore have different revision naming schemes assigned to them.

Item Revision Lifecycle Definitions

Main page: Defining Lifecycle Definitions for a Workspace

A Workspace also comes with a number of pre-defined Lifecycle Definitions, and also supports user-defined Lifecycle Definitions. The Lifecycle Definition is specified at the Workspace level, and applied when an Item is created. To specify the definitions for the Workspace to which you are currently connected:

1. Open the Data Management – Servers page of the Preferences dialog.
2. Click the Properties control, at the far right of the Active Server's entry.
3. Choose the Lifecycles command from the associated menu.

The Edit Lifecycle Definitions dialog will appear.

The lifecycle definition applied is chosen at the individual Item level, when creating an Item. Different Items can therefore have different lifecycle definitions assigned to them.

Reviewing and Managing the Revision and Lifecycle State

Related page: Accessing the Detailed Item View

For a detailed view of the Revision and Lifecycle history of an Item, right-click on the Item in the Explorer panel and choose History from the menu. The Item view (labeled with the Item's ID) will open.

The Item view gives a detailed history of the release timeline of Revisions of the Item, and their Lifecycle state changes.

The view presents a textual timeline, as well as a graphical view of the revisions of that Item, and their lifecycle history. Additional detail that is presented in the view will depend on the type of Item being examined. For example, for a сomponent, the constituent model links are presented, along with parametric information. The graphical region of the view displays a column for each major Revision (where the associated revision naming scheme has more than 1 level). Within each column are the minor revisions and their lifecycle state changes.

The revisions of an Item, and their lifecycle history, can also be browsed and managed from the Explorer panel. Change to the Lifecycle aspect view tab for the selected Item-Revision. To access release data, switch to the Preview aspect view tab.

Access revision and lifecycle data for an Item directly through the Explorer panel, by selecting an Item-Revision and using the Lifecycle aspect view tab. Switch to the Preview aspect view tab to see release data for that revision of the Item.

Lifecycle Cell Commands

Right-click on a lifecycle state cell - in either the detailed Item view, or the Explorer panel - to access the following commands:

• Place <Revision> – use this command to place an instance of the currently selected Item Revision, where such placement is supported. For example, placement of a revision of a Component or Managed Sheet onto an active schematic sheet. The symbol for the component, or the managed sheet symbol, will appear floating on the cursor, ready for placement.
• View Revision Properties – use this command to access the Properties for Item Revision dialog, which provides a listing of properties associated with the parent Item of the selected Revision. Other properties are also listed, such as parameters for a component, or the parent design and configuration for a released board design Item.
• Edit Revision - this command is only available where the item revision is in the Planned state. Use it to access the Edit Revision dialog, from where you can make changes to the revision before any data is release into it.
• Delete Revision – use this command to delete the selected Item Revision. Note that you must delete Items from the 'top-down'. That is, you cannot delete a child Item Revision that is used by a parent Item; you first need to delete the parent Item.

• Promote <item to State> – use this command to promote the Item revision to its next Lifecycle State, which may also transition it to the next Lifecycle Stage.

  The available Lifecycle States are determined by the Lifecycle Definition that applies to the type of Item. The Component Lifecycle Definition would typically apply to Components, for example.
• Rollback <item to previous State> – revert the Item revision's Lifecycle state back to its previously assigned state. Say, from Production back to Prototype when the Component Lifecycle Definition applies.
• Make <item unusable> / Abandon <item> – use this command to change the Item revision Lifecycle State to Abandoned, Obsolete, Deprecated, etc, rather than promoting it to the next higher level. This would be an Obsolete state for the Component Lifecycle definition, for example.
• Establish Planned Revision - <level for Item ID> – use this command to create the next revision level for the Item, which will be in the initial Planned Lifecycle state. The Create Revision dialog will open that provides all controls necessary to fully define the Item revision.
• Establish Planned Item – use this command to create a new Item based on the currently selected Item-Revision, in the initial Planned Lifecycle state. The Create New Item dialog will open ( with the selected Item-Revision set as an Ancestor Revision) that provides all controls necessary to fully define the Item.

State Change and Release Notes

Enhancing the audit trail for content in a Workspace, Altium Designer provides the ability to enter notes when changing the lifecycle state of an Item-Revision and, for many content types, when releasing the source data into planned revisions in the Workspace.

State Change Notes

When changing the lifecycle state for an Item-Revision in a Workspace, use the State change note region of the subsequent state change dialog to enter a relevant note for that change.

Adding a note to explain the change in an Item-Revision's lifecycle state.

Release Notes

When releasing source data into a new planned revision of an Item in a Workspace, use the Release notes region of the subsequent Create Revision dialog to enter a relevant note for that release. This facility is available when re-releasing any Item type that supports the Direct Editing paradigm.

An example of adding a release note during the re-release of a layerstack to a target Workspace.

Viewing the Notes Associated with Revisions of an Item

The notes added for any revision of an Item can be viewed in the following places:

• Detailed Item view – view the associated release note, and notes for revision state changes, in the Note column within the Timeline region. For each state in a revision's life, the applicable note (if added) can also be seen within the graphical view of the revision's lifecycle.
• Explorer panel – switch to the Lifecycle aspect view tab for a selected Item-Revision. For each state in a revision's life, the applicable note (if added) can be seen in the graphical depiction of the revision's lifecycle. In addition, view the associated release note, and note for latest revision state change, in the Note column, within the main Item region of the panel (you may need to enable the display of this column).

Viewing the notes associated with revisions of a component.

Soft Deletion

When connected to a Workspace, flexible functionality is available for removing an Item directly from within Altium Designer, from the Explorer panel. Right-click on the Item's entry in the panel and choose the Delete Item command from the context menu. The Delete Items dialog will appear, in which to confirm the deletion. The action is actually a 'soft delete', whereby the Item will be moved into the Trash area of the Workspace. The Trash is essentially a recycle bin into which any content within your Workspace can be moved (through a soft delete action). It is isolated from the rest of the Workspace.

Soft deletion of a component, along with its associated symbol and footprint. All Items will be moved to the Workspace's Trash area.

To proceed with the deletion, click the button. The item will be removed and a Deletion Summary dialog will confirm successful deletion. If there was an issue with deletion, this will be flagged to you.

All items deleted in this manner can be found on the Trash page of the Workspace's browser interface. Note that you can only view items that you have personally soft deleted. Administrators will be able to see the full content of the Trash page – so all items that have been soft deleted.

Things to consider in relation to a soft-deleted item:

• The item will not be available from your design software, or from within the Web interface.

• Anywhere the item was being used will reflect that the item has been deleted.

  
  Example of a soft-deleted component being flagged as such elsewhere in the software.

• An item can be restored, or permanently deleted from the Trash page, provided you have editing rights. Permanent deletion is only possible provided it is not being used by a parent item.

  For a project, only the owner or an administrator can permanently delete or restore. For more information on soft deletion of a project from within the Workspace's browser interface, see Deleting a Project (Altium 365 Workspace, Enterprise Server Workspace).