Managing Content Structure & Access in an Altium 365 Workspace

 

Note:

Altium is upgrading the sharing permissions inheritance system in all Altium 365 Workspaces. This will greatly improve the ability to manage sharing permissions throughout the Workspace folder hierarchy, including its stored Projects and other design items.

The update is being rolled to Altium customer Workspaces over a period of time, after which the new permission management capabilities will be available. You can quickly check if your Workspace has been updated by inspecting the options included in both the Share dialog in the Explorer page (see example) and the Projects view in the Settings page (see example).

The below content applies to Workspaces that have been upgraded to the new sharing permission system hierarchy. If your Workspace is yet to be upgraded, the previous page content applies to your Workspace and is available within the collapsible section below.

Content structure and access management for a Workspace is performed by an Administrator from the Admin – Explorer page of a Workspace's browser interface. From here, you can:

  • Browse the folders and Items within the Workspace. You are able to create and edit folders and so build the structure of the Workspace, without having to be connected to that Workspace through Altium Designer.
  • Define folder-level and Item-level sharing – controlling who is able to see what content is in the Workspace and, at the folder level, whether other users can simply view a folder and its content, or also edit it (effectively releasing/committing/uploading design data into it).
  • Download content.

The interface itself presents with a look and feel that is similar to that of Altium Designer's Explorer panel when accessing Workspace content. A strong degree of consistency between the two interfaces means that if you are familiar with the panel, you'll be able to use this browser-based variant without difficulty.

Access content in your Workspace through the Admin – Explorer area of the browser interface.Access content in your Workspace through the Admin – Explorer area of the browser interface.

While the browser interface is accessible from any location you have an internet connection, if you are directly connected to the Workspace through Altium Designer, the Explorer panel offers a more advanced set of Workspace management features.

Managing Structure

Various commands are available to manage the overall folder structure in a Workspace, including the ability to create top-level folders and sub-folders, and edit, share and remove folders.

Controls for managing the folder structure can be found on the right-click menu (with the mouse cursor over an existing folder entry). With the exception of adding a top-level folder, commands act on the currently selected folder in the structure.

Access folder structure management commands from the right-click menu.Access folder structure management commands from the right-click menu.

You cannot move existing folders (or items for that matter) within the structure. This can be performed only in the Workspace Projects page or through Altium Designer's Explorer panel interface, and provided you have the appropriate privileges to do so.
You can soft-delete folders and Items from the Admin – Explorer page – sending them to the isolated Trash area for the Workspace. Entities in the Trash can then be permanently deleted, or restored, as required.

Sharing Folders and Items

Related page: Controlling Access to Server Content (Altium Designer page)

The Altium 365 Workspace folder structure features an advanced permission inheritance scheme based on the propagation of sharing permissions from Parent to Child objects – the latter being a folder or design items such as Projects, Components, BOM files, Templates, and so on. This arrangement simplifies the process of organizing a Workspace folder structure and its sharing permissions to match the access requirements of Company Users and Groups of users.

A Workspace provides the following sharing capabilities:

  • Folder-level Sharing – providing the ability to control who is able to see what content in the Workspace by sharing server folders. This allows control over whether other users can simply view a folder and its content, or also edit it (effectively releasing/committing/uploading design data into it). A single Workspace can be partitioned into various effective 'zones' of content but with controlled folder-level permissions, the content can be made selectively visible, or hidden, as required, giving the right people, the right access, to the right data.
  • Item-level Sharing – providing the ability to control who is able to see which Items in a shared folder. Think of this as a finer level of sharing, in contrast to the coarser level of sharing provided through folder access control. Provided a user has access to the folder itself, they will then be able to view/edit (as permitted) Items within that folder that are shared with them.
When specifying the sharing permissions for an item object – such as a Component, Template, etc – the item settings will also apply to its constituent Revisions. You can add/remove permissions from individual Revisions, but permissions are not inherited within the Revision hierarchy itself.

The above sharing capabilities will adhere to the Workspace permission inheritance scheme. In the simplest sense, permissions applied to a folder will propagate down the folder hierarchy through the parent-child relationships – from folder to sub-folder, down the chain.

This permission inheritance structure is maintained (unless specifically disrupted by a ‘detached’ folder/object) when folders are added to the hierarchy, and also when permissions are added within the hierarchy.  Where additional permissions are applied to a folder that is not the top-level folder – it is within the hierarchy – they will be inherited down the hierarchy from this level, without disrupting the existing permissions. Note that the same inheritance behavior applies to the removal of permissions.

Javascript ID: C

Add Edit rights (Read/Write) for the Engineers user Group to the top folder in the A-B-C folder hierarchy.

The new permission entry (Engineers Read/Write) is automatically applied to all folders in the hierarchy through parent-child permission inheritance.

Add Read-only rights (Read) for the Librarians user Group to Folder B hierarchy – its permission set will be 'extended’ by this addition

The new permission entry (Librarians Read) is applied to the B folder and inherited by all folders below it in the hierarchy.

A design Project (or other item type) is created or uploaded into Folder C. It will inherit the share permissions from Folder C.

Extend the permission set of Folder C by adding read-only rights (Read) for the Managers Group.

The added Managers Read permission is inherited by the design Project.  Note that share permissions for Design and Managed BOM Projects are managed through the Share window dialog in the Workspace Projects page.

Those with administrator-level privileges (members of the Administrators group) will be able to see and manage all folders and Items. For a non-administrative user of the Workspace, only those folders and Items that have been shared (or they have created) – that is, the user has permission to access – will be available when the user connects to that Workspace.

Sharing controls are accessed by right-clicking over the entry for the folder (or Item) and using the Share Folder (or Share Item) command from the context menu. The Share window will appear, from where access permissions for the folder/Item can be modified as required.

Javascript ID: F

Share permissions configured for the Team 1 project folder (US team). Projects within this folder inherit these permissions – adding to the inherent administrator and owner write permissions.

Share permissions for a project folder added by a user, which inherits its permission from the parent folder (Team 1). The parent folder was created by a different user (Harold Smith) who ‘owns’ that folder, so write access to the new folder is granted for this user also.

Share permissions configured for the Team 2 project folder (EU team). Projects within this folder inherit these permissions – adding to the inherent administrator and owner write permissions.

Share permissions for a template item, as inherited from the parent Component Templates folder.

Things to be aware of:

  • In terms of permissions, a user/group has Read/Write access when the Can Write (Edit) option is enabled. If this option is disabled, they have Read (View) access only.
  • To remove an existing user/group from having shared access to a folder/item, click the associated Remove control ().
  • By default, a folder/item will only be available to its owner (initially its creator) and all members of the Administrators group. These permissions are inherent and do not need to be explicitly added.
  • To allow all users of the Workspace to see a folder/item, use the Add Anyone control. Be aware that doing so will, by default, grant Read/Write access to all Workspace members. If you want to lock access down to a specific set of users and/or groups, you must remove the Anyone entity.
  • Unlike other items, a design project item's sharing permissions cannot be managed through the Explorer page. They are instead specified in the Share dialog window accessed from the Projects page. See the Workspace Projects page for detailed information.
  • Folders also can be added and removed in the Workspace Projects page.
If an Item in a server folder is shared with a given user but the folder itself is not, then the user will not be able to 'see' (and therefore directly access) that Item when browsing the Workspace content.

Permission Inheritance Continuity

The inheritance of sharing permissions in the Workspace folder hierarchy, as described above, is maintained at its full depth unless interrupted by mismatched permissions between a parent folder and its child folder. In short, a parent folder’s permission set must be present in its child folder to maintain inheritance continuity – the child is otherwise ‘detached’ from its parent, in permission inheritance terms.

A child folder that is detached from its parent will no longer inherit any changed/updated permissions from its parent. While the folder hierarchy permission inheritance is effectively broken at this point, it remains contiguous below the detached point. The full depth of folder permission inheritance will be restored if either the parent or child folder permissions are changed so that the parent permissions are present in the child again – the child is then ‘re-attached’ to its parent.

Javascript ID: D

Remove the Librarians Read permission from Folder C, which is part of folder hierarchy A-D with contiguous permission inheritance.

Because the permission set in Folder B (parent) is no longer fully included in Folder C (child), the permission inheritance is disconnected at this point. Folder C is ‘detached’ from Folder B.

Add Manager Read permission to Folder A.

Folder B inherits the new permission, but Folder C (and its descendant folders) does not because its permission inheritance is detached from Folder B.

Remove Librarians Read permission from Folder A.

Folder B again inherits the permission change (removal) and its detached child, Folder C, does not.

Add Mechanical Read permission to Folder C.

The added permission is inherited by Folder D because parent-child inheritance is maintained below the Folder C detachment point.

Add Managers Read permission to Folder C.

Folder C now includes the permission set of its parent, Folder B, so it is ‘re-attached’ to Folder B. Permission inheritance is again contiguous through the full folder hierarchy. Note that removing the Managers Read entry from Folder A (inherited by Folder B) would also have caused the reattachment because Folder C would then include the permission set of the Folder B parent.

Points of note:

  • If a parent folder and its child folder include a Read permission and the matching child permission is changed to Read/Write, it will remain attached to its parent because it includes the matching Read capability of the parent – the Read capability is common to both.
  • If a parent folder and its child folder include a Read/Write permission and the matching child permission is changed to Read, it will be detached from its parent because it no longer includes the matching Write capability of the parent.
  • When adding a permission to a folder it will effectively overwrite the same permission in a child folder if the child is at a lower access level. For example, if the Librarians Read/Write permission is added to a folder and its child folder has an existing Librarians Read entry, this will be overwritten/upgraded to a Librarians Read/Write entry.
  • Conversely, when adding a permission to a folder it will not affect the same permission in a child folder if the child has a higher access level. For example, if the Librarians Read permission is added to a folder and its child folder has an existing Librarians Read/Write entry, this will not be changed (downgraded) to a Read level entry – it remains at its existing permission level.
Note that the permission inheritance logic described here also applies to projects (Design and Managed BOM projects). A project is always a child of a parent folder and will inherit permissions and become detached/re-attached in the same way as a child folder. The difference is that project permissions are edited through the Share window in the Workspace Projects page.

Moving Folders

Workspace folders can be moved to any other location in the folder structure through the Projects page (see Workspace Projects page) or the Explorer pane in Altium Designer (see Organizing Your Workspace).

The way in which a moved folder’s share permissions are determined depends on its relationship to its original parent folder:

  • When a folder is part of a hierarchy with a contiguous permission structure (it is attached to its parent folder), then moving that folder into another folder will cause it to:
    • inherit the permission set from its new parent folder.
    • lose its original inherited permissions.
      • * A folder/project’s 'inherited' permissions are those in common with its parent – they have been inherited.
    • retain its previous extended permissions.
      • * A folder/project’s 'extended' permissions are those not in common with its parent – they have been specifically added to extend access.

In short, the old parent’s permissions are replaced by the new parent’s permissions, but any that were added will move with the folder.

  • When a folder is disconnected from the permission structure hierarchy (it is detached from its parent folder), then moving that folder into another folder will cause it to:
    • inherit the permission set from its new parent folder.
    • retain its original permissions.

The moved folder (child) will be attached to its parent because it now includes the parent's permissions.

In both of the above cases, if any permissions are in common – those transferred compared to the new parent folder permissions – then the highest available permission level (Read/Write over Read) will be adopted.

Javascript ID: E

In this example, folders A-B-C are in a hierarchy that includes inherited Engineers Read/Write permissions. Folder C permissions have been extended by the addition of Contractors Read. Alternatively, an individual User could have been added.

Moving an 'attached' folder. Move folder C into Folder D, which features a different permission set.

The moved Folder C is now a child of Folder D and will inherit the parent's Mechanical Read permission. Folder C also will lose its original inherited permissions (Engineers Read/Write) but retain its original extended permissions (Contractors Read).

Moving a 'detached' folder. The permissions for Folder C are modified, which causes it to ‘detach’ (in permission inheritance terms) from Folder D because it no longer includes the parent’s permission set.

Move folder C into Folder E, which features a different permission set. Note that Folder C is detached at this point.

The moved Folder C will retain its original permission set and also inherit the permissions of its new parent, Folder E.
Since both the retained and parent permissions include different access levels (Read and Read/Write) of the Managers group permission, the higher access level is adopted by Folder C – Managers Read/Write. Note that Folder C is now attached to the permissions of Folder E.

Note that the permission inheritance logic described here also applies to moving projects (Design and Managed BOM projects). A project is always a child of a parent folder and will inherit its permissions and become detached/re-attached in the same way as a child folder. The difference between the two is that project permissions are edited through the Share window in the Workspace Projects page.

Managing Project Creation Permissions

With the default Workspace settings, projects created or uploaded by Workspace members are stored in the Projects folder and directly accessed through the Projects page. This simple arrangement is convenient for users, but allows any member of the Workspace to create projects in this primary (top-level) location. To implement advanced control over who can create projects in the Projects folder (or additional sub-folders) Workspace administrators can specify the project folder sharing permissions through the Explorer page, or in Altium Designer, the Explorer panel.

As outlined above, folder permissions are accessed in the Workspace Explorer page from the Share Folder option of a folder entry’s right-click context menu. The Projects folder access can be changed by setting the default permission (Anyone) to read-only (deselecting Can Write) or by removing it entirely, and then adding access permissions for specific users (Add User) or groups of users (Add Role) as required.

Javascript ID: A3

The updated write permissions will determine which Workspace members can create (or upload) projects to the Projects folder – in this example, only those who are members of the Managers group. The permission constraints will also apply to users creating a new project in Altium Designer.

When a user without write access to the Projects folder (or some other folder that has been specified as the default storage location) performs a project Create or Upload, the system will automatically create a user-specific Personal Folder structure for storing the new project. This appears as a top-level folder based on the member’s email address, with a My Projects sub-folder that stores that user’s projects. The folder structure/hierarchy is available only to the signed-in user (and administrators) and is not visible to other users.

  • If the user performs a project Create or Upload within a folder they have write access to, then the project is stored in that folder. Projects are otherwise stored in the user's My Projects folder.
  • For the example shown here (above), projects created by users who are members of the Managers group will be included in the Projects folder as normal because they have full Edit rights to the Projects folder.
  • The user will have access to any projects residing in the Projects folder (or elsewhere) as allowed by the project sharing permissions. if the project is shared with all Workspace members, the user's Group, or their username, then these projects will appear in the top-level view of the Projects page.
Javascript ID: B

The personal ‘home’ folder functionality provides controlled isolation between Workspace member projects and from other project folders – users also can create new project folders within this structure. Note that if a user then shares the project more widely, such as to all Workspace members, that project will appear in the main Projects folder for other users.

From a Workspace administrator’s perspective, the member’s personal folders are collected under a top-level Home folder, as evident in the Projects page and the Explorer page folder hierarchy – and also the Altium Designer Explorer pane folder tree.

Javascript ID: 365-PersonalFoldersAdmin

Downloading an Item Revision

To download data from the interface, click the Download control () to the right of the entry for an Item Revision.

Using the control at the parent Item level will download data for the latest revision of that Item.

Navigating the Workspace Structure

You can navigate the content in a Workspace – through its browser interface – in a couple of ways, as highlighted in the following image and described thereafter.

Javascript ID: W365_NavEx_u51

The ways in which to navigate Workspace content through the browser interface.

The results of an example search.

  1. By clicking on a folder name whose contents you wish to peruse.
  2. Using the search feature. Enter a keyword based on an Item's ID, Comment, or Description and press Enter or click the magnifying glass icon (). The entire Workspace will be scanned and results of the search listed, in terms of matching Items.
After a search, you can return to the normal view of the Workspace content by clicking the Admin – Explorer page entry again, in the browser interface's navigation tree on the far left. Alternatively, clear the search field and press Enter.

Additional Features

The following additional features can be found when browsing content through the Workspace's browser interface:

  • Navigate – this command, found on the right-click context menu for an Item, is used to quickly take you to that Item in Altium Designer's Explorer panel. Altium Designer will be opened in order to do this (you'll be prompted if you want to open X2.exe – Altium Designer's source executable).
If Altium Designer is already running, that instance will be used.
  • Full item info – this command, found on the right-click context menu for an Item Revision, is used to present a view listing all detail for that Revision. In effect, it is simply a view that includes all of the various aspect views available for that Item Revision (except Summary).
Using the command at the parent Item level will present details for the latest revision of that Item.
  • Follow/UnFollow – use the Follow command, found on the right-click context menu for a folder of Type Components, to follow the folder. Any activity within the folder being followed (component creation, release, revision state change, or deletion) will be flagged through an email notification sent out from the Workspace (provided email notifications have been enabled for the Workspace by an Administrator). Use the UnFollow command to stop following component activity within that folder.
  • Remove Folder – use this command, found on the right-click menu for a folder, to move that folder and all its content (sub-folders and Items therein) to the isolated Trash area for the Workspace. Entities in the Trash can then be permanently deleted, or restored, as required. If removing a project folder, any associated releases and manufacturing packages will also be moved to the Trash.
  • Remove Item – use this command, found on the right-click menu for an Item, to move that Item to the isolated Trash area for the Workspace. Entities in the Trash can then be permanently deleted, or restored, as required. If removing a Component Item, you also have the opportunity to move its associated models to the Trash at the same time. Note that these can only be deleted if they are not being used elsewhere (by one or more other components).

 

If you find an issue, select the text/image and pressCtrl + Enterto send us your feedback.
참고

사용가능한 기능들은 Altium 제품 레벨에 따라 다릅니다. 논의하셨던 기능이 소프트웨어에 없다면, Altium 영업에 문의하셔서 자세한 내용을 확인해주세요.

콘텐츠