Aperçu de la sécurité

En vigueur le [date de publication]

Application	TuneCraft : automatisation et nettoyage du site, une application Jira Cloud conçue sur Atlassian Forge
Fiche Marketplace	Pas encore inscrite. TuneCraft n’est pas encore sur le Marketplace d’Atlassian, et sa clé d’application sera ajoutée ici lorsqu’elle le sera.
Identifiant de l’application Forge	ari:cloud:ecosystem::app/facece90-dfd5-4792-9bff-6a5bd061a341
Éditeur	Logiciels Plugincraft inc., société constituée en vertu des lois du Québec, Canada

En bref

TuneCraft fonctionne entièrement sur Atlassian Forge. Elle ne déclare aucun accès réseau externe : vos données ne quittent donc pas Atlassian.
Jira décide qui peut faire quoi dans Jira. Les pages de l’application lisent et modifient Jira avec les droits Jira propres à la personne. Un changement à la configuration de votre Jira n’est fait que lorsqu’un administrateur Jira le confirme, et les outils de nettoyage sont réservés aux administrateurs Jira. Les tickets que l’application crée sont les avis aux propriétaires, envoyés en leur propre nom par une personne du niveau Gérer; les tickets de la page À faire, créés en tant qu’administrateur Jira qui les confirme; et les alertes, que l’application crée en son propre nom.
Pour signaler une vulnérabilité, suivez la Politique de divulgation des vulnérabilités et écrivez à info@plugincraft.ca.
Nous répondons aux alertes de sécurité d’Atlassian dans les 8 heures ouvrables et aux demandes de soutien critiques dans les 24 heures, et nous corrigeons les vulnérabilités dans les délais de la politique de correction des bogues de sécurité d’Atlassian pour les applications du Marketplace.
Aucun test d’intrusion n’a encore été fait. Nous en prévoyons un, ainsi qu’une prime aux bogues, après l’inscription de l’application sur le Marketplace d’Atlassian.

Signaler une vulnérabilité

Si vous pensez avoir trouvé un problème de sécurité dans TuneCraft, suivez notre Politique de divulgation des vulnérabilités. Elle explique comment signaler, ce qui est visé, comment nous protégeons les chercheurs de bonne foi, et ce que vous pouvez attendre de nous et quand.

Écrivez à info@plugincraft.ca. Utilisez des données fictives.
Pour une question urgente, par exemple des données exposées en ce moment, mettez « URGENT » au début de l’objet du message.
Heures de la personne-ressource en sécurité : de 8 h à 17 h, heure de l’Est, du lundi au vendredi.

Une fois TuneCraft inscrite au Marketplace d’Atlassian, vous pourrez aussi signaler par l’entremise d’Atlassian : le programme de primes aux bogues de sécurité du Marketplace et le programme de divulgation des vulnérabilités (en anglais).

Engagements de réponse

Voici les délais auxquels Plugincraft s’engage. Ils correspondent aux minimums qu’Atlassian fixe aux partenaires du Marketplace dans le programme Atlassian Enterprise Certified, ou les améliorent. Les jours ouvrables vont du lundi au vendredi, et les heures ouvrables sont les heures de la personne-ressource en sécurité : de 8 h à 17 h, heure de l’Est. Un message reçu en dehors des heures ouvrables compte à partir du début de la période ouvrable suivante.

Quoi	Engagement
Une alerte de sécurité d’Atlassian	Nous répondons dans les 8 heures ouvrables.
Une demande de soutien critique (gravité 1 ou 2, voir Réponse aux incidents)	Première réponse dans les 24 heures, cinq jours ouvrables par semaine.
Un signalement de vulnérabilité de toute autre provenance	Accusé de réception dans les 2 jours ouvrables.
Un incident de sécurité qui touche des clients	Nous avisons Atlassian dans les 24 heures suivant sa découverte.
Le correctif d’une vulnérabilité	Dans les délais de la section suivante.

Les signalements de sécurité vont à info@plugincraft.ca. Cette adresse reçoit des messages en tout temps et est consultée chaque jour ouvrable.

Délais de correction

Nous évaluons une vulnérabilité selon son score CVSS et la corrigeons dans le délai de la politique de correction des bogues de sécurité d’Atlassian (en anglais) pour les applications Cloud. Le délai court à partir du jour où nous recevons le signalement, ou du jour où Atlassian nous signale la vulnérabilité par le Marketplace, selon le premier des deux. Nous avons vérifié la politique le 27 octobre 2026. Atlassian peut la modifier, et c’est la politique publiée sur le site d’Atlassian qui s’applique.

Gravité	Score CVSS	Délai de correction
Critique	9,0 ou plus	10 jours
Élevée	7,0 à 8,9	4 semaines
Moyenne	4,0 à 6,9	12 semaines
Faible	Moins de 4,0	25 semaines

Ce sont les délais auxquels Plugincraft s’engage. Nous n’en demandons pas de plus longs. La politique d’Atlassian n’accepte une prolongation que dans des cas limités, par exemple lorsque le correctif dépend d’un changement de la plateforme Atlassian. Si nous devions en demander une, nous le dirions à la personne qui a signalé le problème. Un incident de sécurité a aussi une gravité et des objectifs dans Réponse aux incidents. Lorsque les deux s’appliquent, nous respectons le délai le plus court.

Pratiques de sécurité

Cette section décrit comment nous concevons, exploitons et vérifions TuneCraft. Ce qu’elle dit de l’application provient du code source et de la documentation de l’application. Ce qu’elle dit de la plateforme d’Atlassian provient de la documentation d’Atlassian, avec un lien à l’endroit où elle est utilisée.

Cycle de développement sécurisé

Code source privé, demandes de fusion seulement. Le code source est privé. Chaque changement est fait dans sa propre branche et n’atteint la branche principale que par une demande de fusion. Personne ne dépose directement dans la branche principale.
Révision indépendante. Chaque demande de fusion est révisée par un réviseur qui ne l’a pas écrite. Le réviseur est un agent de révision d’IA qui applique des règles écrites (voir la Politique d’utilisation de l’IA). Il lit le changement à la lumière de ces règles, vérifie que les tests automatisés réussissent et consigne son verdict sur la demande de fusion. Les auteurs ne fusionnent jamais leurs propres demandes.
Tests automatisés à chaque changement. À chaque demande de fusion et à chaque dépôt dans la branche principale, la compilation exécute la vérification des types, des tests unitaires qui doivent couvrir au moins 90 % des lignes, des branches, des fonctions et des instructions, une compilation de production, et des tests de bout en bout de l’interface dans un vrai navigateur. Une fonction que les gens peuvent voir est livrée avec ses tests de bout en bout dans la même demande de fusion.
Des tests qui protègent les promesses de cette page. Un test fait échouer la compilation si l’application déclare un accès réseau externe, des ressources distantes ou des modules Connect, ou un déclencheur Web qui ne répond pas par des réponses fixes. Un autre le fait échouer si du code journalise autre chose que des identifiants, des nombres et les noms propres à l’application. Un autre le fait échouer si une colonne qui contient un identifiant de compte manque dans la liste qu’utilisent l’effacement et le signalement. Un autre protège les migrations de base de données publiées, auxquelles on peut seulement ajouter, jamais les modifier ni les retirer. Un autre le fait échouer si un texte manque dans l’une des huit langues de l’application.
Recherche de secrets. Une recherche de secrets s’exécute à chaque demande de fusion et à chaque dépôt dans la branche principale. Elle lit le code et l’historique qui précède le changement testé, avec les règles par défaut de l’outil.
Analyse des dépendances et analyse statique. Elles ne font pas encore partie des vérifications automatisées. Le code serveur de l’application a quatre dépendances d’exécution, toutes des bibliothèques Forge d’Atlassian.
Livraisons. Seules les personnes à qui le propriétaire a donné accès à l’application peuvent la déployer.
Environnement d’exécution à jour. L’application s’exécute sur l’environnement Node.js 22 de Forge.

Contrôle d’accès

Qui peut ouvrir l’application. Les administrateurs Jira le peuvent toujours. Les groupes qu’ils autorisent peuvent utiliser la vue globale, et les administrateurs d’un projet peuvent utiliser la vue projet pour ce projet, sauf si les administrateurs Jira la désactivent. Les outils de nettoyage sont réservés aux administrateurs Jira. Chaque page et chaque requête sont vérifiées sur le serveur, et une vérification qui ne peut pas se terminer fait refuser la requête.
Jira décide qui voit et modifie quoi dans Jira. Les pages de l’application lisent et modifient Jira avec les droits Jira propres à la personne : Jira applique donc les permissions de cette personne. Autoriser un groupe dans TuneCraft permet à ses membres d’ouvrir les pages de l’application. Cela ne change les droits de personne dans Jira.
Un changement à la configuration de votre Jira exige la confirmation d’un administrateur Jira. Un changement dans un outil de nettoyage est fait en tant qu’administrateur Jira qui le confirme : le journal d’audit de Jira montre donc cet administrateur. Là où Jira a une corbeille ou des archives, l’application les utilise, et elle garde un registre de chaque changement avec une annulation lorsque Jira en permet une. L’application crée aussi des tickets. Un avis à un propriétaire est créé en tant que la personne qui l’envoie, qui doit avoir le niveau Gérer (un administrateur Jira, ou un membre d’un groupe qu’un administrateur Jira a autorisé à ce niveau). Une alerte est créée par les vérifications de l’application, en son propre nom, dans le projet et le type de ticket choisis par un administrateur Jira; les alertes sont les seules écritures que l’application fait dans Jira en son propre nom.
Les vérifications en arrière-plan lisent en tant qu’application, et lisent seulement la configuration. Dès qu’un administrateur Jira active les vérifications en arrière-plan d’un outil, l’application lit en son propre nom, en arrière-plan, la configuration et les nombres du site, dans un budget de points Jira. En tant qu’application, elle ne lit aucun ticket. Là où l’application n’a pas le droit de lire quelque chose elle-même, la page d’un administrateur Jira le lit, en tant que cet administrateur. Cela comprend des tickets dans deux outils : Pièces jointes cherche les tickets qui ont des pièces jointes, dans les espaces que l’administrateur choisit ou dans tout le site, et compare les noms de fichiers en mémoire sans les garder; Archivage cherche des tickets par un filtre ou un texte de JQL que l’administrateur donne, et ne les modifie que lorsque l’administrateur confirme.
Un seul déclencheur Web, pour l’analyse automatique. Un administrateur Jira peut créer une clé pour l’analyse automatique. La clé est affichée une seule fois. Elle a deux parties : un secret, dont l’application ne garde qu’une empreinte à sens unique, faite avec un secret conservé dans une variable Forge chiffrée, et la clé d’analyse du site, dont l’expéditeur a besoin pour faire les mêmes hachages à clé que le navigateur. Le déclencheur Web n’accepte un envoi qu’avec le secret, vérifie la licence, la taille, l’ordre et l’empreinte de chaque partie, et refuse tout flux qui n’est pas caviardé, sans rien garder de cet envoi. Il ne répond que par des réponses fixes, accepte au plus 6 envois par jour pour un site et en refuse plus de deux ouverts à la fois. Remplacer ou désactiver la clé arrête aussitôt l’ancien secret; la clé d’analyse ne change pas. Quiconque détient la clé entière peut envoyer des analyses à l’application et tester des hypothèses contre un hachage à clé; gardez-la donc comme vous gardez le jeton d’API, dans le coffre à secrets de l’expéditeur.
Moindre privilège. Les permissions que l’application demande, et pourquoi, sont énumérées plus bas. En ajouter une crée une version majeure que tous les administrateurs de site doivent approuver.
Aucun identifiant de connexion. L’application ne demande ni mot de passe ni jeton d’API Atlassian et n’en garde aucun. L’expéditeur de l’analyse automatique utilise le jeton d’API Atlassian du client pour lire les règles; le jeton n’est jamais envoyé à l’application. Le seul secret que l’application vérifie est la clé de l’analyse automatique, gardée seulement sous forme d’empreinte à sens unique (voir plus haut).

Minimisation des données

Les textes de vos flux restent dehors. Le navigateur (ou l’expéditeur du client) remplace chaque texte des réglages d’un flux par un marqueur avant que quoi que ce soit soit envoyé : JQL, adresses Web et en-têtes, adresses courriel, valeurs intelligentes, noms de champs personnalisés, valeurs comparées, commentaires et secrets. Le serveur ne stocke un flux que s’il est ainsi caviardé, le revérifie et refuse celui qui ne l’est pas. Le JQL d’un flux va uniquement vers le Jira de votre propre site, en tant que la personne, pour être vérifié et compté; l’application garde les nombres. Si un client utilise l’analyse automatique, son expéditeur lit d’abord le texte réel des règles par l’API d’Atlassian, avec le jeton du client et là où le client l’exécute, ce qui peut être ScriptRunner Cloud, une application de scripts d’un autre éditeur (voir la politique de confidentialité).
Des identifiants, des nombres et des hachages, pas des noms. De la configuration de Jira, l’application garde des identifiants, des nombres, des jours, le vocabulaire propre à Jira et des hachages à clé. Les pages lisent les noms dans Jira, avec les droits propres à la personne, quand elles les affichent. Les textes écrits par des personnes que l’application conserve sont les noms des flux, ce qu’un administrateur Jira saisit comme réglage (par exemple les conventions de nommage, les cibles et les consignes des vérifications), ainsi que l’ancienne et la nouvelle étiquette d’un changement d’étiquette pendant 30 jours.
Des identifiants, pas des personnes. L’application stocke des identifiants de comptes Atlassian. Elle ne stocke ni noms ni adresses courriel; elle les demande à Jira quand elle les affiche. Elle signale à Atlassian les identifiants qu’elle garde et efface ceux des comptes fermés.
Des journaux sans contenu. Les journaux de l’application contiennent des identifiants, des nombres, des statuts et des codes d’erreur. Voir Journalisation des données.
Paquet de soutien sur demande. Un paquet de soutien contient des versions, l’état de la licence, la taille des tables et des nombres. Un administrateur peut voir tout le fichier avant de décider de l’envoyer.
Aucun pistage. L’application n’utilise aucun service de statistiques. Ce site Web n’utilise aucun outil de statistiques et ne dépose aucun témoin.

Fonctionne sur Atlassian (aucune sortie de données)

L’application ne déclare aucune permission d’appel externe, aucune ressource distante ni aucun module Connect, et n’utilise aucun script, police, image, outil de statistiques ou service de journalisation externe. Un test fait échouer la compilation si l’on en ajoute. Son unique déclencheur Web répond par des réponses fixes. Elle est conçue pour rester admissible au programme Runs on Atlassian d’Atlassian.
Plugincraft n’a aucun serveur à elle. Le seul sous-traitant des données de l’application est Atlassian (voir Sous-traitants), et toutes les données que l’application stocke restent à l’emplacement de résidence des données de votre site Jira.
Atlassian indique que la plateforme Forge est attestée SOC 2 et certifiée ISO 27001, et qu’une application qui utilise l’environnement d’exécution et le stockage hébergé de Forge, sans sortie de données, peut s’appuyer sur les contrôles hérités de la plateforme. Cela vaut pour la plateforme. Ce n’est pas une certification de Plugincraft. Atlassian dit aussi que, lorsqu’une application fonctionne entièrement sur sa plateforme, elle peut pleinement appuyer l’enquête, le confinement et le partage des journaux lors d’un incident.

Chiffrement au repos et en transit

Au repos. TuneCraft ne stocke les données de clients que dans Forge SQL, la base de données hébergée d’Atlassian pour les applications Forge. Elle ne garde rien sur un serveur à elle. Atlassian indique que la plateforme Forge utilise AES-256 pour chiffrer au repos les données stockées dans le stockage des applications Forge. Forge SQL est un stockage hébergé Forge, couvert par la même documentation sur le cycle de vie des données Forge.
En transit. Atlassian indique que la plateforme Forge utilise TLS 1.2 ou une version supérieure pour chiffrer les données en transit. L’application n’établit aucune autre connexion. Ce site Web redirige le HTTP simple vers HTTPS et demande aux navigateurs de n’utiliser que HTTPS.
Secrets. L’application ne garde ni mot de passe ni jeton d’API. Le seul secret qui lui est propre, utilisé pour faire l’empreinte à sens unique de la clé de l’analyse automatique, est une variable Forge chiffrée. La clé elle-même n’est montrée qu’une fois à l’administrateur Jira qui la fabrique; l’application en garde l’empreinte, et la clé d’analyse du site avec le reste de ses données.

Sauvegardes et reprise

Atlassian sauvegarde le stockage. Atlassian indique que les bases de données provisionnées et gérées par Forge SQL sont sauvegardées périodiquement, et que le nuage Atlassian sauvegarde tout le stockage persistant de Forge pour la reprise après sinistre. Si une application supprime des données par erreur, Atlassian peut les restaurer lorsqu’un billet de soutien est ouvert dans les 21 jours suivant la suppression.
Plugincraft ne garde aucune copie. Nous ne gardons aucune copie ni sauvegarde des données de clients. Le code de l’application est dans un dépôt de code source privé, d’où une nouvelle version peut être déployée sur Forge.
Des fichiers d’enregistrement, pas des sauvegardes. Avant de supprimer quelque chose que Jira ne peut pas restaurer, comme un statut, un workflow ou un rôle de projet, l’application remet à l’administrateur Jira un fichier d’enregistrement de ce qu’il contient, à sauvegarder sur son propre ordinateur. Plugincraft ne le reçoit jamais. L’application n’a pas de sauvegarde et de restauration de ses propres données.
En cas de panne. La façon dont nous maintenons l’application en marche et rétablissons le service pour chaque type de perturbation est décrite dans Continuité des activités et reprise après sinistre.

Test d’intrusion et primes aux bogues (prévus)

Test d’intrusion. Aucun test d’intrusion de TuneCraft n’a encore été réalisé. Après l’inscription de l’application au Marketplace d’Atlassian, nous prévoyons de la faire tester une fois par an, par le programme de tests d’intrusion d’Atlassian ou par un fournisseur accrédité CREST. Une fois un test réalisé, nous prévoyons de mettre le rapport ou une lettre d’attestation à la disposition des clients, sous entente de confidentialité.
Primes aux bogues. TuneCraft ne participe pas encore à un programme de primes aux bogues, et Plugincraft ne verse pas encore de récompense pour les signalements. Après l’inscription de l’application, nous prévoyons de participer au programme de primes aux bogues de sécurité du Marketplace d’Atlassian.
Rien de cela n’a encore été réalisé. Nous mettrons cette page à jour quand un test sera réalisé ou que nous aurons adhéré au programme.

Permissions que l’application demande

Voici les 65 permissions Forge du manifeste de l’application, et à quoi chacune sert. Chaque administrateur Jira qui installe l’application les approuve. L’application demande le strict nécessaire.

Permission	À quoi elle sert
read:jira-work	Vérifier, en tant que la personne, si elle est administratrice Jira ou administratrice de projet. Compter, en tant que la personne, les tickets que trouve maintenant la recherche d’un flux planifié (le décompte approximatif de Jira), et faire vérifier par Jira le JQL d’un flux. Faire vérifier par Jira, depuis la page Optimiser, l’expression Jira d’un validateur qu’Optimiser propose, et lire, en tant que la personne, les noms des statuts qu’un flux nomme par identifiant. Lire la configuration du site que nomment les flux, en tant qu’application ou qu’administrateur Jira; les rapports de l’outil Limites sur les tickets proches des plafonds de Jira, en tant qu’administrateur qui ouvre la page (montrés à lui seul, jamais stockés); les tickets qui ont des pièces jointes, pour l’outil Pièces jointes, et les tickets que trouve une recherche d’Archivage, en tant qu’administrateur Jira qui utilise l’outil (les identifiants des plus volumineux sont conservés, jamais un nom ni un texte); les étiquettes du site, le décompte des tickets qui portent chacune et une recherche des tickets qui portent une étiquette choisie, pour l’outil Étiquettes, en tant qu’administrateur Jira dont la page est ouverte; le décompte des tickets ouverts d’un sprint, pour Laissés de côté, en tant qu’administrateur Jira dont la page est ouverte; l’état du ticket lié à une action À faire; et les champs qu’exige un type de ticket. Les nombres sont conservés; le contenu des tickets ne l’est pas.
write:jira-work	Créer des tickets Jira : un avis au propriétaire d’un flux, en tant que la personne qui l’envoie; les actions que crée la page À faire, en tant qu’administrateur Jira qui confirme; les alertes, en tant qu’application (les seules écritures que l’application fait dans Jira en son propre nom), dans le projet et le type de ticket choisis par un administrateur Jira. Aussi, en tant qu’administrateur Jira qui confirme (un filtre, en tant que son propriétaire) : un nouveau propriétaire ou un nouveau nom pour un filtre ou un tableau de bord, chacun avec une annulation; la suppression d’un filtre ou d’un tableau de bord, qui n’en a pas; le JQL d’un filtre réécrit avec l’identifiant d’un champ à la place d’un nom que Jira n’accepte plus, en tant que propriétaire du filtre, lorsque ce propriétaire est la personne qui confirme (prendre un filtre à son propriétaire pour le réparer n’est pas encore offert), avec une annulation; le partage avec n’importe qui sur le Web, avec toute personne connectée ou avec un espace que Jira n’affiche plus, retiré de nombreux filtres et tableaux de bord à la fois, avec une annulation; l’archivage de vieux tickets de l’outil Archivage, que son annulation restaure, et le déplacement de tickets périmés vers un autre statut, qui n’a pas d’annulation; le renommage, la fusion et le retrait d’une étiquette sur les tickets qui la portent, un à la fois et sans les courriels de notification de Jira, de l’outil Étiquettes, avec une annulation pendant 30 jours; la copie, par la page Fusionner des champs, des valeurs d’un champ personnalisé dans un autre du même type, sur les tickets qui en ont une, seulement là où la seconde est vide, un ticket à la fois et sans les courriels de notification de Jira, avec une annulation qui vide le second champ seulement là où il est encore égal au premier; et la suppression de pièces jointes de l’outil Pièces jointes, que Jira ne peut pas rétablir et qui n’a pas d’annulation.
read:jira-user, read:user:jira, read:group:jira, read:avatar:jira	Savoir qui est la personne et à quels groupes elle appartient; chercher des groupes et des personnes par nom; afficher les noms des propriétaires de flux comme Jira les montre; vérifier si les comptes que nomment les flux sont toujours actifs; et, dans la page Groupes, lire les premiers membres des groupes à qui un schéma de permissions accorde quelque chose, ainsi que les noms des groupes. Les noms sont affichés et non stockés.
write:group:jira	Retirer des personnes désactivées d’un groupe, et les y remettre à l’annulation, en tant qu’administrateur Jira qui confirme. TuneCraft ne désactive ni ne supprime jamais un compte.
storage:app	Le stockage hébergé Forge (Forge SQL) pour les propres données de l’application.
report:personal-data	Signaler les identifiants de comptes Atlassian que l’application stocke, une fois par cycle de signalement, et savoir quels comptes ont été fermés pour effacer leurs données.
read:license:jira	Lire, en tant qu’administrateur Jira, si le forfait Jira du site est Free et le décompte approximatif de ses utilisateurs, pour que les administrateurs n’aient pas à les saisir.
read:issue-type-scheme:jira	Lire quels schémas de types de tickets contiennent chaque type et quels espaces utilisent chaque schéma (identifiants et indicateur de schéma par défaut). Lecture seule.
read:workflow:jira, read:workflow-scheme:jira, read:status:jira	Lire les workflows avec les clés des règles de leurs transitions, les statuts, ainsi que les schémas de workflow qui contiennent chaque workflow avec le nombre d’espaces qui les utilisent, pour trouver les workflows et les statuts qu’aucun espace n’utilise. Lecture seule. Les réglages d’une règle ne sont pas conservés.
write:workflow:jira, delete:workflow:jira, delete:workflow-scheme:jira	Supprimer un statut, un workflow ou un schéma de workflow que rien n’utilise, en tant qu’administrateur Jira qui confirme, après un fichier d’enregistrement qu’il sauvegarde. Jira n’a pas de corbeille pour ceux-ci.
read:project:jira, read:project-category:jira, read:project.property:jira, read:project-version:jira, read:project.component:jira, read:issue-type:jira, read:issue-type-hierarchy:jira	Lire les espaces, leurs catégories, versions et composants, ainsi que les types de tickets, pour les outils Espaces, Schémas et Workflows et pour les appels ci-dessous. Les ensembles de Jira pour ces appels en listent plusieurs ensemble. La lecture hebdomadaire de l’outil Espaces demande aussi le responsable de chaque espace, et ne garde l’identifiant de compte du responsable que tant que Jira dit qu’il est inactif; l’application ne lit aucun rôle par leur entremise.
write:project:jira, delete:project:jira, write:project.avatar:jira, write:project-version:jira, delete:project-version:jira, delete:project.component:jira	Archiver, mettre dans la corbeille de Jira ou restaurer un espace; changer son responsable, son responsable par défaut et sa catégorie; mettre des espaces sur un autre schéma de permissions lorsque des schémas identiques sont fusionnés (une annulation les remet); publier, archiver ou supprimer une version; et supprimer un composant, en tant qu’administrateur Jira qui confirme, avec une annulation lorsque Jira en permet une.
read:screen:jira, read:screen-tab:jira, read:screenable-field:jira, read:screen-scheme:jira, read:issue-type-screen-scheme:jira, read:field-configuration:jira, read:field-configuration-scheme:jira, read:notification-scheme:jira, read:issue-security-scheme:jira, read:issue-security-level:jira	Lire les écrans, leurs onglets et leurs champs, les configurations de champs, les schémas et ce qui les utilise, pour trouver ceux que rien n’utilise et compter ce que contient un écran ou un schéma de notification et, pour Laissés de côté, savoir si un espace a des niveaux de sécurité. Lecture seule. Les identifiants et les nombres sont conservés, jamais les noms.
read:field:jira, read:custom-field-contextual-configuration:jira, read:field.option:jira	Lire les champs, l’endroit où un champ personnalisé est utilisé (ses contextes, espaces, écrans et onglets) et si un contexte contient une option. Lecture seule. Les identifiants, les nombres et les vrai ou faux sont conservés.
write:field:jira, delete:field:jira	Mettre un champ personnalisé dans la corbeille de Jira, le restaurer et supprimer un champ déjà dans la corbeille; et ajouter des espaces à un contexte du champ à garder dans une fusion (une annulation les retire), en tant qu’administrateur Jira qui confirme.
write:field.option:jira	Désactiver ou activer les options du contexte d’un champ à sélection, et créer dans le champ à garder d’une fusion les options qui lui manquent (une annulation les désactive), en tant qu’administrateur Jira qui confirme. TuneCraft ne supprime jamais une option.
write:issue-type-screen-scheme:jira, delete:issue-type-screen-scheme:jira	Mettre les espaces d’une copie d’un schéma d’écrans par type de ticket sur le schéma identique que l’administrateur garde, et supprimer la copie restée vide, en tant qu’administrateur Jira qui confirme, après un fichier d’enregistrement qu’il sauvegarde. Les schémas sont prouvés identiques de nouveau avant chaque appel. Un déplacement a une annulation; Jira ne rend pas un schéma supprimé.
write:screenable-field:jira, delete:screenable-field:jira	Ajouter le champ à garder d’une fusion à l’onglet de chaque écran qui montre le champ à vider, juste après lui, et, pour l’annulation, le retirer seulement des écrans où TuneCraft l’a ajouté, en tant qu’administrateur Jira qui confirme. Jamais un ticket.
read:project-role:jira, read:application-role:jira, read:permission:jira, read:permission-scheme:jira	Lire les rôles de projet, les schémas de permissions et leurs octrois à des groupes, des rôles et des personnes, ainsi que les rôles de chaque espace, pour trouver les rôles et les groupes que rien n’utilise et les personnes désactivées qu’un schéma nomme encore.
delete:project-role:jira	Supprimer un rôle de projet qu’aucun schéma de permissions n’accorde et auquel aucun espace n’a donné d’acteurs, en tant qu’administrateur Jira qui confirme, après un fichier d’enregistrement qu’il sauvegarde.
write:permission:jira, delete:permission:jira	Retirer les octrois d’un rôle des schémas de permissions dans lesquels aucun espace qui utilise le schéma ne donne d’acteurs au rôle, et les remettre à l’annulation. Aussi retirer un octroi qui donne une permission à n’importe qui ou à tous les utilisateurs d’un produit, ou le donner à un groupe ou à un rôle à la place, et le remettre à l’annulation. Le tout en tant qu’administrateur Jira qui confirme. TuneCraft ne change jamais qui est dans un rôle.
delete:permission-scheme:jira	Supprimer la copie d’un schéma de permissions qu’aucun espace n’utilise après que ses espaces ont été placés sur un schéma identique, en tant qu’administrateur Jira qui confirme.
read:board-scope:jira-software, read:board-scope.admin:jira-software, read:sprint:jira-software	Lire, en tant qu’administrateur Jira qui ouvre Tableaux ou Sprints, les tableaux, leur configuration et leur filtre, ainsi que les sprints. Montrés à lui seul, jamais stockés.
write:sprint:jira-software, delete:sprint:jira-software, write:board-scope:jira-software	Renommer, fermer et supprimer des sprints, ajouter les tickets ouverts d’un sprint qu’elle ferme au prochain sprint futur ou à un nouveau sprint, et supprimer des tableaux orphelins, en tant qu’administrateur Jira qui confirme. Fermer un sprint et en supprimer un n’ont pas d’annulation. Les noms ne sont pas stockés; le registre garde des identifiants, des états et des hachages à clé.
read:audit-log:jira	Lire les enregistrements d’audit de Jira, seulement lorsqu’un administrateur Jira appuie sur « Qui l’a fait » dans la page Historique des changements, en tant que cet administrateur, pour les jours qu’il a choisis. Montrés à lui seul et jamais stockés.

Incidents et état du service

La façon dont nous traitons un incident est décrite dans Réponse aux incidents. Une page d’état sera publiée avec la fiche du Marketplace. Les problèmes de Jira ou de Forge eux-mêmes sont signalés sur la page d’état d’Atlassian.