Gestion de la structure du contenu et des accès

La structure du contenu et la gestion des accès d’un Workspace peuvent être effectuées à la fois depuis la page Admin – Explorer (par un administrateur) ou depuis la page Projects principale (par un membre du Workspace disposant de droits suffisants). Les commandes et fonctionnalités de ces pages vous permettent de :

  • Parcourir les dossiers et les éléments du Workspace. Vous pouvez créer, modifier et supprimer des dossiers, et ainsi construire la structure du Workspace. Les dossiers et éléments supprimés sont envoyés dans la Corbeille, où ils peuvent être supprimés définitivement ou restaurés.

  • Définir le partage au niveau des dossiers et au niveau des éléments. Cela contrôle qui peut voir quel contenu dans le Workspace et, au niveau du dossier, si d’autres utilisateurs peuvent simplement consulter un dossier et son contenu, ou également le modifier (autrement dit y publier/valider/téléverser des données de conception).

  • Spécifier si un dossier ou un élément (tel qu’un projet) hérite de ses autorisations de partage de son dossier parent. Il s’agit de la condition par défaut.

En termes de structure du contenu et de gestion, les interfaces des pages Projects et Explorer diffèrent en matière de capacités et de commodité :

  • La page Projects du Workspace offre une approche simple de la gestion des dossiers et des éléments de projet, accessible aux administrateurs, aux propriétaires de projet/élément et aux autres utilisateurs disposant de droits de modification suffisants.
    Remarque : avec cette interface, vous ne pouvez pas modifier ni définir les autorisations de partage du dossier Projects de niveau supérieur (par défaut), ni créer un autre dossier de niveau supérieur.

    La majorité des tâches de gestion de la structure et des autorisations du Workspace peut être effectuée à partir des commandes de la page Projects.La majorité des tâches de gestion de la structure et des autorisations du Workspace peut être effectuée à partir des commandes de la page Projects.

  • La page Explorer du Workspace, similaire au panneau Altium Designer Explorer et accessible uniquement aux administrateurs, fournit un accès de gestion à tous les dossiers et éléments, y compris les données de Release des projets, les composants, le contenu géré, etc.
    Remarque : avec cette interface, vous ne pouvez pas partager un projet de conception ni déplacer des dossiers et des éléments.

    La page Explorer fournit un contrôle détaillé de la structure du Workspace et des paramètres d’autorisation, y compris l’accès au dossier Projects de niveau supérieur.La page Explorer fournit un contrôle détaillé de la structure du Workspace et des paramètres d’autorisation, y compris l’accès au dossier Projects de niveau supérieur.

Partage des dossiers et des éléments

Related page: Contrôle de l’accès au contenu du serveur (page Altium Designer)

La structure de dossiers du Workspace Altium 365 dispose d’un schéma avancé d’héritage des autorisations basé sur la propagation des autorisations de partage des objets Parent vers les objets Enfant, ces derniers étant un dossier ou des éléments de conception tels que des projets, composants, fichiers BOM, modèles, etc. Cette organisation simplifie le processus d’organisation de la structure des dossiers d’un Workspace et de ses autorisations de partage afin de répondre aux exigences d’accès des utilisateurs de l’entreprise et des groupes d’utilisateurs.

Un Workspace offre les capacités de partage suivantes :

  • Folder-level Sharing – permet de contrôler qui peut voir quel contenu dans le Workspace en partageant des dossiers. Cela permet de décider si d’autres utilisateurs peuvent simplement consulter un dossier et son contenu, ou aussi le modifier (autrement dit y publier/valider/téléverser des données de conception). Un même Workspace peut être partitionné en différentes « zones » de contenu effectives, avec des autorisations contrôlées au niveau des dossiers, ce qui permet de rendre le contenu sélectivement visible ou masqué selon les besoins, afin de donner aux bonnes personnes le bon accès aux bonnes données.

  • Item-level Sharing – permet de contrôler qui peut voir et accéder à quels éléments dans un dossier partagé. Ce niveau de partage plus spécifique vous permet de remplacer (ou de compléter) l’ensemble d’autorisations qu’un élément a hérité de son dossier parent. À condition qu’un utilisateur ait accès au dossier lui-même, il pourra alors consulter/modifier (selon les autorisations) les éléments de ce dossier qui sont partagés avec lui.

Lors de la spécification des autorisations de partage pour un objet élément (tel qu’un composant, un modèle, etc.) à l’aide de l’interface Explorer du Workspace, les paramètres de partage de l’élément s’appliqueront également à ses révisions constitutives. Vous pouvez ajouter/supprimer des autorisations pour des révisions individuelles dans cette hiérarchie, mais la modification d’autorisation ne se propagera pas dans la hiérarchie elle-même : elle n’est pas héritée par les révisions situées en dessous dans la hiérarchie.

En interne, l’accès aux objets du Workspace est déterminé par une Access Control Listliste de contrôle d’accès (ACL) hiérarchique qui détermine les autorisations associées aux dossiers, projets et éléments. Cette liste précise qui a accès à cet objet et s’il peut être modifié. Par exemple, si les paramètres de partage d’un projet particulier incluent des autorisations View (lecture seule) pour Librarians, alors il est accessible aux membres du groupe Librarians, mais ne peut pas être modifié, déplacé ou supprimé (ni repartagé) par ces membres, sauf s’ils sont administrateurs ou propriétaires du projet.

Les capacités de partage ci-dessus respectent le schéma d’héritage des autorisations du Workspace. Dans sa forme la plus simple, les autorisations appliquées à un dossier se propagent vers le bas dans la hiérarchie des dossiers via les relations parent-enfant, de dossier à sous-dossier, tout au long de la chaîne.

Cette structure d’héritage des autorisations est maintenue (sauf si elle est volontairement désactivée à un certain point de la hiérarchie) lors de l’ajout de dossiers dans la hiérarchie, ainsi que lors de l’ajout d’autorisations au sein de la hiérarchie. Lorsque des autorisations supplémentaires sont appliquées à un dossier qui n’est pas le dossier de niveau supérieur — donc à l’intérieur de la hiérarchie — elles seront héritées vers le bas à partir de ce niveau, sans affecter les autorisations existantes.

Ajoutez des droits de modification (Read/Write) pour le groupe d’utilisateurs Engineers au dossier supérieur dans la hiérarchie de dossiers A-B-C.

La nouvelle entrée d’autorisation (Engineers Read/Write) est automatiquement appliquée à tous les dossiers de la hiérarchie via l’héritage des autorisations parent-enfant.

Ajoutez des droits en lecture seule (Read) pour le groupe d’utilisateurs Librarians à la hiérarchie du dossier B — son ensemble d’autorisations sera « étendu » par cet ajout

La nouvelle entrée d’autorisation (Librarians Read) est appliquée au dossier B et héritée par tous les dossiers situés en dessous de lui dans la hiérarchie.

Un projet de conception (ou un autre type d’élément) est créé ou téléversé dans le dossier C. Il héritera des autorisations de partage du dossier C.

Étendez l’ensemble d’autorisations du dossier C en ajoutant des droits en lecture seule (Read) pour le Managers Group.

L’autorisation Managers Read ajoutée est héritée par le projet de conception. Notez que les autorisations de partage pour les projets Design et Managed BOM sont gérées via la boîte de dialogue Sharewindow dans la page Workspace Projects.

 

Les personnes disposant de privilèges de niveau administrateur (membres du groupe Administrators) pourront voir et gérer tous les dossiers et éléments. Un utilisateur du Workspace non administrateur ne peut accéder qu’aux dossiers et éléments qu’il a créés (dont il est le « propriétaire »), ou à ceux qui ont été partagés avec lui via des autorisations appropriées.

Dans la page Projects du Workspace, les autorisations des dossiers de projet peuvent être consultées et modifiées à partir des options de l’interface Share. Sélectionnez une entrée de dossier, puis le bouton supérieur ou l’option Share du menu de l’entrée pour accéder à la fenêtre Share Item. Notez que :

  • par défaut — lorsqu’un Workspace est activé pour la première fois — le dossier Projects de niveau supérieur n’est pas accessible dans la page Projects, mais il devient disponible si d’autres dossiers de niveau supérieur sont créés. L’interface de la page Explorer peut toujours accéder au dossier Projects.

  • l’interface et les fonctionnalités de la fenêtre fonctionnent de la même manière lors du partage d’un projet — cela inclut la possibilité de changer le propriétaire de l’élément (dossier).

Autorisations de partage configurées pour le dossier de projet Team 1 — accès complet pour l’équipe US Engineering et les ECAD Managers en consultation seule. Les projets dans ce dossier héritent de ces autorisations, en plus des autorisations d’écriture inhérentes aux administrateurs et aux propriétaires.

Autorisations de partage pour un dossier de projet ajouté par un utilisateur, qui héritera de ses autorisations du dossier parent (Team 1). Le dossier parent a été créé par un autre utilisateur (Harold Smith) qui « possède » ce dossier, de sorte que l’accès en écriture au nouveau dossier est également accordé à cet utilisateur.

Autorisations de partage configurées pour le dossier de projet Team 2 — accès complet pour l’équipe EU Engineering et les ECAD Managers en consultation seule. Les projets dans ce dossier héritent de ces autorisations, en plus des autorisations d’écriture inhérentes aux administrateurs et aux propriétaires.

 

Dans la page Explorer, les contrôles de partage sont accessibles en cliquant avec le bouton droit sur l’entrée de l’arborescence de navigation du dossier (ou de l’élément) et en utilisant la commande Share Folder (ou Share Item) dans le menu contextuel. La fenêtre Share apparaît, depuis laquelle les autorisations d’accès au dossier/à l’élément peuvent être modifiées selon les besoins.

Autorisations de partage configurées pour le dossier de projet Team 1 — accès complet pour l’équipe US Engineering et les ECAD Managers en consultation seule. Les projets dans ce dossier héritent de ces autorisations, en plus des autorisations d’écriture inhérentes aux administrateurs et aux propriétaires.

Autorisations de partage pour un dossier de projet ajouté par un utilisateur, qui héritera de ses autorisations du dossier parent (Team 1). Le dossier parent a été créé par un autre utilisateur (Harold Smith) qui « possède » ce dossier, de sorte que l’accès en écriture au nouveau dossier est également accordé à cet utilisateur.

Autorisations de partage configurées pour le dossier de projet Team 2 — accès complet pour l’équipe EU Engineering et les ECAD Managers en consultation seule. Les projets dans ce dossier héritent de ces autorisations, en plus des autorisations d’écriture inhérentes aux administrateurs et aux propriétaires.

Autorisations de partage pour un élément de modèle, telles qu’héritées du dossier parent Component Templates.

 

Points à connaître :

  • En termes d’autorisations, un utilisateur/groupe dispose d’un accès lecture/écriture lorsque l’option Can Write (Edit) est activée. Si cette option est désactivée, il dispose uniquement d’un accès en lecture (consultation).

    Activer l’accès Edit à un dossier/élément pour un utilisateur/groupe revient effectivement à ajouter une autre autorisation à son ensemble d’autorisations (ACL), et remettre cet accès sur View revient effectivement à supprimer une autorisation de cet ensemble.

  • En termes de sélections des autorisations de partage dans l’interface utilisateur :

    • Une option Can Write cochée (lecture/écriture) dans la page Explorer équivaut à Can Edit sélectionné dans la page Projects.

    • Une option Can Write décochée (lecture seule) dans la page Explorer équivaut à Can View sélectionné dans la page Projects.

  • Pour supprimer l’accès partagé à un dossier/élément pour un utilisateur/groupe existant :

    • dans la page Projects, sélectionnez l’option Remove de la vignette utilisateur/groupe dans la fenêtre Share Item.

    • dans la page Explorer, cliquez sur le contrôle Remove associé à l’entrée utilisateur/groupe () dans la fenêtre Share.

  • Par défaut, un dossier/élément n’est accessible qu’à son propriétaire (initialement son créateur) et à tous les membres du groupe Administrators. Ces autorisations sont inhérentes et n’ont pas besoin d’être ajoutées explicitement. Owners et Administrators disposent des autorisations Lecture/Écriture (Afficher/Modifier).

  • Pour permettre à tous les utilisateurs de l’Espace de travail de voir un dossier/élément :

    • dans la fenêtre Share Item de la page Projects, définissez l’option d’accès de la vignette Workspace Members sur Can View, ou sur Can Edit pour un accès complet en écriture.

    • dans la fenêtre Share de la page Explorer, sélectionnez le contrôle Add Workspace Members et décochez son option Can Write, ou laissez-la cochée pour un accès complet en écriture.

      Sachez qu’en procédant ainsi, vous accorderez potentiellement un accès Lecture/Écriture à tous les membres de l’Espace de travail. Si vous souhaitez restreindre l’accès à un ensemble spécifique d’utilisateurs et/ou de groupes, vous devez définir Workspace Members pour No access (page Projects) ou supprimer le Workspace Members entry (page Explorer).

  • Contrairement aux autres éléments, les autorisations de partage d’un projet de conception ne peuvent pas être gérées via la page Explorer. Elles sont définies à la place dans la fenêtre Share Item, accessible depuis la page Projects. Consultez la page Projets de l’Espace de travail pour des informations détaillées.

Restrictions de partage contrôlées par l’héritage

Certains niveaux d’accès utilisateur, tels que Can View ou No access dans la fenêtre Share Item d’un dossier, peuvent être indisponibles à la sélection car ils contrediraient (rétrograderaient) l’ensemble d’autorisations hérité de son dossier parent. Par défaut, les autorisations de partage du dossier accordent un accès complet en écriture à tous les utilisateurs – Workspace Members Can Edit comme indiqué dans la fenêtre Share Item, ou Workspace Members peut Write comme indiqué dans la fenêtre Share de la page Explorer.

Dans ce cas par défaut, par exemple, les options permettant de rétrograder les autorisations héritées d’un dossier (de Workspace Members Edit vers Workspace Members View ou No Access) sont désactivées afin d’éviter une rupture involontaire dans la structure hiérarchique des autorisations. Notez que vous pouvez toujours promouvoir (augmenter) le niveau d’accès au partage, car cela « ajoute » simplement à l’ensemble d’autorisations existant hérité du dossier parent.

Pour déconnecter intentionnellement l’héritage des autorisations Parent vers Enfant pour ce dossier, afin qu’un niveau d’accès différent (réduit) puisse être appliqué, décochez l’option Inherit parent folder permissions dans la section Advanced Settings de la fenêtre Share Item. Le dossier n’héritant alors plus des autorisations de son parent, ses propres autorisations d’accès peuvent être modifiées sans restriction. Consultez la section ci-dessous pour plus d’informations.

L’option Inherit permissions from parent folder est initialement activée par défaut, et l’est toujours pour les dossiers nouvellement créés.

De même, lorsque vous modifiez les autorisations de partage d’un dossier via la page Explorateur de l’Espace de travail, il vous est impossible de rétrograder des autorisations héritées du dossier parent. Décochez l’option Inherit permissions from parent de la fenêtre Share pour déconnecter intentionnellement l’héritage des autorisations de son dossier parent (Projects dans ce cas).

Outre les dossiers et les projets, le système d’héritage des autorisations s’applique également aux éléments (tels que les composants) et à leurs révisions constitutives. Ils présentent le même comportement d’héritage des autorisations et incluent l’option permettant d’activer/désactiver cet héritage (sous Advanced Settings dans la boîte de dialogue Share de la page Explorer).

Forcer l’héritage des autorisations

Les options Advanced Sharing dans les pages Projects et Admin – Explorer de l’Espace de travail offrent une commande supplémentaire Enforce inheritance for all child items qui activera Inherit parent folder permissions pour tous les sous-dossiers et éléments du dossier (parent) actuellement sélectionné. Cela a pour effet de propager l’ensemble d’autorisations du dossier parent vers le bas de la hiérarchie, chaque dossier/élément héritant des autorisations de son parent direct.

Notez que ce contrôle de gestion des autorisations n’est disponible que pour les administrateurs de l’Espace de travail.

Accès à la commande Enforce inheritance for all child items depuis la page Explorateur.

Accès à la commande Enforce inheritance for all child items depuis la page Projets.

 

Bien qu’elle ne soit normalement pas nécessaire, l’exécution de la commande peut atténuer la situation où des sous-dossiers ou des éléments sont détachés (déconnectés) de la hiérarchie d’héritage. Cela peut se produire parce que l’option Inherit parent folder permissions d’un sous-dossier ou d’un élément a été désactivée afin de permettre la suppression (ou la rétrogradation) d’une autorisation héritée existante. Dans cette situation, une modification de l’ensemble d’autorisations au niveau du dossier supérieur ne se propagera pas dans la hiérarchie vers tout dossier/élément dont l’héritage est déconnecté.

Un exemple pourrait être celui où plusieurs dossiers de sauvegarde, définis avec un accès Admin uniquement, sont ensuite déplacés dans un dossier d’archive global. Chacun de ces dossiers est détaché de la hiérarchie des dossiers (l’option Inherit parent folder permissions est désactivée) afin de permettre la rétrogradation des autorisations d’accès à Admin uniquement. Lorsqu’ils sont déplacés dans le dossier d’archive (qui est lui aussi défini sur Admin uniquement), ils conservent leur statut détaché. Voir Déplacement de dossiers.

Cependant, comme l’héritage des autorisations n’est pas continu dans la hiérarchie du dossier d’archive, les modifications apportées à son ensemble d’autorisations de niveau supérieur, par exemple l’ajout d’un accès View pour Managers, ne se propageront pas à ses sous-dossiers ni à leur contenu. Cette situation peut être corrigée en appliquant la commande Enforce inheritance for all child items, qui restaure l’héritage des autorisations en activant le paramètre Inherit parent folder permissions pour tous les sous-dossiers et leurs éléments. L’accès Manager appliqué est alors propagé dans toute la hiérarchie du dossier d’archive.

Les étapes de cet exemple sont illustrées ci-dessous. Les différents dossiers contiendraient des éléments tels que des composants ou des projets, etc.

Une collection de dossiers de sauvegarde (Dossiers A et B), accessibles uniquement aux administrateurs, doit être déplacée dans un dossier Archives général, également accessible uniquement aux administrateurs. L’option Inherit parent folder permissions est désactivée pour les dossiers Archive et Sauvegarde.

Une fois déplacés, les dossiers de sauvegarde conservent le paramètre de leur option Inherit parent folder permissions (désactivée). Notez que l’option Inherit parent folder permissions est activée pour le dossier Sauvegarde existant ; il héritera donc des modifications apportées au dossier Archive, son parent.

Les autorisations du dossier Archive sont mises à jour par l’ajout de droits View pour Managers.

 

Le dossier Sauvegarde existant adoptera l’ensemble d’autorisations mis à jour du dossier Archive, car son option Inherit parent folder permissions est activée. Les autorisations d’accès des dossiers Sauvegarde A et B ne changeront pas car ils sont déconnectés de la hiérarchie (pas d’héritage).

La commande Enforce inheritance for all child items est appliquée au dossier Archives de niveau supérieur.

L’option Inherit parent folder permissions est activée pour les sous-dossiers. Cela inclut les dossiers Sauvegarde A et B, qui héritent par conséquent de l’ensemble d’autorisations de leurs dossiers parents. La hiérarchie des dossiers a été modifiée de force afin d’avoir un héritage continu des autorisations. Ainsi, toute modification ultérieure des autorisations apportée au dossier Archive (de niveau supérieur) sera adoptée par ses sous-dossiers.

 

Un autre exemple d’héritage forcé peut illustrer la situation dans laquelle des dossiers détachés possèdent des ensembles d’autorisations existants. Le principe fondamental de l’héritage des autorisations est que les dossiers et les éléments adoptent les autorisations de leur dossier parent et ne sont pas remplacés par elles ; ainsi, lorsque l’héritage est activé, les autorisations existantes du dossier/élément sont conservées. Voir Continuité de l’héritage des autorisations ci-dessous pour plus d’informations.

Une hiérarchie de dossiers avec différents ensembles d’autorisations, où les sous-dossiers de niveau inférieur (Subfolder 2 et Subfolder 3) ont leur option Inherit parent folder permissions désactivée — ils sont détachés de la hiérarchie des autorisations.

Application de l’option Enforce inheritance for all child items. Notez que les dossiers dont l’héritage est désactivé (2 et 3) ont des autorisations de partage existantes appliquées — indiquées en souligné.

La commande active l’option Inherit parent folder permissions pour tous les sous-dossiers, qui héritent de l’ensemble d’autorisations du niveau supérieur tout en conservant leurs autorisations existantes. Notez que l’autorisation Managers Read existante dans le Sous-dossier 3 adopte l’autorisation Write correspondante de son parent.

 

Continuité de l’héritage des autorisations

La continuité de l’héritage des autorisations de partage à travers la hiérarchie des dossiers de l’Espace de travail, telle que décrite ci-dessus, est maintenue à moins que l’héritage des autorisations d’un dossier depuis son dossier parent ne soit explicitement déconnecté (désactivé) à un moment donné. La propagation Parent vers Enfant des autorisations pour un dossier (ou projet/élément) est désactivée en décochant son option Inherit permissions from parent, telle qu’elle est disponible dans la boîte de dialogue Share Item. Bien que ce dossier n’hérite alors plus des modifications d’autorisations apportées à son parent, et que la hiérarchie des autorisations soit effectivement déconnectée (désactivée) à ce point, l’héritage reste continu en dessous de ce niveau.

La profondeur complète de l’héritage des autorisations des dossiers sera rétablie si l’option Inherit permissions from parent de ce dossier « déconnecté » est réactivée. Il réhéritera alors des autorisations du parent (si elles ne sont pas déjà présentes) afin de restaurer l’intégrité des autorisations parent-enfant.

Un exemple de hiérarchie de dossiers (A-D) avec un héritage continu des autorisations. L’autorisation Engineers Write a été ajoutée au niveau supérieur du dossier A (ou au-dessus) et s’est propagée dans la hiérarchie jusqu’au dossier D.

Désactivation de l’héritage des autorisations parent-enfant au niveau du dossier C en décochant l’option Inherit permissions from parent dans la boîte de dialogue Share du dossier.

La continuité de l’héritage des autorisations est interrompue entre les dossiers B et C, mais elle est conservée dans les sections de la hiérarchie situées au-dessus et au-dessous de ce point.

Ajout de Managers Write comme nouvelle autorisation d’accès au dossier A.

L’autorisation ajoutée est héritée par le dossier B. Autrement dit, elle se propage uniquement dans la section contiguë de la hiérarchie où l’héritage des autorisations est actif (A-B), mais pas au dossier C, car l’héritage B-C (parent-enfant) est désactivé.

Ajout de l’autorisation Librarians Read au dossier C. En outre, les autorisations existantes du dossier C pourraient être rétrogradées ou supprimées, puisqu’elles ne sont plus liées à celles du dossier parent B.

L’autorisation ajoutée est héritée par le dossier D. Autrement dit, elle se propage dans la section contiguë de la hiérarchie où l’héritage est actif (C-D).

Réactivation de l’héritage des autorisations parent-enfant au niveau du dossier C en cochant l’option Inherit permissions from parent dans la boîte de dialogue Share du dossier.

L’héritage des autorisations redevient continu dans toute la hiérarchie de dossiers, car l’héritage du dossier B vers le dossier C (parent→enfant) est activé. Le dossier C (et les éléments situés en dessous) hérite de l’autorisation Manager Write depuis le dossier B afin de maintenir la relation complète d’héritage parent-enfant.

 

Conformément au schéma d’héritage des autorisations activé, les autorisations d’un dossier/élément peuvent être élevées et complétées (ce qui revient effectivement à la même action), mais ne peuvent pas être rétrogradées par rapport à celles de leur parent. Cela s’applique également si une autorisation ajoutée pour un groupe/utilisateur doit être commune aux entités parent et enfant :

  • Lorsqu’une autorisation est ajoutée à un dossier, elle remplacera effectivement la même autorisation dans un dossier enfant si celle-ci est à un niveau d’accès inférieur. Par exemple, si l’autorisation Librarians Read/Write est ajoutée à un dossier et que son dossier enfant possède déjà une entrée Librarians Read, celle-ci sera élevée au niveau d’une entrée Librarians Read/Write.
    En substance, un accès de niveau écriture a été ajouté au dossier parent, et celui-ci est hérité par le dossier enfant. L’héritage des autorisations est maintenu.

  • À l’inverse, lorsqu’une autorisation est ajoutée à un dossier, elle n’affecte pas la même autorisation dans un dossier enfant si celle-ci dispose d’un niveau d’accès supérieur. Par exemple, si l’autorisation Librarians Read est ajoutée à un dossier et que son dossier enfant possède déjà une entrée Librarians Read/Write, celle-ci ne sera pas modifiée (rétrogradée) en une entrée de niveau Read — elle reste à son niveau d’autorisation existant.
    En substance, un accès de niveau lecture a été ajouté au parent, et celui-ci existe déjà dans le dossier enfant. L’héritage des autorisations est maintenu.

Lorsqu’une entrée d’autorisation est supprimée d’un dossier, cette modification se propage dans la hiérarchie (là où l’héritage des autorisations est activé), quel que soit le niveau d’accès appliqué (Read ou Write). Par exemple, si un dossier possède des autorisations d’accès Librarians Read mais que les autorisations de son dossier enfant ont été élevées à Librarians Write, alors la suppression de l’entrée Librarians du parent supprimera également l’entrée Librarians de l’enfant.

La logique d’héritage des autorisations de dossier décrite ici s’applique également aux éléments de projet (Design et projets Managed BOM). Un projet est toujours l’enfant d’un dossier parent et héritera de ses autorisations, et l’héritage des autorisations peut être désactivé de la même manière que pour un dossier enfant.
Les autorisations du projet sont modifiées dans la fenêtre Share Item de la page Workspace Projects.

Déplacement de dossiers

Les dossiers du Workspace peuvent être déplacés vers n’importe quel autre emplacement dans la structure des dossiers via la page Projects (voir Workspace Projects page) ou le volet Explorer dans Altium Designer (voir Organizing Your Workspace).

La manière dont les autorisations de partage d’un dossier déplacé sont déterminées dépend de la relation d’héritage avec son dossier parent actuel :

  • Lorsque l’option Inherit parent folder permissions d’un dossier est activée (condition par défaut), le déplacement de ce dossier dans un autre dossier aura pour effet de :

    • hériter de l’ensemble des autorisations de son nouveau dossier parent (y compris le propriétaire de ce dossier).

    • perdre ses autorisations héritées d’origine.

      • * Les autorisations « héritées » d’un dossier/projet sont celles adoptées depuis son parent — elles ont été héritées.

    • conserver ses autorisations étendues précédentes.

      • * Les autorisations « étendues » d’un dossier/projet sont celles qui ont été spécifiquement ajoutées pour étendre l’accès utilisateur — elles n’ont pas été héritées de leur parent.

  • En bref, les autorisations de l’ancien parent sont remplacées par celles du nouveau parent, mais celles qui ont été ajoutées se déplacent avec le dossier.

  • Lorsque l’option Inherit parent folder permissions d’un dossier est désactivée (il n’adopte pas les autorisations de son parent), le déplacement de ce dossier dans un autre dossier aura pour effet de :

    • conserver ses autorisations d’origine.

    • conserver l’état désactivé de son paramètre Inherit parent folder permissions.

  • En bref, il s’agit littéralement d’un événement de déplacement sans autre modification. Cela peut être considéré comme la manière la plus sûre de déplacer un dossier et son contenu, car cela évite la possibilité de modifications inattendues des autorisations dues à l’héritage depuis son nouveau dossier parent.

Dans cet exemple, les dossiers A-B-C se trouvent dans une hiérarchie qui inclut des autorisations Engineers Write héritées. Les autorisations du dossier C ont été étendues par l’ajout de Contractors Read. À la place, un utilisateur individuel aurait également pu être ajouté.

Moving folder with Permission Inheritance enabled. Le dossier C sera déplacé dans le dossier D, qui comporte un ensemble d’autorisations différent. Notez que l’héritage des autorisations est activé pour tous les dossiers (condition par défaut).

Le dossier C déplacé est maintenant un enfant du dossier D et héritera de l’autorisation Mechanical Read de son parent. Le dossier C perdra également ses autorisations héritées d’origine (Engineers Read/Write) mais conservera ses autorisations étendues (ajoutées) (Contractors Read).

Moving a folder with Permission Inheritance disabled. L’option Inherit permission from parent de la fenêtre Share a été désactivée (décochée) pour le dossier C. En outre, une autorisation supplémentaire Managers Read a été ajoutée.

Le dossier C sera déplacé dans le dossier E, qui comporte un ensemble d’autorisations différent. Notez que l’héritage des autorisations est désactivé pour le dossier C, qui est « détaché » de son parent (dossier D) en termes d’héritage des autorisations.

Le dossier C déplacé conservera à la fois son ensemble d’autorisations d’origine et son paramètre d’héritage des autorisations (désactivé). Il est déplacé dans le dossier E sans modification des autorisations et n’héritera d’aucune modification d’autorisation apportée à son parent, le dossier E.

 

Avant de déplacer un dossier ou un projet dans un autre dossier, il est fortement recommandé de vérifier d’abord les autorisations du dossier cible, car par défaut (si Inherit parent folder permissions est activé), celles-ci seront héritées par le dossier/projet déplacé. Par exemple, les autorisations du dossier cible peuvent offrir un niveau de partage plus élevé que souhaité, comme des droits de modification ou un accès pour tous les utilisateurs, qui s’appliqueront alors au dossier/projet déplacé

Notez que la logique d’héritage des autorisations de dossier décrite ici s’applique également au déplacement des projets (Design et projets Managed BOM). Un projet est toujours l’enfant d’un dossier parent, et son état d’héritage des autorisations est activé/désactivé par l’option Inherit parent folder permissions, de la même manière que pour un dossier enfant.

Gestion des autorisations de création de projet

Avec les paramètres Workspace par défaut, les projets créés ou téléversés par les membres du Workspace sont stockés dans le dossier Projects, disponible en accès écriture pour tous les utilisateurs (comme hérité du dossier parent Projects), et sont directement accessibles via la page Projects. Cette organisation simple est pratique pour les utilisateurs, mais elle permet à n’importe quel membre du Workspace de créer des projets accessibles dans cet emplacement principal (niveau supérieur). Pour mettre en place un contrôle plus avancé sur les personnes autorisées à créer (et à accéder à) des projets dans le dossier Projects, ou dans des sous-dossiers supplémentaires, les administrateurs du Workspace peuvent définir les autorisations de partage du dossier de projet via la page Explorer ou, dans Altium Designer, le panneau Explorer.

Comme indiqué ci-dessus, les autorisations de dossier sont accessibles dans la page Explorer du Workspace à partir de l’option Share Folder du menu contextuel obtenu par clic droit sur une entrée de dossier. Par exemple, l’accès au dossier Projects peut être modifié en définissant l’autorisation par défaut (Workspace Members) en lecture seule (en désélectionnant Can Write) ou en la supprimant complètement, puis en ajoutant des autorisations d’accès pour des utilisateurs spécifiques (Add User) ou des groupes d’utilisateurs (Add Role), selon les besoins.

 

Les autorisations d’écriture mises à jour détermineront quels membres du Workspace peuvent créer (ou téléverser) des projets dans le dossier Projects — dans l’exemple ci-dessus, uniquement ceux qui sont membres du groupe Managers. Les contraintes d’autorisation s’appliqueront également aux utilisateurs qui créent un nouveau projet dans Altium Designer.

Pour une hiérarchie de dossiers structurée dans laquelle les autorisations et l’accès des utilisateurs/groupes sont configurés en conséquence, par exemple avec une ouverture progressive vers le bas de l’arborescence des dossiers, cette approche peut fournir des niveaux d’autorisation d’accès adaptés pour les utilisateurs et les groupes en fonction du dossier cible.

Autorisations de création de projet par défaut

Comme alternative à l’organisation par défaut, dans laquelle un projet nouvellement ajouté hérite de l’ensemble d’autorisations de son dossier parent, vous pouvez définir un ensemble d’autorisations fixe pour tous les nouveaux projets en activant l’option Default Permissions for new projects dans la vue Projects de la page Admin – Settings. Cette configuration peut être mieux adaptée à une hiérarchie d’autorisations de dossiers moins structurée, où tous les projets utilisateur sont créés à un emplacement spécifique, tel que le dossier Projects.

Cette option est disponible lorsque vous disposez d’un niveau d’accès Altium Solution plus élevé.

Lorsqu’elle est activée, un projet nouvellement créé adopte les autorisations définies par cette option au lieu d’hériter des autorisations de son dossier parent. Les paramètres initiaux de l’option correspondent aux paramètres par défaut du Workspace – accès en écriture pour tous les utilisateurs – et peuvent être modifiés selon vos besoins. Par exemple, vous pouvez définir un accès Write (modification) pour les ingénieurs et un accès View (lecture seule) pour les bibliothécaires.

Pour définir un ensemble fixe d’autorisations d’accès pour les projets nouvellement créés (ou téléversés), activez l’option Default permissions for new projects dans la page Admin - Settings, qui est initialement définie sur la condition par défaut de l’accès Write pour tous les Workspace members.

Sélectionnez les ensembles d’autorisations souhaités pour les projets nouvellement créés – dans cet exemple, uniquement Engineers Write et Librarians Read. Notez que les administrateurs et le propriétaire du projet (créateur) disposent toujours d’un accès complet en écriture.

Lorsqu’un utilisateur crée/téléverse un nouveau projet, les autorisations par défaut spécifiées sont appliquées au lieu de celles adoptées depuis le dossier parent du projet (Projects), comme indiqué dans la boîte de dialogue Share du projet.

L’option Inherit parent folder permissions de la fenêtre est automatiquement désactivée pour un nouveau projet lorsque l’option Default permission for new projects (dans Admin - Settings) a été activée.

 

Points of note:

  • Les administrateurs disposent toujours d’un accès en écriture à tous les projets (et dossiers), cette configuration ne peut donc pas être modifiée (elle est en lecture seule).

  • Le propriétaire du projet (l’utilisateur qui a créé un projet) dispose d’un accès complet à ce projet, et par extension à son dossier parent, puisque des autorisations d’écriture sur le dossier sont requises pour créer un nouveau projet.

  • L’application d’un ensemble fixe d’autorisations de projet (comme décrit ci-dessus) n’inclura probablement pas les autorisations du dossier parent ; l’héritage automatique des autorisations parent-enfant du projet (dossier-projet) est donc désactivé automatiquement – diapositive n°4 ci-dessus. S’il est réappliqué manuellement au projet, l’ensemble d’autorisations du dossier parent sera alors ajouté au projet – voir Permission Inheritance Continuity ci-dessus pour plus d’informations.

  • Le comportement d’adoption des autorisations décrit pour les nouveaux projets s’applique également lors du clonage d’un projet.

Création de projet sans accès en écriture au dossier

Lorsqu’un utilisateur ne disposant pas d’un accès en écriture à un dossier de projet – tel que l’emplacement de stockage par défaut ou un autre dossier qui lui a été partagé – accède pour la première fois au Workspace, le système crée automatiquement une structure Personal Folder propre à cet utilisateur pour stocker les nouveaux projets. Celle-ci apparaît sous la forme d’un dossier de niveau supérieur basé sur l’adresse e-mail du membre, avec un sous-dossier My Projects qui stocke les projets de l’utilisateur. La structure/hiérarchie de dossiers appartient uniquement à l’utilisateur connecté (ainsi qu’aux administrateurs) et n’est pas visible par les autres utilisateurs.

 
  • Si l’utilisateur effectue une création ou un téléversement de projet dans un dossier sur lequel il dispose d’un accès en écriture, le projet est alors stocké dans ce dossier.

  • Si l’utilisateur effectue une création ou un téléversement de projet dans un dossier sur lequel il ne dispose que d’un accès en lecture seule (View), et qu’il ne s’agit pas de l’emplacement de stockage par défaut, le processus est bloqué () et la structure de dossier My Projects de niveau supérieur est créée pour cet utilisateur si elle n’existe pas déjà.

  • Dans l’exemple d’autorisations de dossier Projects présenté ci-dessus, les projets créés par des utilisateurs membres du groupe Managers seront inclus dans le dossier Projects normalement, puisqu’ils disposent de droits complets de modification sur ce dossier. Les autres utilisateurs disposent d’un accès en lecture seule (View) au dossier Projects, de sorte que leurs nouveaux projets sont stockés dans leur dossier My Projects.

  • Si un projet situé dans le dossier My Projects d’un membre du Workspace est partagé avec d’autres utilisateurs (via Workspace Members, Groups ou des noms d’utilisateur spécifiques), il apparaîtra alors dans la vue de niveau supérieur de la page Projects pour ces utilisateurs.

Du point de vue d’un administrateur du Workspace, les dossiers personnels des membres sont regroupés sous un dossier Home de niveau supérieur, comme on peut le voir dans la page Projects et dans la hiérarchie de dossiers de la page Explorer – ainsi que dans l’arborescence des dossiers du volet Explorer d’Altium Designer.

 

Téléchargement d’une révision d’élément

Pour les membres du Workspace, le contenu du projet (fichiers source, fichiers générés, données publiées, etc.) peut être téléchargé via les vues Design et Releases du projet. Dans la page Explorer, vous pouvez télécharger directement des données depuis l’interface en cliquant sur le contrôle Download () à droite de l’entrée correspondant à une révision d’élément.

L’utilisation du contrôle au niveau de l’élément parent téléchargera les données de la dernière révision de cet élément.

Navigation dans la structure du Workspace

Bien que la navigation orientée projet dans le contenu du Workspace soit disponible pour tous les membres du Workspace via les pages Projects et Components, les administrateurs du Workspace peuvent parcourir et accéder à tout le contenu via l’interface de la page Explorer, comme décrit ci-dessous.

Les différentes façons de naviguer dans le contenu du Workspace via l’interface du navigateur.

Les résultats d’une recherche d’exemple.

 

Les administrateurs peuvent accéder au contenu du Workspace :

  1. En cliquant sur le nom d’un dossier dont ils souhaitent parcourir le contenu.

  2. En utilisant la fonction de recherche. Saisissez un mot-clé basé sur l’ID, le commentaire ou la description d’un élément, puis appuyez sur Enter ou cliquez sur l’icône en forme de loupe (). L’ensemble du Workspace sera analysé et les résultats de la recherche seront listés sous forme d’éléments correspondants.

    Après une recherche, vous pouvez revenir à la vue normale du contenu du Workspace en cliquant à nouveau sur l’entrée de page Admin – Explorer , dans l’arborescence de navigation de l’interface du navigateur située à l’extrême gauche. Vous pouvez également effacer le champ de recherche et appuyer sur Enter.

Fonctionnalités supplémentaires

Les fonctionnalités supplémentaires suivantes sont disponibles lors de la navigation dans le contenu via l’interface navigateur du Workspace :

  • Navigate – cette commande, disponible dans le menu contextuel accessible par clic droit sur un élément, permet d’accéder rapidement à cet élément dans le panneau Explorer d’Altium Designer. Altium Designer sera ouvert pour effectuer cette action (une invite vous demandera si vous souhaitez ouvrir X2.exe – l’exécutable source d’Altium Designer).

    Si Altium Designer est déjà en cours d’exécution, cette instance sera utilisée.

  • Full item info – cette commande, disponible dans le menu contextuel accessible par clic droit sur une révision d’élément, permet d’afficher une vue listant tous les détails de cette révision. En pratique, il s’agit simplement d’une vue qui inclut toutes les différentes vues d’aspect disponibles pour cette révision d’élément (sauf Summary).

    L’utilisation de la commande au niveau de l’élément parent affichera les détails de la dernière révision de cet élément.

  • Follow/UnFollow – utilisez la commande Follow , disponible dans le menu contextuel accessible par clic droit sur un dossier de type Components, pour suivre ce dossier. Toute activité dans le dossier suivi (création de composants, publication, changement d’état de révision ou suppression) sera signalée par une notification par e-mail envoyée depuis le Workspace (à condition que les notifications par e-mail aient été activées pour le Workspace par un administrateur). Utilisez la commande UnFollow pour cesser de suivre l’activité des composants dans ce dossier.

  • Remove Folder – utilisez cette commande, disponible dans le menu accessible par clic droit sur un dossier, pour déplacer ce dossier et tout son contenu (sous-dossiers et éléments qu’il contient) vers la zone isolée Trash du Workspace. Les entités présentes dans Trash peuvent ensuite être supprimées définitivement ou restaurées, selon les besoins. Si vous supprimez un dossier de projet, toutes les publications et tous les packages de fabrication associés seront également déplacés vers la Trash.

  • Remove Item – utilisez cette commande, disponible dans le menu accessible par clic droit sur un élément, pour déplacer cet élément vers la zone isolée Trash du Workspace. Les entités présentes dans Trash peuvent ensuite être supprimées définitivement ou restaurées, selon les besoins. Si vous supprimez un élément composant, vous avez également la possibilité de déplacer en même temps ses modèles associés vers la Trash. Notez que ceux-ci ne peuvent être supprimés que s’ils ne sont pas utilisés ailleurs (par un ou plusieurs autres composants).

AI-LocalizedLocalisé par IA
Si vous trouvez un problème, sélectionnez le texte/l’image et appuyez surCtrl + Entréepour nous envoyer vos commentaires.
Disponibilité des fonctionnalités

Les fonctionnalités auxquelles vous avez accès dépendent de la solution Altium dont vous disposez – Altium Develop, Altium Agile Teams, Altium Agile Enterprise, ou Altium Designer (avec un abonnement actif).

Si vous ne voyez pas une fonctionnalité documentée dans votre logiciel actuel, contactez le service commercial d’Altium pour en savoir plus.

Contenu