Gerenciando a estrutura e o acesso ao conteúdo

Updated: August 02, 2026

A estrutura do conteúdo e o gerenciamento de acesso de um Workspace podem ser realizados tanto na página Admin – Explorer (por um Administrador) quanto na página principal Projects (por um membro do Workspace com direitos suficientes). Os comandos e recursos nessas páginas permitem:

Navegar pelas pastas e pelos Items dentro do Workspace. Você pode criar, editar e remover pastas, e assim montar a estrutura do Workspace. Pastas e itens removidos são enviados para a Lixeira, onde podem ser excluídos permanentemente ou restaurados.
Definir compartilhamento no nível de pasta e no nível de Item. Isso controla quem pode ver qual conteúdo existe no Workspace e, no nível de pasta, se outros usuários podem apenas visualizar uma pasta e seu conteúdo ou também editá-la (efetivamente liberando/confirmando/fazendo upload de dados de projeto nela).
Especificar se uma pasta ou item (como um projeto) herda suas permissões de compartilhamento da pasta pai. Essa é a condição padrão.

Em termos de estrutura e gerenciamento de conteúdo, as interfaces das páginas Projects e Explorer diferem em termos de capacidades e conveniência:

A página Projects do Workspace oferece uma abordagem simples para gerenciamento de pastas e itens de projeto, disponível para Administradores, proprietários de projeto/item e outros usuários com direitos de edição suficientes.
Observação: com essa interface, você não pode editar nem definir permissões de compartilhamento para a pasta Projects de nível superior (por padrão), nem criar outra pasta de nível superior.

A maior parte das tarefas de gerenciamento da estrutura e das permissões do Workspace pode ser realizada a partir dos comandos da página Projects.
A página Explorer do Workspace, semelhante ao painel Explorer do Altium Designer e disponível apenas para Administradores, fornece acesso de gerenciamento a todas as pastas e itens, incluindo dados de Release de projeto, Components, Managed Content etc.
Observação: com essa interface, você não pode compartilhar um projeto de design nem mover pastas e itens.

A página Explorer fornece controle detalhado sobre a estrutura do Workspace e as configurações de permissões, incluindo acesso à pasta Projects de nível superior.

Compartilhando pastas e itens

A estrutura de pastas do Workspace do Altium 365 apresenta um esquema avançado de herança de permissões baseado na propagação de permissões de compartilhamento de objetos Pai para Filho — sendo este último uma pasta ou itens de design, como Projects, Components, arquivos BOM, Templates e assim por diante. Essa organização simplifica o processo de organizar a estrutura de pastas de um Workspace e suas permissões de compartilhamento para corresponder aos requisitos de acesso dos usuários e grupos de usuários da empresa.

Um Workspace oferece os seguintes recursos de compartilhamento:

Folder-level Sharing – fornecendo a capacidade de controlar quem pode ver qual conteúdo no Workspace por meio do compartilhamento de pastas. Isso permite controlar se outros usuários podem simplesmente visualizar uma pasta e seu conteúdo ou também editá-la (efetivamente liberando/confirmando/fazendo upload de dados de projeto nela). Um único Workspace pode ser particionado em várias 'zonas' efetivas de conteúdo, mas com permissões controladas no nível de pasta, o que permite que o conteúdo seja tornado seletivamente visível ou oculto conforme necessário, dando às pessoas certas o acesso certo aos dados certos.
Item-level Sharing – fornecendo a capacidade de controlar quem pode ver e acessar quais Items em uma pasta compartilhada. Esse nível mais específico de compartilhamento permite substituir (ou complementar) o conjunto de permissões que um Item herdou de sua pasta pai. Desde que um usuário tenha acesso à própria pasta, ele poderá então visualizar/editar (conforme permitido) os Items dentro dessa pasta que tenham sido compartilhados com ele.

Ao especificar as permissões de compartilhamento para um objeto de item (como um Component, Template etc.) usando a interface Explorer do Workspace, as configurações de compartilhamento do item também serão aplicadas às Revisions que o compõem. Você pode adicionar/remover permissões de Revisions individuais dentro dessa hierarquia, mas a alteração de permissão não se propagará pela própria hierarquia — ela não será herdada pelas Revisions abaixo dela na hierarquia.

Internamente, o acesso a objetos do Workspace é determinado por uma Access Control List hierárquica (ACL) que define as permissões associadas a Folders, Projects e Items. A lista especifica quem tem acesso a esse objeto e se ele pode ser modificado. Por exemplo, se as configurações de compartilhamento de um determinado projeto incluem permissões View (somente leitura) para Librarians, ele será acessível aos membros do grupo Librarians, mas não poderá ser Editado, Movido ou Removido (ou compartilhado novamente) por esses membros — a menos que sejam Administradores ou o proprietário do projeto.

Os recursos de compartilhamento acima obedecem ao esquema de herança de permissões do Workspace. No sentido mais simples, as permissões aplicadas a uma pasta se propagam pela hierarquia de pastas por meio das relações pai-filho — de pasta para subpasta, descendo pela cadeia.

Essa estrutura de herança de permissões é mantida (a menos que seja desativada intencionalmente em algum ponto da hierarquia) quando pastas são adicionadas à hierarquia e também quando permissões são adicionadas dentro da hierarquia. Quando permissões adicionais são aplicadas a uma pasta que não é a pasta de nível superior — isto é, está dentro da hierarquia — elas serão herdadas hierarquia abaixo a partir desse nível, sem afetar as permissões existentes.

Adicione direitos de edição (Read/Write) para o grupo de usuários Engineers à pasta superior na hierarquia de pastas A-B-C.

A nova entrada de permissão (Engineers Read/Write) é aplicada automaticamente a todas as pastas da hierarquia por meio da herança de permissões pai-filho.

Adicione direitos somente leitura (Read) para o grupo de usuários Librarians à hierarquia da Pasta B — seu conjunto de permissões será 'estendido' por essa adição

A nova entrada de permissão (Librarians Read) é aplicada à pasta B e herdada por todas as pastas abaixo dela na hierarquia.

Um Project de design (ou outro tipo de item) é criado ou enviado por upload para a Pasta C. Ele herdará as permissões de compartilhamento da Pasta C.

Estenda o conjunto de permissões da Pasta C adicionando direitos somente leitura (Read) para o Managers Group.

A permissão Managers Read adicionada é herdada pelo Project de design. Observe que as permissões de compartilhamento para projetos Design e Managed BOM são gerenciadas pela caixa de diálogo da janela Share na página Workspace Projects.

Aqueles com privilégios de nível administrativo (membros do grupo Administrators) poderão ver e gerenciar todas as pastas e Items. Um usuário do Workspace sem privilégios administrativos só pode acessar as pastas e Items que criou (dos quais é o 'proprietário') ou aqueles que foram compartilhados com ele por meio de permissões adequadas.

Na página Projects do Workspace, as permissões de pastas de projeto podem ser acessadas e alteradas nas opções Share da interface. Selecione uma entrada de pasta e, em seguida, o botão superior ou a opção Share no menu da entrada para acessar a janela Share Item. Observe que:

por padrão — quando um Workspace é ativado pela primeira vez — a pasta Projects de nível superior não fica acessível na página Projects, mas ficará disponível se outras pastas de nível superior forem criadas. A interface da página Explorer sempre pode acessar a pasta Projects.
a interface e a funcionalidade da janela operam da mesma maneira ao compartilhar um Project — isso inclui a capacidade de alterar o proprietário do Item (pasta).

Permissões de compartilhamento configuradas para a pasta de projeto Team 1 — acesso total para a equipe US Engineering e ECAD Managers somente podem visualizar. Os Projects dentro dessa pasta herdam essas permissões, acrescentando-se às permissões inerentes de gravação do administrador e do proprietário.

Permissões de compartilhamento para uma pasta de projeto que foi adicionada por um usuário, a qual herdará suas permissões da pasta pai (Team 1). A pasta pai foi criada por um usuário diferente (Harold Smith) que é o 'proprietário' dessa pasta, portanto o acesso de gravação à nova pasta também é concedido a esse usuário.

Permissões de compartilhamento configuradas para a pasta de projeto Team 2 — acesso total para a equipe EU Engineering e ECAD Managers somente podem visualizar. Os Projects dentro dessa pasta herdam essas permissões, acrescentando-se às permissões inerentes de gravação do administrador e do proprietário.

Na página Explorer, os controles de compartilhamento são acessados clicando com o botão direito na entrada da árvore de navegação da pasta (ou Item) e usando o comando Share Folder (ou Share Item) no menu de contexto. A janela Share aparecerá, de onde as permissões de acesso para a pasta/Item poderão ser modificadas conforme necessário.

Permissões de compartilhamento para um item de template, conforme herdadas da pasta pai Component Templates.

Pontos importantes:

Em termos de permissões, um usuário/grupo tem acesso de leitura/gravação quando a opção Can Write (Edit) está habilitada. Se essa opção estiver desabilitada, ele terá apenas acesso de leitura (View).

Habilitar acesso Edit a uma Folder/Item para um usuário/grupo equivale efetivamente a adicionar outra permissão ao seu conjunto de permissões (ACL), e alterar esse acesso de volta para View equivale efetivamente a remover uma permissão do conjunto.
Em termos das seleções de permissões de compartilhamento na interface do usuário:
- Uma opção Can Write marcada (leitura/gravação) na página Explorer é equivalente a Can Edit selecionado na página Projects.
- Uma opção Can Write desmarcada (somente leitura) na página Explorer é equivalente a Can View selecionado na página Projects.
Para remover o acesso compartilhado de um usuário/grupo existente a uma pasta/item:
- na página Projects, selecione a opção Remove do bloco do usuário/grupo na janela Share Item.
- na página Explorer, clique no controle Remove associado à entrada do usuário/grupo () na janela Share.
Por padrão, uma pasta/item estará disponível apenas para seu proprietário (inicialmente, seu criador) e todos os membros do grupo Administrators. Essas permissões são inerentes e não precisam ser adicionadas explicitamente. Owners e Administrators têm permissões de Leitura/Gravação (Visualizar/Editar).
Para permitir que todos os usuários do Workspace vejam uma pasta/item:
- na janela Share Item da página Projects, defina a opção de acesso do bloco Workspace Members como Can View, ou Can Edit para acesso completo de gravação.
- na janela Share da página Explorer, selecione o controle Add Workspace Members e desmarque sua opção Can Write, ou deixe-a marcada para acesso completo de gravação.
  
  Esteja ciente de que fazer o acima potencialmente concederá acesso de Leitura/Gravação a todos os membros do Workspace. Se você quiser restringir o acesso a um conjunto específico de usuários e/ou grupos, deverá definir Workspace Members para No access (página Projects) ou remover Workspace Members entry (página Explorer).
Ao contrário de outros itens, as permissões de compartilhamento de um item de projeto de design não podem ser gerenciadas pela página Explorer. Em vez disso, elas são especificadas na janela Share Item, acessada pela página Projects. Consulte a página Workspace Projects page para obter informações detalhadas.

Restrições de compartilhamento controladas por herança

Alguns níveis de acesso do usuário, como Can View ou No access na janela Share Item de uma pasta, podem não estar disponíveis para seleção porque contradiriam (rebaixariam) o conjunto de permissões herdado da pasta pai. Por padrão, as permissões de compartilhamento da pasta são de acesso completo de gravação para todos os usuários – Workspace Members Can Edit, como mostrado na janela Share Item, ou Workspace Members pode Write, como mostrado na janela Share da página Explorer.

Neste caso padrão, por exemplo, as opções para rebaixar as permissões herdadas de uma pasta (de Workspace Members Edit para Workspace Members View ou No Access) ficam desabilitadas para evitar uma desconexão inadvertida na estrutura hierárquica de permissões. Observe que você sempre pode promover (aumentar) o nível de acesso de compartilhamento, já que isso simplesmente 'adiciona' ao conjunto de permissões existente herdado da pasta pai.

Para desconectar intencionalmente a herança de permissões de Pai para Filho desta pasta, de modo que um nível de acesso diferente (reduzido) possa ser aplicado, desmarque a opção Inherit parent folder permissions na Advanced Settings da janela Share Item. Com a pasta deixando de herdar permissões de sua pasta pai, suas próprias permissões de acesso podem ser alteradas sem restrição. Veja a seção abaixo para mais informações.

A opção Inherit permissions from parent folder é inicialmente ativada por padrão e está sempre ativada para pastas recém-criadas.

Da mesma forma, ao alterar permissões de compartilhamento de pasta pela página Explorer page do Workspace, você é impedido de rebaixar permissões herdadas da pasta pai. Desmarque a opção Inherit permissions from parent da janela Share para desconectar intencionalmente a herança de permissões de sua pasta pai (Projects neste caso).

Junto com pastas e Projects, o sistema de herança de permissões também se aplica a Items (como Components) e suas Revisions constituintes. Eles exibem o mesmo comportamento de herança de permissões e incluem a opção de ativar/desativar essa herança (em Advanced Settings na caixa de diálogo Share da página Explorer).

Forçar herança de permissões

As opções Advanced Sharing nas páginas Projects e Admin – Explorer do Workspace oferecem um comando adicional Enforce inheritance for all child items que ativará Inherit parent folder permissions para todas as subpastas e Items dentro da pasta (pai) selecionada no momento. Isso tem o efeito de propagar o conjunto de permissões da pasta pai para baixo na hierarquia, à medida que cada pasta/Item herda as permissões de seu respectivo pai.

Observe que esse controle de gerenciamento de permissões está disponível somente para Administradores do Workspace.

Acesso à página Explorer page para o comando Enforce inheritance for all child items.

Acesso à página Projects page para o comando Enforce inheritance for all child items.

Embora normalmente não seja necessário, o processo do comando pode mitigar a situação em que subpastas ou itens estejam destacados (desconectados) da hierarquia de herança. Isso pode ocorrer porque a opção Inherit parent folder permissions de uma subpasta ou item foi desativada para permitir a remoção (ou rebaixamento) de uma permissão herdada existente. Nessa situação, uma alteração no conjunto de permissões no nível da pasta superior não será propagada hierarquia abaixo para qualquer pasta/item cuja herança esteja desconectada.

Um exemplo seria haver várias pastas de backup configuradas com acesso apenas Admin, que então são movidas para uma pasta geral de arquivo. Cada uma dessas pastas é destacada da hierarquia de pastas (a opção Inherit parent folder permissions está desmarcada/desativada) para permitir o rebaixamento das permissões de acesso para apenas Admin. Quando elas são movidas para a pasta de arquivo (que também está configurada apenas para Admin), mantêm seu status destacado. Consulte Moving Folders.

No entanto, como a herança de permissões não é contínua através da hierarquia da pasta de arquivo, alterações em seu conjunto de permissões de nível superior, por exemplo adicionar acesso View para Managers, não serão propagadas para suas subpastas e respectivos conteúdos. Essa situação pode ser corrigida aplicando o comando Enforce inheritance for all child items, que restaura a herança de permissões ao ativar a configuração Inherit parent folder permissions para todas as subpastas e seus Items. O acesso Manager aplicado é então propagado por toda a hierarquia da pasta de arquivo.

As etapas deste exemplo são ilustradas abaixo. As várias pastas incluiriam Items como Components ou Projects, etc.

Uma coleção de pastas de backup (Pastas A e B), acessíveis apenas a Administradores, precisa ser movida para uma pasta geral de Arquivos – também disponível apenas para Administradores. A opção Inherit parent folder permissions está desativada para as pastas Arquivo e Backup.

Quando movidas, as pastas de Backup mantêm sua configuração da opção Inherit parent folder permissions (desativada). Observe que a opção Inherit parent folder permissions está ativada para a pasta Existing Backup, portanto ela herdará alterações feitas na pasta Arquivo – sua pasta pai.

As permissões da pasta Arquivo são atualizadas com a adição de direitos View para Managers.

A pasta Existing Backup adotará o conjunto de permissões atualizado da pasta Arquivo porque sua opção Inherit parent folder permissions está ativada. As permissões de acesso das pastas Backup A e B não mudarão porque elas estão desconectadas da hierarquia (sem herança).

O comando Enforce inheritance for all child items é aplicado à pasta Arquivos de nível superior.

A opção Inherit parent folder permissions é ativada para as subpastas. Isso inclui as pastas Backup A e B, que consequentemente herdam o conjunto de permissões de suas pastas pai. A hierarquia de pastas foi alterada à força para ter herança de permissões contínua, portanto quaisquer alterações subsequentes de permissões feitas na pasta Arquivo (nível superior) serão adotadas por suas subpastas.

Outro exemplo de herança forçada pode demonstrar a situação em que pastas destacadas têm conjuntos de permissões existentes. O princípio central da herança de permissões é que pastas e itens adotam permissões de sua pasta pai e não são substituídos por elas; portanto, quando a herança é ativada, as permissões existentes da pasta/item são mantidas. Consulte Permission Inheritance Continuity abaixo para mais informações.

Uma hierarquia de pastas com diferentes conjuntos de permissões, em que as subpastas de nível inferior (Subfolder 2 e Subfolder 3) têm a opção Inherit parent folder permissions desativada – elas estão destacadas da hierarquia de permissões.

Aplicando a opção Enforce inheritance for all child items. Observe que as pastas com herança desativada (2 e 3) têm permissões de compartilhamento existentes aplicadas – mostradas sublinhadas.

O comando ativa a opção Inherit parent folder permissions para todas as subpastas, que herdam o conjunto de permissões de acima enquanto mantêm suas permissões existentes. Observe que a permissão existente Managers Read na Subpasta 3 adota a permissão relacionada Write de sua pasta pai.

Continuidade da herança de permissões

A continuidade da herança de permissões de compartilhamento por toda a hierarquia de pastas do Workspace, conforme descrito acima, é mantida a menos que a herança de permissões de uma pasta a partir de sua pasta Pai seja explicitamente desconectada (desativada) em algum ponto. A propagação de permissões de Pai para Filho para uma pasta (ou project/Item) é desativada ao desmarcar sua opção Inherit permissions from parent, conforme disponível na caixa de diálogo Share Item. Embora essa pasta deixe de herdar quaisquer alterações de permissões feitas em sua pasta pai, e a hierarquia de permissões seja efetivamente desconectada (desativada) neste ponto, a herança permanece contínua abaixo desse nível.

A profundidade total da herança de permissões de pasta será restaurada se a opção Inherit permissions from parent dessa pasta 'desconectada' for ativada novamente. Ela então voltará a herdar as permissões da pasta pai (caso ainda não estejam presentes) para restaurar a integridade das permissões entre pai e filho.

Um exemplo de uma hierarquia de pastas (A-D) com herança contínua de permissões. A permissão Engineers Write foi adicionada no nível superior da Pasta A (ou acima) e propagada pela hierarquia até a Pasta D.

Desabilitando a herança de permissões entre pai e filho na Pasta C ao desmarcar a opção Inherit permissions from parent na caixa de diálogo Share da pasta.

A continuidade da herança de permissões é interrompida entre as Pastas B e C, mas é mantida nas seções da hierarquia acima e abaixo desse ponto.

Adicionando Managers Write como uma nova permissão de acesso à Pasta A.

A permissão adicionada é herdada pela Pasta B. Ou seja, ela se propaga apenas pela seção contígua de herança de permissões da hierarquia (A-B), mas não para a Pasta C porque a herança B-C (pai-filho) está desabilitada.

Adicionando a permissão Librarians Read à Pasta C. Além disso, as permissões existentes da Pasta C podem ser rebaixadas ou removidas, já que não estão mais vinculadas às da Pasta-pai B.

A permissão adicionada é herdada pela Pasta D. Ou seja, ela se propaga pela seção contígua de herança da hierarquia (C-D).

Reabilitando a herança de permissões entre pai e filho na Pasta C ao marcar a opção Inherit permissions from parent na caixa de diálogo Share da pasta.

A herança de permissões volta a ser contínua em toda a hierarquia de pastas porque a herança da Pasta B para a C (pai→filho) está habilitada. A Pasta C (e as abaixo dela) herda a permissão Manager Write da Pasta B para manter o relacionamento completo de herança pai-filho.

Em conformidade com o esquema de herança de permissões habilitado, as permissões de uma pasta/item podem ser elevadas e complementadas (efetivamente a mesma ação), mas não rebaixadas em relação às de sua pasta-pai. Isso também se aplica se uma permissão adicionada para um Grupo/Usuário for comum tanto à entidade Pai quanto à entidade Filha:

Ao adicionar uma permissão a uma pasta, isso substituirá efetivamente a mesma permissão em uma pasta filha se ela estiver em um nível de acesso inferior. Por exemplo, se a permissão Librarians Read/Write for adicionada a uma pasta e sua pasta filha tiver uma entrada Librarians Read existente, ela será elevada para uma entrada Librarians Read/Write.
Em essência, o acesso no nível Write foi adicionado à pasta-pai, e isso é herdado pela pasta filha. A herança de permissões é mantida.
Por outro lado, ao adicionar uma permissão a uma pasta, isso não afetará a mesma permissão em uma pasta filha se ela tiver um nível de acesso superior. Por exemplo, se a permissão Librarians Read for adicionada a uma pasta e sua pasta filha tiver uma entrada Librarians Read/Write existente, ela não será alterada (rebaixada) para uma entrada de nível Read — ela permanece em seu nível de permissão existente.
Em essência, o acesso no nível Read foi adicionado à pasta-pai, e isso já existe na pasta filha. A herança de permissões é mantida.

Quando uma entrada de permissão é removida de uma pasta, essa alteração será propagada pela hierarquia (onde a herança de permissões estiver habilitada), independentemente do nível de acesso aplicado (Read ou Write). Por exemplo, se uma pasta tiver permissões de acesso Librarians Read, mas as permissões de sua pasta filha tiverem sido elevadas para Librarians Write, então remover a entrada Librarians da pasta-pai também removerá a entrada Librarians da pasta filha.

A lógica de herança de permissões de pastas descrita aqui também se aplica a Itens de projeto (projetos Design e Managed BOM). Um projeto é sempre filho de uma pasta-pai e herdará suas permissões, e a herança de permissões pode ser desabilitada da mesma forma que em uma pasta filha.
As permissões do projeto são editadas pela janela Share Item na página Workspace Projects.

Movendo Pastas

As pastas do Workspace podem ser movidas para qualquer outro local na estrutura de pastas por meio da página Projects (consulte página Workspace Projects) ou do painel Explorer no Altium Designer (consulte Organizing Your Workspace).

A forma como as permissões de compartilhamento de uma pasta movida são determinadas depende do relacionamento de herança com sua pasta-pai atual:

Quando a opção Inherit parent folder permissions de uma pasta está habilitada (condição padrão), a ação de mover essa pasta para dentro de outra pasta fará com que ela:
- herde o conjunto de permissões de sua nova pasta-pai (incluindo o Owner dessa pasta).
- perca suas permissões herdadas originais.
  - * As permissões 'herdadas' de uma pasta/projeto são aquelas adotadas de sua pasta-pai — elas foram herdadas.
- mantenha suas permissões estendidas anteriores.
  - * As permissões 'estendidas' de uma pasta/projeto são aquelas que foram adicionadas especificamente para ampliar o acesso do usuário — elas não foram herdadas da pasta-pai.

Em resumo, as permissões da pasta-pai antiga são substituídas pelas permissões da nova pasta-pai, mas quaisquer permissões adicionadas acompanharão a pasta.

Quando a opção Inherit parent folder permissions de uma pasta está desabilitada (ela não adota as permissões de sua pasta-pai), a ação de mover essa pasta para dentro de outra pasta fará com que ela:
- mantenha suas permissões originais.
- mantenha o estado desabilitado de sua configuração Inherit parent folder permissions.

Em resumo, trata-se literalmente de um evento de movimentação sem nenhuma outra alteração. Isso pode ser considerado a forma mais segura de mover uma pasta e seu conteúdo, pois evita a possibilidade de alterações inesperadas nas permissões devido à herança da nova pasta-pai.

Neste exemplo, as pastas A-B-C estão em uma hierarquia que inclui permissões herdadas Engineers Write. As permissões da Pasta C foram estendidas com a adição de Contractors Read. Como alternativa, um Usuário individual poderia ter sido adicionado.

Moving folder with Permission Inheritance enabled. A Pasta C será movida para a Pasta D, que apresenta um conjunto de permissões diferente. Observe que a herança de permissões está habilitada para todas as pastas (condição padrão).

A Pasta C movida agora é filha da Pasta D e herdará a permissão Mechanical Read de sua pasta-pai. A Pasta C também perderá suas permissões herdadas originais (Engineers Read/Write), mas manterá suas permissões estendidas (adicionadas) (Contractors Read).

Moving a folder with Permission Inheritance disabled. A opção Share da janela Inherit permission from parent foi desabilitada (desmarcada) para a pasta C. Além disso, foi adicionada uma permissão adicional Managers Read.

A Pasta C será movida para a Pasta E, que apresenta um conjunto de permissões diferente. Observe que a herança de permissões está desabilitada para a Pasta C, que está ‘desvinculada’ de sua pasta-pai (Pasta D) em termos de herança de permissões.

A Pasta C movida manterá tanto seu conjunto original de permissões quanto sua configuração de herança de permissões (desabilitada). Ela é movida para a Pasta E sem alterações de permissões e não herdará quaisquer mudanças de permissões feitas em sua pasta-pai, a Pasta E.

Antes de mover uma pasta ou projeto para outra pasta, é altamente recomendável verificar primeiro as permissões da pasta de destino, porque, por padrão (Inherit parent folder permissions habilitado), elas serão herdadas pela pasta/projeto movido. Por exemplo, as permissões da pasta de destino podem ter um nível de compartilhamento maior do que o desejado, como direitos de edição ou acesso para todos os usuários, o que então se aplicará à pasta/projeto realocado

Observe que a lógica de herança de permissões de pastas descrita aqui também se aplica à movimentação de projetos (projetos Design e Managed BOM). Um projeto é sempre filho de uma pasta-pai, e seu estado de herança de permissões é habilitado/desabilitado pela opção Inherit parent folder permissions, da mesma forma que em uma pasta filha.

Gerenciando Permissões de Criação de Projetos

Com as configurações padrão do Workspace, os projetos criados ou carregados por membros do Workspace são armazenados na pasta Projects, disponível com acesso de escrita para todos os usuários (como herdado da pasta-pai Projects) e acessados diretamente pela página Projects. Essa configuração simples é conveniente para os usuários, mas permite que qualquer membro do Workspace crie projetos acessíveis nesse local principal (nível superior). Para implementar um controle mais avançado sobre quem pode criar (e acessar) projetos na pasta Projects, ou em subpastas adicionais, os administradores do Workspace podem definir as permissões de compartilhamento da pasta do projeto por meio da página Explorer ou, no Altium Designer, pelo painel Explorer panel.

Conforme descrito acima, as permissões de pastas são acessadas na página Explorer do Workspace a partir da opção Share Folder no menu de contexto, acessado com o botão direito, de uma entrada de pasta. Por exemplo, o acesso à pasta Projects pode ser alterado definindo a permissão padrão (Workspace Members) como somente leitura (desmarcando Can Write) ou removendo-a completamente, e então adicionando permissões de acesso para usuários específicos (Add User) ou grupos de usuários (Add Role), conforme necessário.

As permissões de escrita atualizadas determinarão quais membros do Workspace podem criar (ou carregar) projetos para a pasta Projects — no exemplo mostrado acima, apenas aqueles que são membros do grupo Managers. As restrições de permissão também se aplicarão aos usuários criando um novo projeto no Altium Designer.

Para uma hierarquia estruturada de pastas em que as permissões e o acesso de usuários/grupos sejam configurados de acordo, por exemplo, sendo progressivamente abertos ao longo da árvore de pastas, essa abordagem pode fornecer níveis adequados de acesso por permissões para usuários e grupos com base na pasta de destino.

Permissões Padrão de Criação de Projetos

Como alternativa à disposição padrão, em que um projeto recém-adicionado herdará o conjunto de permissões da sua pasta pai, você pode especificar um conjunto fixo de permissões para todos os novos projetos ativando a opção Default Permissions for new projects na visualização Projects da página Admin – Settings. Essa configuração pode ser mais adequada para uma hierarquia de permissões de pastas menos estruturada, em que todos os projetos de usuários são criados em um local específico, como a pasta Projects.

Essa opção está disponível quando você tem um nível mais alto de acesso ao Altium Solution.

Quando ativada, um projeto recém-criado adotará as permissões especificadas por essa opção, em vez de herdar as permissões da sua pasta pai. As configurações iniciais da opção correspondem às configurações padrão do Workspace – acesso de gravação para todos os usuários – e podem ser alteradas conforme necessário. Um exemplo disso seria acesso Write (edição) para Engenheiros e acesso View (somente leitura) para Bibliotecários.

Para especificar um conjunto fixo de permissões de acesso para projetos recém-criados (ou carregados), ative a opção Default permissions for new projects na página Admin - Settings, que inicialmente está definida com a condição padrão de acesso Write para todos os Workspace members.

Selecione os conjuntos de permissões desejados para projetos recém-criados – neste exemplo, apenas Engineers Write e Librarians Read. Observe que os Administradores e o Proprietário do projeto (criador) sempre têm acesso total de gravação.

Quando um usuário cria/carrega um novo projeto, as permissões padrão especificadas são aplicadas em vez daquelas adotadas da pasta pai do projeto (Projects), como mostrado na caixa de diálogo Share do projeto.

A opção Inherit parent folder permissions da janela é automaticamente desativada para um novo projeto quando a opção Default permission for new projects (em Admin - Settings) tiver sido ativada.

Points of note:

Os Administradores sempre têm acesso de gravação a todos os projetos (e pastas), portanto essa configuração não pode ser alterada (é somente leitura).
O Proprietário do Projeto (o usuário que criou um projeto) tem acesso total ao projeto e, por inferência, à sua pasta pai, porque permissões de gravação na pasta são necessárias para criar um novo projeto.
A aplicação de um conjunto fixo de permissões de projeto (conforme descrito acima) provavelmente não incluirá as permissões da pasta pai, portanto a herança de permissões pai-filho do projeto (pasta-projeto) é desativada automaticamente – slide nº 4, acima. Se ela for reaplicada manualmente ao projeto, então o conjunto de permissões da pasta pai será adicionado ao projeto – consulte Continuidade da Herança de Permissões acima para obter informações.
O comportamento descrito de adoção de permissões para novos projetos também se aplicará ao clonar um projeto.

Criação de Projeto Sem Acesso de Gravação à Pasta

Quando um usuário sem acesso de gravação a uma pasta de projeto – como o local de armazenamento padrão ou alguma outra pasta que tenha sido compartilhada com ele – acessa o Workspace pela primeira vez, o sistema criará automaticamente uma estrutura Personal Folder específica do usuário para armazenar novos projetos. Ela aparece como uma pasta de nível superior baseada no endereço de e-mail do membro, com uma subpasta My Projects que armazena os projetos do usuário. A estrutura/hierarquia de pastas pertence e está disponível apenas para o usuário conectado (e administradores), e não é visível para outros usuários.

Se o usuário executar uma operação de Criar ou Carregar projeto dentro de uma pasta para a qual tenha acesso de gravação, então o projeto será armazenado nessa pasta.
Se o usuário executar uma operação de Criar ou Carregar projeto dentro de uma pasta para a qual tenha acesso somente leitura (View) e que não seja o local de armazenamento padrão, então o processo será bloqueado () e a estrutura de pasta My Projects de nível superior será criada para esse usuário, caso ainda não exista.
Para o exemplo de permissões de pasta Projects mostrado acima, os projetos criados por usuários que são membros do grupo Managers serão incluídos na pasta Projects normalmente, porque eles têm direitos completos de Edit nessa pasta. Outros usuários têm acesso somente leitura (View) à pasta Projects, portanto seus novos projetos são armazenados na pasta My Projects.
Se um projeto localizado na pasta My Projects de um membro do Workspace for compartilhado com outros usuários (por meio de Membros do Workspace, Grupos ou nomes de usuário específicos), então ele aparecerá na visualização de nível superior da página Projects para esses usuários.

Na perspectiva de um administrador do Workspace, as pastas pessoais do membro são reunidas em uma pasta de nível superior Home, como fica evidente na página Projects e na hierarquia de pastas da página Explorer – e também na árvore de pastas do painel Explorer do Altium Designer.

Baixando uma Revisão de Item

Para membros do Workspace, o conteúdo do Projeto (arquivos-fonte, arquivos gerados, dados liberados etc.) pode ser baixado por meio das visualizações Design e Releases do projeto. Na página Explorer, você pode baixar dados diretamente da interface clicando no controle Download () à direita da entrada de uma Revisão de Item.

Usar o controle no nível do Item pai fará o download dos dados da revisão mais recente desse Item.

Navegando pela Estrutura do Workspace

Embora a navegação orientada a projetos do conteúdo do Workspace esteja disponível para todos os membros do Workspace por meio das páginas Projects e Components, os administradores do Workspace podem navegar e acessar todo o conteúdo por meio da interface da página Explorer, conforme descrito abaixo.

As maneiras de navegar pelo conteúdo do Workspace por meio da interface do navegador.

Os resultados de um exemplo de pesquisa.

Os administradores podem navegar até o conteúdo do Workspace:

Clicando no nome de uma pasta cujo conteúdo desejam examinar.
Usando o recurso de pesquisa. Insira uma palavra-chave com base no ID, Comentário ou Descrição de um Item e, em seguida, pressione Enter ou clique no ícone de lupa (). Todo o Workspace será examinado e os resultados da pesquisa serão listados em termos dos Itens correspondentes.

Após uma pesquisa, você pode retornar à visualização normal do conteúdo do Workspace clicando novamente na entrada da página Admin – Explorer , na árvore de navegação da interface do navegador à extrema esquerda. Como alternativa, limpe o campo de pesquisa e pressione Enter.

Recursos Adicionais

Os seguintes recursos adicionais podem ser encontrados ao navegar pelo conteúdo por meio da interface do navegador do Workspace:

Navigate – este comando, encontrado no menu de contexto do botão direito para um Item, é usado para levá-lo rapidamente a esse Item no painel Explorer do Altium Designer. O Altium Designer será aberto para fazer isso (você será solicitado a confirmar se deseja abrir X2.exe – o executável-fonte do Altium Designer).

Se o Altium Designer já estiver em execução, essa instância será usada.
Full item info – este comando, encontrado no menu de contexto do botão direito para uma Revisão de Item, é usado para apresentar uma visualização que lista todos os detalhes dessa Revisão. Na prática, é simplesmente uma visualização que inclui todas as várias visualizações de aspecto disponíveis para essa Revisão de Item (exceto Summary).

Usar o comando no nível do Item pai apresentará os detalhes da revisão mais recente desse Item.
Follow/UnFollow – use o comando Follow , encontrado no menu de contexto do botão direito para uma pasta do Tipo Components, para seguir a pasta. Qualquer atividade dentro da pasta seguida (criação de componente, liberação, alteração do estado da revisão ou exclusão) será sinalizada por meio de uma notificação por e-mail enviada pelo Workspace (desde que as notificações por e-mail tenham sido ativadas para o Workspace por um Administrador). Use o comando UnFollow para parar de seguir a atividade de componentes dentro dessa pasta.
Remove Folder – use este comando, encontrado no menu do botão direito para uma pasta, para mover essa pasta e todo o seu conteúdo (subpastas e Itens nelas contidos) para a área isolada Trash do Workspace. As entidades em Trash podem então ser excluídas permanentemente ou restauradas, conforme necessário. Se estiver removendo uma pasta de projeto, quaisquer liberações e pacotes de fabricação associados também serão movidos para Trash.
Remove Item – use este comando, encontrado no menu do botão direito para um Item, para mover esse Item para a área isolada Trash do Workspace. As entidades em Trash podem então ser excluídas permanentemente ou restauradas, conforme necessário. Se estiver removendo um Item de Componente, você também terá a opção de mover seus modelos associados para Trash ao mesmo tempo. Observe que eles só podem ser excluídos se não estiverem sendo usados em outro lugar (por um ou mais outros componentes).

Versão para impressão

Localizado por IA

Caso encontre um problema, selecione o texto/imagem e primaCtrl + Enterpara nos enviar o seu feedback.