Controlo de acesso

O Weblate vem com um sistema de privilégios fino para atribuir permissões ao utilizador para toda a instância ou num escopo limitado.

Alterado na versão 3.0: Antes do Weblate 3.0, o sistema de privilégios era baseado apenas no sistema de privilégios do Django, mas é agora especificamente construído para Weblate. Se for usado algo mais antigo, consulte a documentação para a versão específica que está a usar.

Controle de acesso personalizado

Se não está a administrar toda a instalação do Weblate e apenas tem acesso para gerir certos projetos (como no Hosted Weblate), as suas opções de gestão de controle de acesso são limitadas às seguintes configurações. Se não precisa de nenhuma configuração complexa, elas são suficientes para si.

Controlo de acesso ao projeto

Nota

Este recurso está indisponível para projetos que executam o plan Libre no Hosted Weblate.

Pode limitar o acesso do utilizador a projetos individuais a selecionar uma configuração diferente de Controle de acesso. As opções disponíveis são:

Pública

Visível publicamente, traduzível para todos os utilizadores autenticados.

Protegido

Publicamente visível, mas somente traduzível por utilizadores selecionados.

Privado

Visível e traduzível apenas por utilizadores selecionados.

Personalizado

Os recursos de Gestão de utilizadores serão desativados; por padrão, todos os utilizadores estão proibidos de realizar qualquer ação no projeto. Terá que configurar todas as permissões a usar Controle de acesso personalizado.

O Controle de acesso pode ser alterado na guia Acesso da configuração (Gerir ↓ Configurações) de cada projeto.

O valor padrão pode ser alterado por DEFAULT_ACCESS_CONTROL.

Nota

Mesmo para projetos Privados, algumas informações sobre o seu projeto serão expostas: estatísticas e resumo de linguagem para toda a instância incluirão contagens para todos os projetos, apesar da configuração de controle de acesso. O nome do seu projeto e outras informações não podem ser revelados por meio disso.

Nota

O conjunto real de permissões disponíveis para utilizadores por padrão em projetos Públicos, Protegidos e Privados pode ser redefinido pelo administrador da instância de Weblate a usar configurações personalizadas.

Veja também

Controlo de acesso

A gerir controle de acesso por projeto

Os utilizadores com o privilégio gerir o acesso ao projecto (ver Lista de privilégios e funções embutidas) podem gerir utilizadores em projetos através da adição deles às equipas. A coleção inicial de equipas é fornecida pela Weblate, mas equipas adicionais podem ser definidas, proporcionando um controlo de acesso mais fino. É possível limitar as equipas aos idiomas e atribuir-lhes funções de acesso designadas (ver Lista de privilégios e funções embutidas).

As equipas seguintes são criadas automaticamente para cada projeto:

Para projetos Públicos, Protegidos e Privados:

Administração

Inclui todas as permissões disponíveis para o projeto.

Revisar (somente se fluxo de trabalho de revisão estiver ativado)

Pode aprovar traduções durante a revisão.

Para projetos Protegidos e Privados apenas:

Traduzir

Pode traduzir o projeto e enviar traduções feitas offline.

Fontes

Pode editar cadeias fonte (se permitido nas configurações do projeto) e informações de cadeias fonte.

Idiomas

Pode gerir idiomas traduzidos (adicionar ou remover traduções).

Glossário

Pode gerir glossário (adicionar ou remover entradas e também enviar).

Memória

Pode gerir memória de tradução.

Capturas de ecrã

Pode gerir capturas de ecrã (adicioná-las ou removê-las e associá-las a cadeias fonte).

Tradução automática

Pode usar a tradução automática.

VCS

Pode gerir VCS e acessar o repositório exportado.

Faturação

Pode acessar informações de cobrança e configurações (consulte Faturação).

Esses recursos estão disponíveis na página Controle de acesso, que pode ser acessada no projeto a partir do menu Gerir ↓ Utilizadores.

Team administrators

Novo na versão 4.15.

Each team can have team administrator, who can add and remove users within the team. This is useful in case you want to build self-governed teams.

Novo convite de utilizador

Além de adicionar um utilizador existente ao projeto, também é possível convidar novos. Qualquer novo utilizador será criado imediatamente, mas a conta permanecerá inativa até que entre com uma ligação no convite enviado por e-mail. Não é necessário ter nenhum privilégio de todo o site para fazer isso, a permissão de gestão de acesso no escopo do projeto (por exemplo, uma associação ao grupo Administração) seria suficiente.

Dica

Se o utilizador convidado perdeu a validade do convite, ele pode definir a sua palavra-passe a usar o endereço de e-mail convidado no formulário de redefinição de palavra-passe, pois a conta já foi criada.

Novo na versão 3.11: É possível reenviar o e-mail para convites de utilizador (a invalidar qualquer convite enviado anteriormente).

O mesmo tipo de convite está disponível em todo o site a partir da interface de gestão na guia Utilizadores.

A bloquear utilizadores

Novo na versão 4.7.

No caso de alguns utilizadores se comportarem mal no seu projeto, tem a opção de bloqueá-los de contribuir. O utilizador bloqueado ainda poderá ver o projeto se tiver permissão para isso, mas não poderá contribuir.

Gestão de permissões por projeto

Pode definir os seus projetos para Protegido ou Privado e gerir utilizadores por projeto na interface de utilizador do Weblate.

By default this prevents Weblate from granting access provided by Users and Viewers default teams due to these teams’ own configuration. This doesn’t prevent you from granting permissions to those projects site-wide by altering default teams, creating a new one, or creating additional custom settings for individual component as described in Controle de acesso personalizado below.

Um dos principais benefícios de gerir permissões por meio da interface de utilizador do Weblate é que pode delegá-las a outros utilizadores sem lhes dar o privilégio de superutilizador. Para isso, adicione-os à equipa Administração do projeto.

Controle de acesso personalizado

Nota

Este recurso está indisponível para projetos que executam o plan Libre no Hosted Weblate.

The permission system is based on teams and roles, where roles define a set of permissions, and teams link them to users and translations, see Users, roles, teams, and permissions for more details.

Os recursos mais poderosos do sistema de controle de acesso do Weblate por enquanto estão disponíveis apenas através da interface administrativa do Django. Pode usá-la para gerir as permissões de qualquer projeto. Não precisa necessariamente definir o controle de acesso para Personalizado para utilizá-lo. No entanto, deve ter privilégios de superutilizador para usá-lo.

Se não está interessado em detalhes de implementação e apenas deseja criar uma configuração simples o suficiente com base nos padrões, ou não tem um acesso de todo o site para toda a instalação do Weblate (como em Hosted Weblate), consulte a secção Controle de acesso personalizado.

Configurações comuns

Esta secção contém uma visão geral de algumas configurações comuns nas quais pode estar interessado.

Gestão de permissões para todo o site

To manage permissions for a whole instance at once, add users to appropriate default teams:

• Users (this is done by default by the automatic team assignment).

• Revisores (se estiver a usar fluxo de trabalho de revisão com revisores dedicados).

• Gestores (se deseja delegar a maioria das operações de gestão a outra pessoa).

You should keep all projects configured as Public (see Controlo de acesso ao projeto), otherwise the site-wide permissions provided by membership in the Users and Reviewers teams won’t have any effect.

You may also grant some additional permissions of your choice to the default teams. For example, you may want to give a permission to manage screenshots to all the Users.

You can define some new custom teams as well. If you want to keep managing your permissions site-wide for these teams, choose an appropriate value for the Project selection (e.g. All projects or All public projects).

Permissões personalizadas a idiomas, componentes ou projetos

You can create your own dedicated teams to manage permissions for distinct objects such as languages, components, and projects. Although these teams can only grant additional privileges, you can’t revoke any permission granted by site-wide or per-project teams by adding another custom team.

Exemplo:

Se quiser (por qualquer motivo) permitir a tradução para um idioma específico (digamos, tcheco) apenas para um conjunto fechado de tradutores confiáveis, a manter as traduções para outros idiomas públicos, terá que:

1. Remove the permission to translate Czech from all the users. In the default configuration this can be done by altering the Users default team.

   Grupo Utilizadores

   Seleção de idioma	Como definido
   Idiomas	Todos, exceto Tcheco

2. Add a dedicated team for Czech translators.

   Grupo Tradutores(as) de tcheco

   Funções	Utilizadores(as) avançados(as)
   Seleção de projeto	Todos os projetos públicos
   Seleção de idioma	Como definido
   Idiomas	Tcheco

3. Add users you wish to give the permissions to into this team.

Como pode ver, a gestão de permissões dessa maneira é poderosa, mas pode ser um trabalho tedioso. Não pode delegá-lo a outro utilizador, a menos que conceda permissões de superutilizador.

Users, roles, teams, and permissions

Os modelos de autenticação consistem em vários objetos:

Permissão

Permissão individual definida pelo Weblate. Permissões não podem ser atribuídas a utilizadores. Isso só pode ser feito através da atribuição de papéis.

Função

Um papel define um conjunto de permissões. Isso permite a reutilização desses conjuntos em vários lugares, a facilitar a administração.

Utilizador

User can belong to several teams.

Grupo

Grupo conecta papéis, utilizadores e objetos de autenticação (projetos, idiomas e listas de componentes).

Nota

A team can have no roles assigned to it, in that case access to browse the project by anyone is assumed (see below).

Acesso para navegar até um projeto

A user has to be a member of a team linked to the project, or any component inside that project. Having membership is enough, no specific permissions are needed to browse the project (this is used in the default Viewers team, see List of teams).

Acesso para navegar até um componente

Um utilizador pode acessar componentes irrestritos assim que for possível acessar o projeto dos componentes (e terá todas as permissões que foram concedidas ao utilizador para o projeto). Com o Acesso restrito ativado, o acesso ao componente requer permissões explícitas para o componente (ou uma lista de componentes na qual o componente está contido).

Scope of teams

The scope of the permission assigned by the roles in the teams are applied by the following rules:

• If the team specifies any Component list, all the permissions given to members of that team are granted for all the components in the component lists attached to the team, and an access with no additional permissions is granted for all the projects these components are in. Components and Projects are ignored.

• If the team specifies any Components, all the permissions given to the members of that team are granted for all the components attached to the team, and an access with no additional permissions is granted for all the projects these components are in. Projects are ignored.

• Otherwise, if the team specifies any Projects, either by directly listing them or by having Projects selection set to a value like All public projects, all those permissions are applied to all the projects, which effectively grants the same permissions to access all projects unrestricted components.

• The restrictions imposed by a team’s Languages are applied separately, when it’s verified if a user has an access to perform certain actions. Namely, it’s applied only to actions directly related to the translation process itself like reviewing, saving translations, adding suggestions, etc.

Dica

Use Seleção de idioma ou Seleção de projeto para automatizar a inclusão de todos os idiomas ou projetos.

Exemplo:

Let’s say there is a project foo with the components: foo/bar and foo/baz and the following team:

Grupo Revisores-admins de espanhol

Funções	Rever cadeias, Gerir repositório
Componentes	foo/bar
Idiomas	Espanhol

Members of that team will have following permissions (assuming the default role settings):

• Acesso geral (navegação) para todo o projeto foo incluindo ambos componentes nele: foo/bar e foo/baz.

• Rever cadeias na tradução para espanhol de foo/bar (não em outro lugar).

• Gerir VCS para todo o repositório foo/bar, por exemplo, fazer commit de alterações pendentes feitas por tradutores de todos os idiomas.

Automatic team assignments

On the bottom of the Group editing page in the Django admin interface, you can specify Automatic team assignments, which is a list of regular expressions used to automatically assign newly created users to a team based on their e-mail addresses. This assignment only happens upon account creation.

The most common use-case for the feature is to assign all new users to some default team. In order to do so, you will probably want to keep the default value (^.*$) in the regular expression field. Another use-case for this option might be to give some additional privileges to employees of your company by default. Assuming all of them use corporate e-mail addresses on your domain, this can be accomplished with an expression like ^.*@mycompany.com.

Nota

Automatic team assignment to Users and Viewers is always recreated when upgrading from one Weblate version to another. If you want to turn it off, set the regular expression to ^$ (which won’t match anything).

Nota

As for now, there is no way to bulk-add already existing users to some team via the user interface. For that, you may resort to using the REST API.

Default teams and roles

After installation, a default set of teams is created (see List of teams).

These roles and teams are created upon installation. The built-in roles are always kept up to date by the database migration when upgrading. You can’t actually change them, please define a new role if you want to define your own set of permissions.

Lista de privilégios e funções embutidas

Âmbito	Permissão	Funções
Faturamento (consulte Faturação)	Ver informação de faturação	Administração, Cobrança
Alterações	Transferir alterações	Administração
Comentários	Publicar comentário	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
	Apagar comentário	Administração
	Resolver comentário	Administração, Revisar textos
Componente	Editar definições de componente	Administração
	Bloquear componente, impedindo traduções	Administração
Glossário	Adicionar entrada de glossário	Administração, Gerir glossário, Utilizador avançado
	Editar entrada de glossário	Administração, Gerir glossário, Utilizador avançado
	Apagar entrada de glossário	Administração, Gerir glossário, Utilizador avançado
	Enviar entradas de glossário	Administração, Gerir glossário, Utilizador avançado
Sugestões automáticas	Usar sugestões automáticas	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
Memória de tradução	Editar memória de tradução	Administração, Gerir memória de tradução
	Apagar memória de tradução	Administração, Gerir memória de tradução
Projetos	Editar definições do projeto	Administração
	Gerir acesso do projeto	Administração
Relatórios	Transferir relatórios	Administração
Capturas de ecrã	Adicionar captura de ecrã	Administração, Gerir capturas de ecrã
	Editar captura de ecrã	Administração, Gerir capturas de ecrã
	Apagar captura de ecrã	Administração, Gerir capturas de ecrã
Cadeias fonte	Editar informação adicional da cadeia	Administração, Editar fonte
Cadeias	Adicionar nova cadeia	Administração
	Remover uma cadeia	Administração
	Dispensar verificação com falha	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
	Editar cadeias	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
	Rever cadeias	Administração, Revisar textos
	Editar cadeia quando as sugestões são forçadas	Administração, Revisar textos
	Editar cadeias fonte	Administração, Editar fonte, Utilizador avançado
Sugestões	Aceitar sugestão	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
	Adicionar sugestão	Administração, Editar fonte, Adicionar sugestão, Utilizador avançado, Revisar textos, Traduzir
	Apagar sugestão	Administração, Utilizador avançado
	Votar na sugestão	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
Traduções	Adicionar idioma para tradução	Administração, Utilizador avançado, Gerir idiomas
	Realizar tradução automática	Administração, Tradução automática
	Apagar tradução existente	Administração, Gerir idiomas
	Descarregar ficheiro de tradução	Administração, Editar fonte, Acessar repositório, Utilizador avançado, Revisar textos, Traduzir, Gerir idiomas
	Adicionar vários idiomas para tradução	Administração, Gerir idiomas
Envios	Definir o autor da tradução enviada	Administração
	Substituir cadeias existentes com enviadas	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
	Enviar traduções	Administração, Editar fonte, Utilizador avançado, Revisar textos, Traduzir
VCS	Aceder ao repositório interno	Administração, Acessar repositório, Utilizador avançado, Gerir repositório
	Submeter alterações no repositório interno	Administração, Gerir repositório
	Enviar alteração do repositório interno	Administração, Gerir repositório
	Reiniciar alterações no repositório interno	Administração, Gerir repositório
	Ver localização do repositório principal	Administração, Acessar repositório, Utilizador avançado, Gerir repositório
	Atualizar o repositório interno	Administração, Gerir repositório
Privilégios para todo o site	Utilizar a interface de gestão
	Adicionar novos projetos
	Adicionar definições de idioma
	Gerir definições de idioma
	Manage teams
	Gerir utilizadores
	Gerir funções
	Gerir anúncios
	Gerir a memória de tradução
	Gerir tradução automática
	Gerir as listas de componentes

Nota

Privilégios para todo o site não são concedidos a nenhuma função padrão. Eles são poderosos e muito próximos do estado de superutilizador. A maioria deles afetam todos os projetos da sua instalação do Weblate.

List of teams

The following teams are created upon installation (or after executing setupgroups) and you are free to modify them. The migration will, however, re-create them if you delete or rename them.

Convidados

Define permissões para utilizadores não autenticados.

This team only contains anonymous users (see ANONYMOUS_USER_NAME).

You can remove roles from this team to limit permissions for non-authenticated users.

Funções predefinidas: Adicionar sugestão, Acessar repositório

Visualizadores

This role ensures visibility of public projects for all users. By default, all users are members of this team.

By default, automatic team assignment makes all new accounts members of this team when they join.

Funções predefinidas: nenhuma

Utilizadores

Default team for all users.

By default, automatic team assignment makes all new accounts members of this team when they join.

Funções predefinidas: Utilizador avançado

Revisores

Grupo para revisores (consulte Fluxos de trabalho de tradução).

Funções predefinidas: Revisar cadeias

Gestores

Grupo pra administradores.

Funções predefinidas: Administração

Aviso

Never remove the predefined Weblate teams and users as this can lead to unexpected problems! If you have no use for them, you can removing all their privileges instead.

Restrições adicionais de acesso

Se quer usar a instalação do Weblate de forma menos pública, ou seja, permitir novos utilizadores apenas por convite, isso pode ser feito configurando o Weblate para que apenas utilizadores conhecidos tenham acesso a ele. Para fazer isso, pode definir REGISTRATION_OPEN para False para prevenir registos de quaisquer novos utilizadores e definir REQUIRE_LOGIN para /.* para exigir login para acessar todas as páginas do site. Assim terá o seu Weblate privado.

Dica

Pode usar Novo convite de utilizador para adicionar novos utilizadores.