Configurações do Projeto
As Configurações do Projeto são o centro de controle de cada projeto no Axoria. Aqui você define como o fluxo de trabalho funciona, quem pode fazer o quê, quais regras são aplicadas e como o sistema se comporta. Todas as regras configuradas nesta área são verificadas e impostas pelo backend - nenhuma alteração de papel ou campo no frontend é suficiente para contorná-las.
Acesse as configurações pelo menu ⚙️ Configurações na barra lateral esquerda do projeto.
Quem Pode Acessar as Configurações
O acesso às configurações é restrito e verificado a cada requisição:
| Quem | Condição |
|---|---|
| Owner da organização | Acesso total a qualquer projeto da org |
| Admin da organização | Acesso total a qualquer projeto da org |
Membro com permissão MANAGE_PROJECTS |
Pode configurar qualquer projeto (via Grupo de Perfil) |
Membro com papel PROJECT_ADMIN |
Pode configurar somente o projeto ao qual pertence |
| DEVELOPER / REPORTER / VIEWER | Sem acesso às configurações - somente board e backlog |
Como a regra é imposta: Todas as verificações de acesso são realizadas no servidor a cada requisição. Usuários que não satisfazem nenhuma das condições acima recebem HTTP 403. A interface oculta os menus de configuração correspondentes, mas o backend é a camada de controle definitiva.
Configurações Gerais
Onde: Configurações → Geral
Defina as informações básicas e o comportamento de visibilidade do projeto.
| Campo | Tipo | Descrição |
|---|---|---|
| Nome | Texto | Nome exibido na interface, relatórios e breadcrumbs. Obrigatório. |
| Descrição | Texto | Descreve o propósito do projeto. Opcional. |
| Tipo | Enum | SOFTWARE, BUSINESS, KANBAN, SCRUM ou CUSTOM |
| Visibilidade | Enum | PRIVATE, INTERNAL ou PUBLIC (veja abaixo) |
| Avatar | Imagem ou ícone | Ícone embutido (FontAwesome) ou imagem enviada por upload |
Regras de Visibilidade
| Valor | Comportamento |
|---|---|
PRIVATE |
Apenas membros cadastrados no projeto têm acesso |
INTERNAL |
Qualquer membro da organização pode visualizar o projeto |
PUBLIC |
Qualquer pessoa com a URL pode visualizar (sem autenticação) |
A visibilidade
PUBLICexpõe apenas a leitura - operações de escrita continuam exigindo autenticação e papel adequado.
Chave do Projeto (key)
A chave (key) é definida na criação do projeto (ex.: SHOP, API). Ela compõe os identificadores das issues (SHOP-1, API-42). A chave não pode ser alterada após a criação.
Regras da chave: 2 a 10 caracteres, somente letras maiúsculas e números ([A-Z0-9]).
Board
Onde: Configurações → Board
O Board é o quadro visual de acompanhamento das issues. Cada projeto pode ter múltiplos boards, mas apenas um board ativo por vez.
Criando e Ativando um Board
- Clique em + Criar Board e informe o nome e o tipo (
KANBANouSCRUM). - Para definir qual board é exibido, clique em Ativar. Ativar um board desativa automaticamente o anterior.
Modos de Visualização
Cada board pode habilitar um ou mais modos de visualização:
| Modo | Descrição |
|---|---|
KANBAN |
Quadro visual por colunas - sempre incluído, não pode ser removido |
TABLE |
Lista tabular de issues com colunas ordenáveis |
CALENDAR |
Visualização por data de vencimento no calendário |
Configure em Configurações → Board → [board] → Editar Views.
Colunas
Onde: Configurações → Board → Colunas
As colunas representam as etapas do fluxo. Cada issue ocupa uma coluna de acordo com seu status.
| Campo | Tipo | Descrição |
|---|---|---|
| Nome | Texto | Rótulo exibido no board (máx. 100 chars) |
| Tipo | Enum | TODO, IN_PROGRESS ou DONE |
| Limite WIP | Inteiro | Máximo de issues simultâneas na coluna. 0 ou null = sem limite |
| Mapeamento de Status | Texto | Nome do status do Workflow que esta coluna representa |
| Ordem | Inteiro | Posição no board (arraste para reordenar) |
Por que usar o limite WIP?
O WIP (Work in Progress) Limit impede sobrecarga em uma etapa do fluxo. Quando a coluna atingir o limite, nenhuma issue pode ser movida para ela até que outra seja concluída.
Como é imposto: O backend valida o limite WIP a cada movimentação de status. Se a coluna de destino estiver cheia, a operação é rejeitada com HTTP 400 e uma mensagem descritiva.
Transições
Onde: Configurações → Board → Transições
As transições definem quais movimentos entre colunas (status) são permitidos.
| Campo | Tipo | Descrição |
|---|---|---|
| Nome | Texto | Rótulo descritivo da transição |
| De | Status (nullable) | Status de origem. Se null = aceita qualquer status como origem |
| Para | Status | Status de destino obrigatório |
Comportamento padrão
Se não houver transições definidas no workflow padrão, qualquer mudança de status é permitida.
Se transições estiverem definidas, apenas os movimentos explicitamente configurados são permitidos.
Como é imposto: O backend valida cada alteração de status contra as transições configuradas. Se o movimento não for permitido, a operação é rejeitada com HTTP 400.
Exemplo prático: Para impedir que issues pulem de To Do diretamente para Done, crie transições explícitas apenas entre etapas consecutivas (ex.: TODO → IN_PROGRESS, IN_PROGRESS → REVIEW, REVIEW → DONE).
Workflows e Status
Onde: Configurações → Workflow
O Workflow define os status disponíveis no projeto. Cada issue possui um status pertencente ao workflow padrão ativo.
Múltiplos Workflows
Você pode criar múltiplos workflows (ex.: um para bugs, outro para features), mas apenas um workflow pode ser marcado como padrão. Ao marcar um workflow como padrão, o sistema automaticamente desmarca o anterior.
Criando/Editando um Workflow
| Campo | Tipo | Descrição |
|---|---|---|
| Nome | Texto | Nome interno do workflow (máx. 100 chars) |
| Descrição | Texto | Descrição opcional (máx. 500 chars) |
| Padrão | Boolean | Marca como workflow ativo do projeto |
Status do Workflow
Cada workflow possui uma lista de status:
| Campo | Tipo | Descrição |
|---|---|---|
| Nome | Texto | Rótulo do status (máx. 100 chars) |
| Cor | Hex | Cor de destaque do status (ex.: #3fb950) |
| Categoria | Enum | TODO, IN_PROGRESS ou DONE - usada para relatórios e filtros |
| Posição | Inteiro | Ordem de exibição |
Por que a categoria importa? A categoria é usada para calcular taxa de conclusão de sprints, gráficos de burndown e contagem de issues concluídas nos relatórios.
Schema de Campos
Onde: Configurações → Schema de Campos
O Schema de Campos define campos customizados que aparecem no painel de cada issue. Você pode criar múltiplos schemas e associá-los a tipos de issue específicos.
Criando um Schema
| Campo | Tipo | Descrição |
|---|---|---|
| Nome | Texto | Identificação do schema (máx. 150 chars) |
| Descrição | Texto | Opcional (máx. 500 chars) |
| Tipos de Issue | Lista | Se preenchido, o schema aparece apenas para esses tipos. Se vazio, aplica-se a todos |
| Ativo | Boolean | Schemas inativos não são exibidos nas issues |
Tipos de Campo Disponíveis
| Tipo | Uso |
|---|---|
TEXT |
Texto curto de uma linha |
TEXTAREA |
Texto longo, múltiplas linhas |
NUMBER |
Valor numérico |
DATE |
Seletor de data |
SELECT |
Seleção única entre opções pré-definidas |
MULTISELECT |
Seleção múltipla entre opções |
CHECKBOX |
Valor booleano (marcado/desmarcado) |
USER |
Referência a um usuário do projeto |
LABEL |
Rótulo/tag livre |
Campos Customizados
Cada campo dentro de um schema possui:
| Campo | Descrição |
|---|---|
| Nome | Rótulo exibido no painel (displayName) |
| Chave | Identificador técnico único no schema (fieldKey) |
| Tipo | Um dos tipos listados acima |
| Obrigatório | Se marcado, a issue não pode ser salva sem este campo preenchido |
| Padrão | Valor pré-preenchido ao criar uma nova issue |
| Opções | Lista de valores possíveis (somente SELECT/MULTISELECT) |
| Posição | Ordem de exibição no painel |
Painel de Issue
Onde: Configurações → Painel de Issue
Define como o painel de detalhes de uma issue é exibido ao clicar nela.
| Modo | Descrição |
|---|---|
OFFCANVAS |
Painel deslizante lateral (padrão) |
MODAL |
Janela modal centralizada |
PAGE |
Página dedicada (URL própria) |
Além do modo, é possível configurar o parâmetro width para os modos OFFCANVAS e MODAL, aceito nos formatos px, em, rem e % (ex.: 560px, 80%).
Quem pode alterar: somente membros com acesso às configurações (
PROJECT_ADMIN, org Owner/Admin). Membros comuns podem visualizar o painel mas não alterar seu modo.
Tipos de Issue
Onde: Configurações → Tipos de Issue
Os tipos de issue categorizam o trabalho. O Axoria inclui 10 tipos padrão + CUSTOM:
| Tipo | Ícone padrão | Cor padrão | Hierarquia |
|---|---|---|---|
EPIC |
fa-bolt |
#a371f7 |
EPIC |
STORY |
fa-book-open |
#3fb950 |
STANDARD |
TASK |
fa-square-check |
#58a6ff |
STANDARD |
BUG |
fa-bug |
#f85149 |
STANDARD |
SUBTASK |
fa-circle-dot |
#7d8590 |
SUBTASK |
IMPROVEMENT |
fa-arrow-trend-up |
#a5a5ff |
STANDARD |
SPIKE |
fa-bolt-lightning |
#ffd43b |
STANDARD |
RESEARCH |
fa-magnifying-glass |
#4dabf7 |
STANDARD |
HOTFIX |
fa-fire |
#ff6b6b |
STANDARD |
TECHNICAL_DEBT |
fa-gauge-high |
#adb5bd |
STANDARD |
Personalizando Tipos
Para cada tipo você pode alterar:
- Nome de exibição (
displayName) - o que aparece na interface - Ícone - qualquer classe FontAwesome
- Cor - valor hexadecimal (
#RRGGBB) - Nível de hierarquia -
EPIC,STANDARDouSUBTASK - Ativo / Inativo - tipos inativos não aparecem ao criar issues
Como a Regra é Imposta
Se uma issue tiver seu tipo alterado para um tipo inativo, o backend recusa a operação com HTTP 400.
Prioridades
Onde: Configurações → Prioridades
As prioridades indicam a urgência de cada issue. O sistema inclui 5 prioridades padrão:
| Prioridade | Cor padrão | Ícone padrão |
|---|---|---|
CRITICAL |
#f03e3e |
fa-angles-up |
HIGH |
#fd7e14 |
fa-angle-up |
MEDIUM |
#f59f00 |
fa-equals |
LOW |
#40c057 |
fa-angle-down |
TRIVIAL |
#868e96 |
fa-angles-down |
Personalizando Prioridades
Para cada prioridade você pode alterar nome de exibição, cor, ícone e ordem (sortOrder). Prioridades podem ser habilitadas ou desabilitadas.
Como a Regra é Imposta
Se uma issue tiver sua prioridade alterada para uma desabilitada, o backend recusa com HTTP 400.
Esquemas
Onde: Configurações → Esquemas
Um Esquema é um pacote de configuração que une três elementos em uma estrutura reutilizável:
- Board - qual board está ativo para este esquema
- Workflow - qual workflow de status é usado
- Schema de Campos - quais campos customizados são exibidos
Apenas um esquema pode estar ativo por vez. Ativar um esquema desativa automaticamente o anterior.
Layout do Cartão (CardLayoutSettings)
Cada esquema também controla quais informações aparecem nos cartões do board:
| Campo | Padrão | Descrição |
|---|---|---|
showPriority |
true |
Exibe ícone de prioridade no cartão |
showStoryPoints |
true |
Exibe estimativa de story points |
showAssignee |
true |
Exibe avatar do responsável |
showLabels |
true |
Exibe etiquetas |
showDueDate |
false |
Exibe data de vencimento |
showType |
true |
Exibe ícone do tipo de issue |
Por que usar Esquemas?
Esquemas permitem alternar rapidamente entre configurações distintas sem recriar boards e workflows. Exemplo: um esquema "Sprint Ativo" com board SCRUM e outro esquema "Kanban Contínuo" com board KANBAN - troque com um clique.
Regras de Notificação
Onde: Configurações → Notificações
As regras de notificação determinam quem é notificado, como e quando algo acontece no projeto.
Eventos Disponíveis
| Evento | Quando é acionado |
|---|---|
ISSUE_CREATED |
Nova issue criada no projeto |
ISSUE_UPDATED |
Campos de uma issue foram editados |
ISSUE_ASSIGNED |
Issue atribuída ou reatribuída a um membro |
COMMENT_ADDED |
Comentário adicionado a uma issue |
STATUS_CHANGED |
Status de uma issue foi alterado |
SPRINT_STARTED |
Uma sprint foi iniciada |
SPRINT_COMPLETED |
Uma sprint foi encerrada |
MENTION |
Um membro foi mencionado com @ em uma issue ou comentário |
Canal de Notificação
| Canal | Descrição |
|---|---|
IN_APP |
Notificação visível no sino 🔔 dentro do Axoria |
Envio de e-mails pode ser configurado por meio de Automações (
send_email). Webhooks são um sistema separado de notificações in-app.
Destinatários
Os destinatários podem ser definidos como:
| Token | Quem recebe |
|---|---|
ASSIGNEE |
Responsável(is) pela issue |
REPORTER |
Quem reportou a issue |
ALL_MEMBERS |
Todos os membros do projeto |
| UUID de usuário | Membro específico pelo ID |
Criando uma Regra
Vá em Configurações → Notificações → + Nova Regra e defina:
- O evento que dispara a notificação
- O canal de entrega
- Os destinatários
- Se a regra está ativa
Uma regra inativa é preservada mas não dispara notificações.
Webhooks
Onde: Configurações → Webhooks
Os Webhooks são distintos das Regras de Notificação. Enquanto as regras gerenciam notificações internas (IN_APP), os Webhooks enviam payloads assinados para endpoints externos (ex.: Slack, sistemas de CI/CD, pipelines próprios).
| Campo | Descrição |
|---|---|
| Nome | Identificação do webhook |
| URL | Endpoint que receberá as requisições HTTP POST |
| Secret Token | Chave usada para assinar o payload com HMAC-SHA256 |
| Eventos | Conjunto de eventos subscritos |
| Ativo | Ligar/desligar sem excluir |
Segurança dos Webhooks
Cada requisição é assinada com HMAC-SHA256 usando o secretToken configurado. O endpoint receptor deve validar a assinatura antes de processar o payload.
Membros do Projeto
Onde: Configurações → Membros
Gerencie quem tem acesso ao projeto e com qual papel.
Papéis do Projeto
| Papel | Permissões |
|---|---|
PROJECT_ADMIN |
Controle total do projeto: configurações, membros, board, issues |
DEVELOPER |
Criar, editar e mover issues; visualizar configurações (sem alterar) |
REPORTER |
Criar issues e comentar; não pode mover ou excluir |
VIEWER |
Somente leitura: visualiza issues e board sem poder editar |
Adicionando um Membro
- Clique em + Adicionar Membro
- Informe o e-mail do usuário
- Selecione o papel (padrão:
DEVELOPER) - Confirme
Se o usuário já for membro do projeto, a operação retorna erro
409 CONFLICT.
Alterando o Papel
Um membro com acesso às configurações pode alterar o papel de qualquer membro via o menu de ação ao lado de cada membro na lista.
Removendo um Membro
Clique em Remover ao lado do membro. A remoção revoga o acesso imediatamente. Issues já atribuídas ao membro não são reatribuídas automaticamente.
Quem pode gerenciar membros: org Owner/Admin, membro com MANAGE_PROJECT_MEMBERS, ou membro com PROJECT_ADMIN no projeto.
Anexos
Onde: Configurações → Anexos
Controle se as issues do projeto aceitam arquivos anexados.
| Configuração | Padrão | Descrição |
|---|---|---|
| Anexos habilitados | true |
Liga/desliga uploads de arquivos nas issues |
| Máximo por issue | 4 |
Entre 1 e 20. Limite de arquivos por issue |
Regras de Upload
- Apenas arquivos de imagem são aceitos (PNG, JPG, GIF, WebP)
- Tamanho máximo por arquivo: 5 MB
- Se
attachmentsEnabled = false, qualquer tentativa de upload retornaHTTP 403 - Se o limite for atingido, o upload é recusado com
HTTP 400
Tokens Públicos
Onde: Configurações → Tokens Públicos
Os Tokens Públicos permitem compartilhar uma visão somente-leitura do board ou de relatórios com pessoas que não têm conta no Axoria.
| Campo | Descrição |
|---|---|
| Tipo | BOARD (board específico) ou REPORT (relatórios do projeto) |
| Token | String segura de 64 caracteres gerados com SecureRandom |
| Expira em | Data de expiração opcional. null = nunca expira |
| Ativo | O token pode ser desativado sem ser excluído |
| Filtros | Filtros opcionais aplicados à view pública (ex.: sprint específica) |
Gerando um Token
- Vá em Configurações → Tokens Públicos
- Clique em + Gerar Token
- Selecione o tipo (
BOARDouREPORT) e o recurso alvo - Defina expiração (opcional)
- Copie a URL pública gerada
Segurança
- Nenhum UUID interno ou dado sensível é retornado na resposta pública
- Revogar um token invalida imediatamente todos os acessos com aquele link
Zona de Perigo
Onde: Configurações → Zona de Perigo
Arquivar Projeto
Arquivar um projeto muda seu status para ARCHIVED. Projetos arquivados:
- Não aparecem na listagem padrão de projetos
- Mantêm todos os dados preservados (issues, sprints, attachments)
- Podem ser desarquivados por um Owner/Admin
Quem pode arquivar: org Owner/Admin, membro com MANAGE_PROJECTS, ou PROJECT_ADMIN do projeto.
⚠️ Excluir um projeto é uma operação irreversível. Todos os dados são permanentemente removidos. Exporte os dados antes de prosseguir.
Resumo de Quem Pode Fazer o Quê
| Ação | Viewer | Reporter | Developer | PROJECT_ADMIN | Org Owner/Admin |
|---|---|---|---|---|---|
| Ver board e issues | ✅ | ✅ | ✅ | ✅ | ✅ |
| Criar issues | ❌ | ✅ | ✅ | ✅ | ✅ |
| Editar e mover issues | ❌ | ❌ | ✅ | ✅ | ✅ |
| Gerenciar membros | ❌ | ❌ | ❌ | ✅ | ✅ |
| Acessar configurações | ❌ | ❌ | ❌ | ✅ | ✅ |
| Criar/editar colunas | ❌ | ❌ | ❌ | ✅ | ✅ |
| Configurar workflows | ❌ | ❌ | ❌ | ✅ | ✅ |
| Gerenciar tipos/prioridades | ❌ | ❌ | ❌ | ✅ | ✅ |
| Gerar tokens públicos | ❌ | ❌ | ❌ | ✅ | ✅ |
| Arquivar projeto | ❌ | ❌ | ❌ | ✅ | ✅ |
Membros com permissões via Grupo de Perfil da organização (
MANAGE_PROJECTS,MANAGE_BOARDS, etc.) podem ter acesso ampliado sem serPROJECT_ADMIN.
Configurações Gerais
| Campo | Descrição |
|---|---|
| Nome | Nome exibido na interface e nos relatórios |
| Descrição | Texto descritivo sobre o propósito do projeto |
| Tipo | Software, Business ou Marketing |
| Visibilidade | Privado, Público na Org ou Público |
| Avatar | Ícone embutido ou imagem personalizada do projeto |
Configuração do Board
Colunas
Gerencie as colunas do Kanban em Configurações → Board → Colunas:
| Campo | Descrição |
|---|---|
| Nome | Rótulo exibido no board |
| Tipo | TODO, IN_PROGRESS, DONE ou CANCELLED |
| Limite WIP | Máximo de issues simultâneas (0 = sem limite) |
| Ordem | Arraste para reordenar as colunas no board |
Clique em + Adicionar Coluna para criar uma nova etapa no fluxo.
Transições
As transições definem quais movimentos entre colunas são permitidos. Acesse em Configurações → Board → Transições.
Por padrão, todas as transições são permitidas. Restrinja-as para impor passos obrigatórios no fluxo (ex.: impedir que uma issue vá de TODO diretamente para DONE sem passar por IN_PROGRESS).
Workflow e Status
O Workflow define os status disponíveis no projeto, cada um associado a uma coluna do board.
Em Configurações → Workflow:
- Visualize todos os status e suas colunas associadas
- Adicione, renomeie ou remova status
- Defina o status padrão para novas issues
Schema de Campos
O Schema de Campos define campos customizados visíveis no painel de cada issue. Acesse em Configurações → Schema de Campos.
Campos disponíveis:
- Texto livre
- Número
- Data
- Seleção única
- Seleção múltipla
Configure a visibilidade de cada campo padrão e customizado em Configurações → Painel de Issue.
Tipos de Issue
Configure as categorias de issue em Configurações → Tipos de Issue:
- Crie tipos com nome e ícone personalizados
- Defina o tipo padrão para novas issues
- Reordene ou desative tipos existentes
Prioridades
Configure os níveis de urgência em Configurações → Prioridades:
- Nome e cor de cada nível de prioridade
- Ordem de exibição nos filtros e formulários
- Prioridade padrão para novas issues
Esquemas
Os Esquemas permitem criar e reutilizar configurações de tipos e campos entre projetos. Acesse em Configurações → Esquemas.
Notificações
Configure regras de notificação por evento do projeto em Configurações → Notificações.
Eventos Disponíveis
| Evento | Quando é acionado |
|---|---|
| ISSUE_CREATED | Nova issue criada no projeto |
| ISSUE_UPDATED | Issue editada |
| ISSUE_ASSIGNED | Issue atribuída a um membro |
| COMMENT_ADDED | Comentário adicionado a uma issue |
| STATUS_CHANGED | Status da issue alterado |
| SPRINT_STARTED | Sprint iniciada |
| SPRINT_COMPLETED | Sprint completada |
| MENTION | Membro mencionado em uma issue |
Canal de Notificação
| Canal | Descrição |
|---|---|
| IN_APP | Notificação interna na interface do Axoria |
Envio de e-mails pode ser configurado por Automações. Webhooks são um sistema separado.
Destinatários
| Token | Quem recebe a notificação |
|---|---|
| ASSIGNEE | Todos os assignees da issue |
| REPORTER | Quem criou a issue |
| ALL_MEMBERS | Todos os membros do projeto |
Criando uma Regra
- Acesse Configurações → Notificações → Nova Regra.
- Selecione o evento, canal e destinatários.
- Ative a regra com o toggle e salve.
Webhooks
Webhooks permitem integrar o Axoria com sistemas externos como Slack, Discord, pipelines de CI/CD, etc.
- Acesse Configurações → Webhooks → Adicionar Webhook.
- Informe a URL de destino (HTTPS recomendado).
- Selecione os eventos que acionam o webhook.
- Salve.
O payload é um JSON com detalhes do evento ocorrido.
Configurações de Anexo
Controle os anexos de issue em Configurações → Anexos:
| Campo | Padrão | Intervalo |
|---|---|---|
| Ativar Anexos | Sim | - |
| Máximo por issue | 3 | 1–20 |
Apenas imagens (PNG, JPG, GIF, WebP) são aceitas. Tamanho máximo: 5 MB por arquivo.
Tokens Públicos
Tokens Públicos permitem compartilhar o board ou o relatório do projeto com pessoas sem conta no Axoria.
- Acesse Configurações → Tokens Públicos → Gerar Token.
- Selecione o tipo: Board ou Relatório.
- Opcionalmente defina uma data de expiração.
- Copie e compartilhe o link gerado.
Para revogar o acesso, clique em Revogar ao lado do token. O link para de funcionar imediatamente.