Managing Content Structure & Access

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.

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.

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 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, which allows the content to 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.

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 affecting 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.

In the Explorer page, sharing controls are accessed by right-clicking over the navigation tree 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. Owners and Administrators have Read/Write (View/Edit) permissions.

• 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.

For Administrators or a folder's owner/creator, project folder permissions also can be accessed and changed from the Share option in the Workspace Projects page. Select a folder entry and then the upper button or the Share option from the entry’s menu to access the Share Item window. The window’s interface and functionality operate in the same manner as when sharing a Project – this includes the ability to change the Item (folder) Owner.

In the below example, the default Project folder settings (write access for all Workspace members) is constrained to write access only for Managers by changing the Workspace Members permissions to Can View (or No Access), adding Managers to the Share Item With field, and then setting its associated share option to Can Edit.

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, in permissions inheritance terms.

❯ ❮ Javascript ID: D

Removing 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 (its child), the permission inheritance is disconnected at this point. Folder C is ‘detached’ from Folder B. Adding 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. Removing Librarians Read permission from Folder A. Folder B again inherits the permission change (removal) and its detached child, Folder C, does not. Adding 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. Adding 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 (permission inheritance is maintained) 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 (permission inheritance is lost) 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.

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. Folder C will be moved 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. Folder C will be moved 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.

Managing Project Creation Permissions

With the default Workspace settings, projects created or uploaded by Workspace members are available with write access to all users, 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 accessible projects in this primary (top-level) location. To implement advanced control over who can create (and access) 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 the example shown above, only those who are members of the Managers group. The permission constraints will also apply to users creating a new project in Altium Designer.

Project Creation Without Folder Write Access

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 owned by and available to the signed-in user only (and administrators), and is not visible to other users.

❯ ❮ Javascript ID: B

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.

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.

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).

• 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).

• 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).