Administration
Les paramètres de l'application se trouvent sur une seule page de l'administration de Jira, sous Applications. Les administrateurs Jira et les administrateurs de l'application peuvent aussi y accéder par Paramètres de l'app, au bas de la liste des hiérarchies. Un menu à gauche regroupe les outils, et l'aide intégrée décrit chacun d'eux et permet de l'ouvrir directement.
Dans cette page

Les administrateurs Jira ont accès à tous les outils. Les administrateurs de l'application y ont accès aussi, sauf à Administrateurs de l'app, à Tickets masqués dans les totaux et à Sauvegarde.
| Groupe | Outils |
|---|---|
| Premiers pas | Guide de configuration, Licence |
| Accès | Accès à l'app, Administrateurs de l'app, Droits d'automatisation |
| Comportement | Limites des règles, Points de l'API Jira, Calendrier de travail, Valeurs par défaut, Tickets masqués dans les totaux |
| Données et support | Sauvegarde, Maintenance, Taille de la base, Paquet de support |
Guide de configuration
Le guide de configuration énumère les premières étapes à suivre sur un nouveau site et les coche à mesure que vous avancez. Il reconnaît les étapes déjà faites sur le site :
- Saisir la clé de licence.
- Choisir qui peut utiliser l'application.
- Choisir les projets où elle s'affiche.
- Vérifier les limites des règles.
- Créer une première hiérarchie.
- Laisser les règles la remplir.
- Permettre à la recherche Jira de trouver les tickets des hiérarchies (facultatif).
- Mettre une hiérarchie sur un tableau de bord (facultatif).
La page d'accueil rappelle aux administrateurs les étapes restantes, jusqu'à ce qu'ils cochent Ne plus le rappeler aux administrateurs sur la page d'accueil.
Licence
Une clé de licence est valable pour un seul site Jira. La page Licence affiche l'Identifiant de ce site, à fournir quand vous demandez une clé. Collez la clé dans Clé de licence et sélectionnez Enregistrer la clé.
Une clé correspond soit à une licence complète, qui n'expire pas, soit à un essai de 30 jours. Un site peut utiliser trois licences d'essai. À partir de deux semaines avant la fin d'un essai, les administrateurs voient un avis qui en indique la date de fin. Sans clé valide, ou une fois l'essai terminé, toutes les hiérarchies passent en lecture seule pour tout le monde jusqu'à ce que quelqu'un saisisse une clé. Rien n'est supprimé.
Accès à l'app
Accès à l'app règle trois choses :
- Qui peut utiliser l'application : Toutes les personnes qui peuvent utiliser Jira, ou Seulement ces personnes et groupes.
- Qui peut créer des hiérarchies : Toutes les personnes qui peuvent utiliser l'application, ou Seulement ces personnes et groupes (s'ils peuvent utiliser l'application).
- Projets qui affichent l'application : Tous les projets, ou Seulement ces projets. L'onglet de projet et le panneau du ticket ne fonctionnent que dans ces projets. La page de l'application continue d'afficher les hiérarchies qui contiennent des tickets de n'importe quel projet.
Les administrateurs Jira et les administrateurs de l'application peuvent toujours utiliser l'application et créer des hiérarchies, ce qui les empêche de se bloquer eux-mêmes. Les changements atteignent tout le monde en moins d'une minute. L'application enregistre les personnes, les groupes et les projets par leur identifiant : les renommer ne casse donc pas le réglage.
Accès à l'app ne limite pas la recherche Jira avec treecraftHierarchy(). C'est un paramètre de chaque hiérarchie qui détermine si la recherche peut la trouver.
Administrateurs de l'app
Les administrateurs Jira peuvent désigner des personnes et des groupes comme administrateurs de l'application. Ceux-ci gèrent les paramètres de l'application sans être administrateurs Jira : limites des règles, Accès à l'app, calendrier de travail, guide de configuration, paquet de support et licence, entre autres. Ils peuvent toujours utiliser l'application, mais n'obtiennent aucun accès supplémentaire aux hiérarchies ni aux tickets. Seuls les administrateurs Jira peuvent modifier cette liste.
Droits d'automatisation
Un seul tableau détermine qui peut :
- Utiliser l'automatisation (règles et écritures en retour) ;
- Modifier les règles ;
- Configurer les écritures en retour ;
- Exécuter et annuler les écritures en retour ;
- Partager les colonnes enregistrées.
Chaque liste ne fait que restreindre ce que permet l'accès de la hiérarchie elle-même. Par exemple, modifier les règles exige toujours le niveau Automatiser sur la hiérarchie. Une colonne cochée pour Tout le monde laisse passer tout le monde, ce qui, pour les règles et les écritures en retour, veut dire toutes les personnes autorisées à utiliser l'automatisation. Les administrateurs Jira et les administrateurs de l'application sont toujours autorisés. Les changements peuvent prendre jusqu'à une minute pour s'appliquer partout.
Limites des règles
Les limites gardent les résultats des règles assez petits pour que l'application reste rapide pour tout le monde. Quand une règle atteint une limite, l'application garde ce qu'elle a construit jusque-là et affiche un avis. Un avis de limite de lignes, de tickets par règle, de profondeur ou de niveaux n'apparaît qu'aux personnes qui peuvent voir au moins un des tickets laissés de côté. Les changements s'appliquent à partir de la prochaine mise à jour de chaque hiérarchie.
| Limite | Plage | Par défaut |
|---|---|---|
| Lignes d'une hiérarchie | 1 000 à 25 000 | 10 000 |
| Tickets qu'une règle peut ajouter | 100 à 2 500 | 2 500 |
| Niveau le plus profond que les règles peuvent remplir | 2 à 64 | 20 |
| Niveaux qu'une règle « ajouter enfants/liens » peut ajouter | 1 à 20 | 10 |
Quelles que soient les valeurs choisies, une hiérarchie contient au plus 2 500 tickets et exécute au plus 30 règles, dont au plus 5 règles qui lisent chaque ligne (voir Limites et avis).
Points de l'API Jira
Atlassian accorde à chaque application un nombre de points de l'API Jira par heure. Cette page montre combien l'application en a utilisé pendant l'heure en cours et les heures précédentes, par heure UTC, en distinguant les pages des personnes et le travail en arrière-plan.
Réglez le Pool selon votre cas : Partagé par l'application : 65 000 points par heure (par défaut chez Atlassian), ou Pool propre à ce site (accordé par Atlassian), avec votre Édition de Jira et le nombre d'Utilisateurs du site. Le travail en arrière-plan peut utiliser 80 % du pool, ce qui laisse le reste aux pages des personnes. Une fois que le travail en arrière-plan a épuisé sa part, ou que le pool est vide, les actualisations courantes attendent l'heure suivante. Le travail qui masque ou retire des tickets n'attend jamais. Le décompte de l'application peut être un peu inférieur à celui de Jira.
Calendrier de travail
Les formules et l'écriture en retour Décaler des dates suivent ce calendrier. Définissez les Heures d'une journée de travail (de 0,25 à 24, par quarts d'heure), les Jours d'une semaine de travail, les Jours ouvrés et les Jours fériés. Une durée de 1d ou de 1w a alors la longueur définie ici, et workdays_between, add_workdays et is_workday sautent les jours de congé. Revenir à 8 h par jour, 5 jours par semaine, du lundi au vendredi réinitialise le calendrier.
Valeurs par défaut
Les valeurs par défaut s'appliquent aux personnes qui n'ont pas fait leur propre choix, et seulement si elles peuvent ouvrir ce qui est choisi :
- Hiérarchie sur laquelle s'ouvre la page de l'application, ou aucune pour que chacun retrouve la dernière qu'il a ouverte.
- Hiérarchie que le panneau du ticket montre en premier, ou aucune pour la première qui contient le ticket.
- Jeu de colonnes de départ de chaque page, pour la page de l'application, les pages de projet et l'onglet du tableau. Vous ne pouvez choisir que des vues partagées avec tout le monde.
La hiérarchie par défaut d'un projet se règle sur la page Paramètres de hiérarchie, dans les paramètres du projet. Voir Paramètres du projet.
Tickets masqués dans les totaux
Par défaut, les colonnes de total n'additionnent que les tickets que chaque personne peut voir. Pour les champs numériques que vous ajoutez ici, les totaux comptent aussi les tickets qu'une personne ne peut pas voir. Ils n'entrent que dans les totaux : la valeur propre d'un ticket masqué n'est jamais affichée. Les tickets qui ont un niveau de sécurité ne sont jamais comptés. L'application recompte l'apport des tickets masqués quand quelqu'un ouvre la hiérarchie et que le dernier compte date de plus d'une heure.
Avant d'enregistrer, vous confirmez avoir compris une conséquence : quand une ligne n'a qu'un seul ticket masqué en dessous d'elle, son total affiche la valeur de ce ticket.
Sauvegarde
Enregistrer une sauvegarde place toutes les hiérarchies du site dans un seul fichier, avec leurs lignes, dossiers, règles, notes, accès et écritures en retour, ainsi que les vues, colonnes enregistrées, préréglages et paramètres de l'application du site. Options :
- Avec l'historique : le journal des modifications et les anciennes exécutions d'écriture en retour.
- Pour un autre site : ajoute la clé de chaque ticket, lue dans Jira en votre nom, pour que la sauvegarde puisse être restaurée sur un autre site. Les tickets que vous ne pouvez pas consulter sont listés sans clé et sont laissés de côté sur l'autre site.
Le fichier contient le contenu privé de chaque hiérarchie : règles, JQL, notes et qui peut voir quoi. Conservez-le avec autant de soin que le site lui-même. Il ne contient jamais la clé de licence ni le détail des tickets.
Restauration
Choisissez un fichier de sauvegarde, sélectionnez les hiérarchies à restaurer, puis lancez la restauration. Chacune revient sous la forme d'une nouvelle hiérarchie à côté de celles qui existent, si bien que rien n'est remplacé. Garder les noms tels quels évite l'ajout du suffixe « (restored) ». Les hiérarchies restaurées ont la recherche Jira désactivée au départ et reconstruisent les résultats de leurs règles. Les écritures en retour reviennent uniquement sous forme de configurations : rien n'est écrit dans Jira tant que personne ne les exécute.
Depuis un autre site, l'application retrouve les tickets par leur clé, tels que vous les voyez. Les tickets absents de ce site, ou que vous ne pouvez pas consulter, sont laissés de côté avec tout ce qui se trouve en dessous. L'application liste ce qu'elle a dû effacer, comme une règle qui cite un tableau inexistant ici.
Deux autres options restaurent du contenu qui vaut pour tout le site :
- Restaurer aussi la bibliothèque du site : vues enregistrées, colonnes enregistrées, préréglages de transformations et de règles.
- Restaurer aussi les réglages du site : chaque réglage remplace celui de ce site, y compris les limites des règles, Accès à l'app, le calendrier, les valeurs par défaut, les droits d'automatisation, les administrateurs de l'application, le guide de configuration, la maintenance et les tickets masqués dans les totaux. L'application vous demande d'abord de confirmer.
Une restauration interrompue en cours de route figure sous Restaurations inachevées, où vous pouvez la supprimer avec ce qu'elle a restauré.
Maintenance
Une fois par jour, l'application efface ce que plus personne ne peut atteindre, comme les favoris, les notes et les résultats des règles des hiérarchies supprimées. Elle demande aussi à la recherche Jira de se remettre à jour là où son index s'est décalé. Les restes sont effacés un jour après que l'application les a trouvés pour la première fois. À part l'ancien historique, la maintenance ne supprime jamais rien que les gens peuvent encore voir.
Effacer l'historique de plus d'un an supprime chaque jour les anciennes exécutions d'écriture en retour et les entrées du journal des modifications de plus d'un an. L'option est activée par défaut. Si vous la désactivez, l'historique est conservé indéfiniment et l'espace de stockage de l'application ne cesse de croître. Ce qui est supprimé ne peut pas être récupéré.
La page indique la dernière exécution et ce que chaque tâche a effacé, et propose Lancer maintenant.
Taille de la base
Cette page montre la part de la limite de base de données du site qu'utilise l'application, par type de données : hiérarchies et leurs lignes, règles et leurs résultats, copie des tickets Jira gardée pour la rapidité, recherche Jira, historique des changements, écritures en retour, vues et réglages personnels, et enregistrements propres à l'application. Afficher le détail liste chaque table.
Paquet de support
Le paquet de support est un fichier qui décrit la configuration et le fonctionnement de l'application sur ce site : versions, paramètres, nombres et erreurs récentes. Il ne contient ni résumés de tickets, ni valeurs de champs, ni adresses courriel. Afficher tout le contenu du fichier vous permet de le lire avant de l'envoyer. Sélectionnez Télécharger, puis envoyez le fichier à l'Assistance avec une courte description de ce qui s'est passé.
Des questions sur l’application? Écrivez à info@plugincraft.ca.