Integração nativa com o Jira: Guia de configuração
Importante saber antes da configuração da integração com o Jira
Pré-requisitos de configuração
Para um teste básico, precisamos saber as seguintes informações do lado do cliente:
- Usuário do serviço Jira e método de autenticação escolhido
- API REST do Jira URL
- Navegação no Jira Server URL (opcional para o Jira Servers)
- Configuração de webhooks
- IPs de processos-alvo, solicitações de API e cabeçalhos são adicionados à lista de permissões
Cada um desses pontos é descrito em detalhes a seguir.
Usuário, permissão e autenticação do serviço Jira
Autenticação de usuários e processos-alvo do Jira Service
Para autorizar todas as ações do Targetprocess no Jira. O nome do usuário aparecerá nos registros e no histórico da ACTIVITY, e o usuário será o autor de todas as alterações no Jira, acionadas pela integração (adicionar comentário, alterar estado e outros campos).
Recomendamos ter um usuário de serviço dedicado à integração do Targetprocess. Um usuário dedicado evita problemas de conexão e interrupções de integração quando o Jira é configurado para solicitar CAPTCHA após várias tentativas fracassadas de login. Se outra pessoa estiver usando as mesmas credenciais de usuário do Jira, o bloqueio do CAPTCHA poderá ser ativado e a integração não conseguirá sincronizar os dados, a menos que o CAPTCHA seja resolvido pelo usuário.
Credenciais do usuário do serviço Jira para autenticar o Targetprocess
- O acesso para adicionar/editar/excluir todos os tipos de problemas, comentários, anexos e em todos os projetos será sincronizado com o Targetprocess.
- "Gerenciar sprints" (se as iterações da equipe forem sincronizadas com os sprints do Jira)
- O Global Admin (com permissão para solicitar "editar fluxo de trabalho") é necessário se o cliente solicitar mapeamentos automáticos contínuos de estados (se os nomes corresponderem, mas as transições não, o usuário de integração com uma permissão de Global Admin poderá calcular as transições e aplicar qualquer uma das disponíveis)
- a permissão "Editar comentários" é necessária se a sincronização de comentários for solicitada (permissão para editar comentários publicados por outros usuários do Jira).
Conjunto de dados do Jira para teste (projeto Jira para piloto)
Para fins de configuração e teste de integração, você desejará um acesso (UI) ao projeto de teste no Jira permitido para testes - adicionar ou alterar problemas, gerenciar sprints, procurar problemas no projeto, postar comentários, anexos etc. OU mapeamentos de POC reais de PSs
Obter URL para Jira Rest API
A navegação no Jira Server URL (para usuários e acesso à interface do usuário) pode ser diferente da API do Jira Rest URL.
Para que o perfil de integração seja configurado, você precisa da API URL. Se os usuários do Jira navegarem por um site diferente URL, ele deverá ser fornecido no perfil para que os links adequados para os problemas do Jira sejam gerados no Targetprocess.
Configuração dos webhooks do Jira
O webhook do Jira precisa ser configurado para cada perfil de integração. É necessária a assistência do Jira Administrator.
Normalmente, o administrador do Jira de um cliente tem acesso a essa parte da configuração do Jira, portanto, precisamos solicitar que ele adicione um webhook e o adicione a cada novo perfil. As configurações do webhook estão todas nas instruções do perfil (diferentes para Server e Cloud em termos de Attachments)
Se estiver usando roteiros dinâmicos, talvez seja melhor adicionar um filtro JQL ao Jira e excluir alguns projetos se for sabido que eles não se integrarão ao Targetprocess. Caso contrário, todos os eventos de projetos não integrados serão transmitidos e aparecerá um erro mostrando que o roteamento de destino não foi encontrado.
Todos os outros filtros JQL no webhook devem ser evitados, pois o Jira tem defeitos comuns com as reações de postagem a alguns eventos quando os filtros são aplicados.
A integração não funcionará se o webhook for definido com o corpo excluído. Precisamos receber um JSON.
Lembre-se de atualizar os webhooks no Jira se a conta do Targetprocess mudar seu endereço URL.
Acessibilidade do Jira para solicitações da Targetprocess
- O Jira deve estar disponível para solicitações de API do Targetprocess.
- A permissão de IPs de processo-alvo pode ser necessária no lado do cliente. O processo geral é o seguinte:
- A linha está disponível em https://community.ibm.com/community/user/apptio/blogs/apptio-community-member/2023/01/16/targetprocess-public-ips-range?CommunityKey=55a3712d-1835-4ec2-bcd7-603e88cd9dd2
- Se um cliente ainda não tiver acesso à comunidade, ele poderá solicitar o acesso aqui: https://community.apptio.com/home/request-community-access
- Um cliente permite todo o intervalo de IPs. IPs únicos não são mais fornecidos.
- Um cliente está inscrito nesta página (botão `Follow`)
- Quando o IP está prestes a ser alterado, a equipe de suporte modifica o intervalo de IPs na página da comunidade
- Os clientes inscritos recebem uma notificação e também adicionam esse novo IP
Ativar/desativar recurso
- Importação inicial do Jira. Comentários com o link de retorno para o Targetprocess serão adicionados a cada problema do Jira durante a importação, o que gera várias notificações por e-mail para os usuários do Jira. Considere a possibilidade de desativar o recurso de alternância que adiciona o link à entidade Targetprocess como um comentário no Jira. Habilite-o após a importação, se o link da entidade Targetprocess não for mapeado para o campo personalizado do Jira.
WorkSharing:Linking:SkipComment
- A sincronização da operação de exclusão é desativada por padrão em todos os clusters. No entanto, se um novo cluster privado for adicionado a um cliente, verifique se a sincronização de exclusão ainda está desativada e se WorkSharing:DisableDeleteOppositeEntity está ativado
WorkSharing:DisableDeleteOppositeEntity
- Alguns campos não podem ser sincronizados em um único sentido:
- Ações como Excluir e Converter sincronizam bidirecionalmente por padrão quando a alternância de recursos WorkSharing:DisableDeleteOppositeEntity está desativada. A sincronização bidirecional padrão de Excluir ou Converter pode ser configurada de forma personalizada com as regras de automação. (As regras podem ser encontradas na biblioteca. Em fevereiro de 2023, as amostras serão publicadas no site dev.targetprocess.com )
- As coleções e relações mapeadas e vinculadas são sincronizadas bidirecionalmente e ainda não puderam ser configuradas para sincronização unidirecional. Por exemplo, os Épicos do Jira são mapeados para Recursos, Histórias para Histórias de Usuário (coleções secundárias) e todos os outros tipos como Relações regulares. No momento, não é possível limitar a direção da sincronização de relações e sincronizar apenas histórias do Targetprocess e bugs apenas do Jira. As relações são sincronizadas em ambos os sentidos, os campos são sincronizados na direção selecionada. Lembre-se de que os roteiros de projeto regulam a criação de novos problemas e não afetam a sincronização de campos.
Mapeamentos
A configuração da integração está disponível apenas para os administradores do Targetprocess em Configurações > Integrações.
Toda integração requer um perfil de integração no qual todas as regras de sincronização são definidas. Um perfil pode ser conectado a uma única instância do Jira / ADO / Targetprocess.
- Um perfil pode trabalhar com uma instância do Jira.
- Os departamentos (unidade, equipe) são independentes, os problemas de trabalho entre os departamentos não têm relação entre si e, ao mesmo tempo, os fluxos de trabalho são muito diferentes. Fluxos de trabalho diferentes significam mapeamentos de tipos/campos diferentes. Para facilitar a manutenção do mapeamento, divida essas unidades de negócios em perfis separados.
Ainda não há suporte para relações entre perfis
Ativar com alternância de recursos na página de infraestrutura.
WorkSharing:MultiSharing WorkSharing:Jira:SkipIntegrationUserEvents
Uma entidade pai Targetprocess pode ser compartilhada entre várias instâncias do Jira com diferentes perfis de integração. Isso significa que todas as propriedades, inclusive as coleções filhas, serão compartilhadas em todas as instâncias. Para manter os itens filhos em seu Jira dedicado e evitar o envio automático para outras instâncias do Jira, aplique filtros nos Roteiros para tipos específicos de entidades.
Não é possível o compartilhamento múltiplo de uma entidade em um perfil de integração.
O envio em lote para o Jira é compatível apenas com o primeiro perfil correspondente.
Roteiros
Os roteiros não afetam a sincronização de pares existentes, eles regulam a criação inicial de um par de problemas sincronizados.
Se um problema foi enviado ao Jira para um projeto A e, em seguida, os roteiros foram atualizados para excluir o projeto A de outras sincronizações, isso significa que você não poderá enviar/puxar problemas de/para esse projeto. Mas os itens que foram enviados e vinculados anteriormente continuarão a ser sincronizados, desde que os mapeamentos de tipos e campos sejam válidos.
Roteiros estáticos
Os roteamentos estáticos significam casos simples, quando o seletor de projetos é usado em mapeamentos e mapeamos projetos/equipes do Targetprocess para projetos do Jira.
Todo roteamento estático tem filtros adicionais. Com esses filtros, você define quais condições devem ser atendidas para sincronizar o problema de/para o Jira/Targetprocess.
Roteamentos JS avançados para mapeamento dinâmico
Este é um código JS para definir condições de mapeamentos de escopo. Nós o usamos para casos complicados, quando o projeto de destino pode ser diferente dependendo dos valores de determinados campos. Biblioteca com exemplos
Por exemplo:
- Targetprocess O Portfolio Epic contém trabalho que cria um projeto separado no Jira, o mapeamento não é projeto para projeto, mas Portfolio Epic para Projeto Jira. Em seguida, adicionamos o CF "Jira Project Key" ao Portfolio Epic e calculamos o projeto Jira de destino para todos os itens filhos com base nessa abreviação no Portfolio Epic. Exemplo.
- O projeto no Targetprocess dependerá do valor do campo selecionado no Jira ou vice-versa - a entidade do Targetprocess sincroniza com o projeto do Jira com base no campo personalizado, selecionado no nível pai.
- Além disso, qualquer conjunto sofisticado de filtros e condições adicionais, como "extrair entidades filhas se o próprio projeto for igual ao projeto pai". Exemplo.
Envio automático / Recebimento automático
Ambos os tipos de roteamento, estático e dinâmico, têm opções para puxar ou empurrar cartões automaticamente.
Com o envio automático ativado, todas as entidades do Targetprocess serão enviadas para o Jira assim que forem adicionadas ou modificadas e passarem pelo filtro nos roteiros. A entidade é enviada para o Jira como nova.
Se você precisar vincular itens do Targetprocess a problemas existentes no Jira, a extração automática deverá ser desativada. Como solução alternativa, você pode desvincular a entidade Targetprocess de seu problema do Jira e vinculá-la novamente a outro problema do Jira. A menos que seja atualizado por algum outro serviço ou usuário que acione o envio automático novamente.
Recomendamos ativar a extração automática e extrair os problemas do Jira automaticamente se você quiser que todos os problemas sejam sincronizados imediatamente, assim que forem atualizados ou criados e corresponderem aos filtros de sincronização.
Não é possível extrair cartões do Jira manualmente além da importação.
A opção Auto-pull agora está ativada por padrão ao criar novos roteiros. Esse aprimoramento economiza tempo e reduz o comportamento inesperado da sincronização, pois o Auto-pull é essencial para a maioria dos cenários de sincronização de produção.
Mapeamentos de tipos de entidades
Qualquer entidade do Targetprocess pode ser mapeada para o problema do Jira, incluindo a hierarquia de domínio extensível. Não oferecemos suporte à sincronização de casos de teste e à área de controle de qualidade devido aos vários níveis de aninhamento na hierarquia.
Se você mapear um tipo para vários tipos diferentes do outro lado, a importação inicial sempre considerará o primeiro mapeamento de tipos correspondentes. Se precisar selecionar um tipo específico, use os roteiros JS, nos quais você pode definir condições, cujos valores de campo personalizado marcarão um tipo de problema específico para importação.
Se você excluir o mapeamento de tipo em um perfil em execução, todos os problemas sincronizados por esse mapeamento serão desvinculados e deixarão de ser sincronizados.
Mapeamentos de campo
Alguns campos são suportados por padrão. Caso seja necessário algum comportamento personalizado adicional, use mapeamentos JS. Lembre-se de que os mapeamentos JS precisam de um comparador personalizado a ser adicionado para serem considerados nos relatórios de validação de dados.
- Campos simples como número/texto para número ou texto, campos de data, objeto para texto serão sincronizados por padrão.
- Se seus valores corresponderem ao nome, os seletores únicos e múltiplos serão sincronizados por padrão. Seletores com opções diferentes, não correspondentes por nome, exigem mapeamentos JS. Veja o exemplo de mapeamento de Prioridade JS.
- Mapeamentos de estados
- Por padrão, os Estados corresponderão por nome. Se os nomes não corresponderem, os estados serão combinados pelo sinalizador ‘isInitial’ ou ‘isFinal’.
- Se os nomes corresponderem, mas os fluxos de trabalho e as transições permitidas não suportarem essa transferência, serão solicitadas possíveis transições e qualquer uma adequada será aplicada, SE o usuário do serviço de integração tiver permissão de administrador global. Sem a permissão do administrador global, a pesquisa de possíveis transferências entre dois estados selecionados não é possível sem mapeamentos JS.
- Se os nomes não corresponderem, será necessário o mapeamento JS para os estados
- Targetprocess Mapeamento da equipe
- Por padrão, a equipe atribuída será sincronizada por nome com uma seleção única no Jira
- Equipe atribuída ao campo de seleção múltipla do Jira
- Componentes da equipe para o Jira
- Mapeamento de componentes
- Componentes para seleção múltipla no Targetprocess, mapeamento bidirecional com adição automática de novos componentes no Targetprocess;
- Controle de tempo
- Importe os totais de tempo real gasto/permanente como um registro único (antigo domínio Tempo) para a história de usuário, bug ou tarefa do Jira Issue Total Time Spent/Remain
- Mapeamento de usuário
No caso de mapeamento de usuários do Jira para os campos de usuário do Targetprocess, a integração criará um novo usuário do tipo de integração.
Alternância de recursos WorkSharing:UI:SyncProfile ativa a "Ressincronização de perfil" completa. Não é recomendável usá-lo para perfis de produção em execução, pois ele puxa tudo de um lado para o outro e pode resultar em perda de dados. Sugere-se usá-lo no início da implementação da conta e na atualização intensiva dos mapeamentos para extrair dados de campos recém-adicionados ao escopo de sincronização.
Importante.Tipo de usuário de integração: os usuários com a propriedade habilitada ‘isIntegration’ estão disponíveis para todas as operações como usuários regulares do Targetprocess: atribuir ao trabalho, filtrar o trabalho por usuários, etc. A diferença entre os usuários comuns e os de integração é que os últimos não podem fazer login no Targetprocess. Os usuários de integração são criados automaticamente pela integração, quando um e-mail de usuário nas atribuições é atendido e nenhuma correspondência é encontrada entre os usuários da TP existentes. Os usuários de integração podem ser adicionados manualmente por meio de solicitações de postagem da API ou importação de CSV. A licença conta os usuários de integração separadamente dos usuários comuns. Atualmente, um total de usuários de integração pode ser encontrado apenas em Account > Licenses (Conta > Licenças).
Importante. Visibilidade do e-mail no Jira Cloud: O mapeamento de usuário padrão para usuários do Jira Cloud requer visibilidade do e-mail do usuário do Jira. Com e-mails não acessíveis, use mapeamentos JS para mapear usuários por conta Jira armazenada no campo personalizado ATP.
O Jira Assignee é um campo de seleção única. A atribuição de função do processo de destino é múltipla. Por padrão, quando você atribui mais de um usuário a uma função mapeada no Targetprocess, cada usuário mais recente será sincronizado com o Jira Assignee. Quando a atribuição muda no Jira, ele redefine todas as atribuições no Targetprocess, mas o último usuário definido no Jira.
Se precisar de atribuição múltipla no Jira, use o campo Jira de seleção múltipla do tipo "Usuário
- Campo personalizado de usuário para texto
Por padrão, o e-mail será colado no campo de texto. Se você precisar do nome completo ou de qualquer outro detalhe em vez do e-mail, adicione JS ao mapeamento do campo.
Campos não suportados. Mapeamentos não recomendados
A lista será continuada assim que forem descobertos novos campos que não podem ser suportados.
- Atualizações do campo Jira Original Estimate por meio de acionadores de API e recálculo do tempo restante e do tempo gasto no Jira. Portanto, não recomendamos postar diretamente no Jira Original Estimate.
- Esforço. O campo Effort é um campo calculado no Targeprocess. Sem desativar o cálculo do esforço e redefinir seu cálculo com a métrica, ele será atualizado automaticamente com regularidade para corresponder ao esforço concluído e a ToDo. Portanto, o esforço pode ser mapeado apenas em um sentido, para mostrar o total no Jira. Mas não é recomendável extrair nenhum número do Jira para o campo Targetprocess Effort. Para trabalhar com o esforço, use os campos Esforços de função - esforço da função de desenvolvedor ou esforço do proprietário da solução. Em seguida, o esforço será calculado automática e corretamente com base no esforço dos funcionários responsáveis.
- A data de criação no Targetprocess não pode ser mapeada e definida para problemas extraídos do Jira. Primeiro, a integração cria um problema vazio e, em seguida, aplica valores de campos. A data de criação pode ser aplicada somente no momento da criação, não posteriormente. Essa alteração afetaria o desempenho, por isso sugerimos mapear a data de criação do Jira para o campo personalizado Targetprocess date.
Iterações da equipe > Jira Sprints
Há duas maneiras diferentes de sincronizar sprints e trabalhos atribuídos.
- A solução padrão recomendada é mapear e sincronizar os Sprints da equipe do Targetprocess como Sprints do Jira. À medida que você vincula a iteração da equipe a um sprint existente no Jira, ou envia como novo, as datas de início/fim, a descrição e todos os itens de trabalho mapeados serão sincronizados de e para Jira.Every. A iteração da equipe deve ser vinculada aos sprints do Jira. O sprint do Jira deve estar relacionado a um quadro. É por isso que a integração deve saber em quais projetos e diretorias podem ser criados novos sprints. Portanto, você deve mapear as equipes do Targetprocess para os quadros do Jira e todos os sprints da equipe aparecerão em um projeto e quadro selecionados. Guia do usuário final sobre como impulsionar ou vincular sprintsNota:
Somente os projetos scrum Jira podem ter sprints, e somente esses serão sugeridos nos mapeamentos Targetprocess Teams - Jira Boards. A equipe não pode ser mapeada para o quadro Kanban e o projeto.
O usuário de integração de serviços do Jira deve ter a permissão "Gerenciar Sprint" concedida no Jira
Cada nova iteração da equipe pode ser automaticamente enviada para o Jira com uma regra de automação adicional
- Qualquer mapeamento JS para sincronizar a Iteração da equipe como um campo do problema sincronizado. Nesse caso, o JS atualiza o campo sprint das entidades Jira e Targetprocess sem sincronizar as datas e a descrição do Sprint. Exemplo desse mapeamento JS
O recurso de mapeamento em massa permite que os administradores de integração mapeiem centenas de equipes para centenas de Jira Boards usando uma importação de arquivo CSV. Ele simplifica o processo de mapeamento, economizando tempo e reduzindo erros.
Como administrador de integração, se você precisar mapear 500 equipes para 500 quadros do Jira, fazer isso manualmente envolveria 500 atualizações individuais, o que poderia levar várias horas para ser concluído. No entanto, usando o recurso de mapeamento em massa, você pode fazer o download dos mapeamentos atuais, atualizar o arquivo CSV com os novos mapeamentos e, em seguida, importar o arquivo atualizado. Esse processo permite que você conclua a tarefa em uma fração do tempo.
- Baixe rapidamente o mapeamento atual do Teams para o Jira Boards em um formato de arquivo CSV.
- Amplie facilmente o mapeamento adicionando novas linhas de IDs de equipes mapeadas para IDs de Jira Boards.
- Importe o arquivo CSV atualizado para aplicar o novo mapeamento.
- (Opcional) Faça o download da lista de Jira Boards disponíveis para mapeamento.
- (Opcional) Faça o download da lista de equipes do Targetprocess.
- Faça o download do mapeamento atual do Teams-Boards como um arquivo CSV.
- Amplie o arquivo CSV Teams-Boards com os IDs das equipes e quadros correspondentes.
- Faça o upload do arquivo atualizado.
- Revise as seleções e salve as alterações no perfil. Caso contrário, verifique o console do navegador para obter mais detalhes se precisar rastrear erros.
Relações
É possível mapear e sincronizar relações entre dois problemas do Jira para o Targetprocess.
Se você navegar até a guia Relações do perfil e combinar as relações, elas começarão a ser sincronizadas e aparecerão na guia Relações em uma visualização de entidade.
Por exemplo, com o mapeamento de tipos como abaixo e as relações como acima, se o Jira Epic tiver um link do tipo "Blocks" (Bloqueios) para um Bug do Jira, e ambos os problemas do Jira forem sincronizados com o Targetprocess como Recurso e Bug apropriadamente, a relação "Blocker" (Bloqueador) será adicionada entre os itens do Targetprocess.
Aqui é onde você encontrará as relações entre dois problemas vinculados a problemas do Jira:
A relação com o problema do Jira, em que o tipo é mapeado no perfil de integração, é replicada na exibição Recurso > guia Relações.
Detalhes técnicos
Na maioria das situações, as visualizações de entidade serão personalizadas automaticamente com a guia "Trabalho sincronizado" como padrão. É a última guia na exibição. A ordem das guias pode ser alterada, se necessário, nas configurações de "Visualizações detalhadas".
Se, por algum motivo, o "Synced Work" não tiver sido adicionado automaticamente após a conclusão da configuração do perfil de integração, você poderá adicionar esse bloco manualmente
- Tabulação
{ "title": { "type": "string", "value": "Synced Work", "localize": true }, "component": { "type": "work-sharing-v2/v2", "component": "WorkSharingInfoComponentV2", "componentId": "work-sharing-v2-some" }, "componentId": "section_si4pcbc" },
- Painel lateral direito
{ "type": "work-sharing-v2/v2", "component": "WorkSharingInfoComponentV2", "componentId": "work_sharing_component" },
Se a conta tiver a personalização de visualizações desativada, o bloco "Trabalho sincronizado" será exibido no painel direito para Solicitação, Bug, Tarefa, História de usuário, Recurso, Épico, Portfólio Épico e Iteração de equipe, sem levar em conta o mapeamento de tipos no perfil.
Para tolerar mais erros, a integração primeiro cria uma entidade vazia com o nome técnico, por exemplo:
'criado pela integração em nível de problema ( 189997:10902:b523f50b-e2e1-40f6-be0f-3cf4798fc38a )'
Em seguida, esse modelo será preenchido com valores de campo, um a um, de acordo com os mapeamentos. Aqueles que não se candidatarem serão ignorados. Se você encontrar um nome de entidade "criado por integração de nível de problema (ID)", isso significa que os valores de campo ainda não foram aplicados, parcialmente ou de forma alguma.
Você pode chamar atualizações pull/push para essa entidade, se ela estiver vinculada a um problema, para atualizar os campos e verificar os logs quanto a erros reais de sincronização. Se a entidade ainda não estiver vinculada, ela poderá ser removida com segurança.
???? Devido a essa lógica, a "Data de criação" será igual à data em que o problema foi adicionado. Não é possível alterar a data de criação da entidade Targetprocess existente posteriormente.
???? Devido a essa lógica, os campos obrigatórios no Jira redefinirão seus valores padrão para os valores do Targetprocess. Se os campos mapeados no Targetprocess estiverem vazios, o valor padrão do campo do Jira será removido logo após a transferência de todos os valores de campo e a conclusão da criação do problema.
Tempo médio de sincronização
As operações de sincronização podem atrasar por diferentes motivos (a importação de um novo conjunto de problemas está em andamento, o Jira limita o acesso por algum período de tempo ou não está acessível). Para saber quanto tempo levaria para passar as alterações entre dois sistemas, você pode consultar um tempo médio de atualização. O número é aproximado e mais válido para perfis que trabalham constantemente. O tempo médio de atualização é calculado com base nas últimas 10 atualizações. É por isso que, se a última atualização tiver ocorrido ontem, você verá um horário válido para o carregamento de ontem.
O tempo médio das atualizações pode ser encontrado na lista de integrações para cada perfil em execução.
E também na visualização da entidade, abaixo dos registros:
Registros e erros
Todos os registros para integração de nível de problema podem ser encontrados em Configurações > Diagnóstico e registros > Registros de serviço. Aqui, são mostrados os registros mais completos de todos os perfis de integração nativos.
Os registros, filtrados por perfil, aparecem no painel inferior dentro de um perfil de integração, no link "View messages log" (Exibir registro de mensagens).
Erros e registros de sincronização de entidades específicas aparecem na visualização da entidade, na área "Trabalho sincronizado", se você clicar na contagem de erros ou no link "Exibir registro de mensagens".
- Se o mapeamento de tipos foi excluído enquanto o perfil estava desativado ou inacessível. Por exemplo, você vinculou vários problemas e, em seguida, excluiu os mapeamentos de tipos correspondentes do perfil. A sincronização será abortada e a regra de sincronização será excluída. Anteriormente, não excluíamos regras, portanto, itens antigos podem mostrar a seguinte mensagem. Ele não será mais sincronizado e a entidade deverá ser vinculada novamente de forma manual (desvincular + vincular ao existente ou enviar).
E, momentos depois, se você adicionar exatamente o mesmo mapeamento de tipos de volta ao perfil, esse par de itens vinculados não será corrigido automaticamente - esse mapeamento de tipos será considerado um mapeamento diferente, terá outro ID. E todos os problemas, vinculados e sincronizados anteriormente com o mapeamento de tipos excluídos, devem ser corrigidos manualmente - desvinculados do relatório de sincronização e enviados/vinculados novamente.
- Você pode ver a mensagem 'Linked issue was deleted' (O problema vinculado foi excluído) quando um dos dois problemas vinculados foi excluído enquanto o suporte a ações de exclusão/conversão estava desativado ou o perfil de integração estava desativado ou o Jira não era accessible.If. O problema do Jira foi convertido ou movido para outro projeto do Jira e sua chave e/ou tipo de problema foi alterado, então o par se torna inválido. Isso deve ser corrigido manualmente - os problemas devem ser desvinculados e enviados ou vinculados aos problemas do Jira novamente usando os mapeamentos corretos.
