Le tri depuis la carte Slack, et une extension qui explique ses propres refus

Depuis hier, un rapport annoncé dans Slack est devenu quelque chose sur quoi vous pouvez agir sans quitter le canal.

La carte portait déjà de quoi décider si un bogue avait de l’importance. Elle porte maintenant les deux décisions par lesquelles le tri se termine réellement : les boutons de statut, et les trois niveaux de sévérité, dans les mots mêmes qu’emploie la boîte de réception. Appuyez sur l’un d’eux et le rapport avance. Le lien vers le rapport complet garde sa place et reste le seul bouton coloré de la carte, parce que l’ouvrir demeure ce que la plupart des gens veulent.

Si votre équipe préfère que le canal reste un simple fil d’annonces, il existe un réglage pour cela. Auparavant, un canal connecté pouvait modifier un rapport, que quelqu’un l’ait choisi ou non - les boutons arrivaient tout simplement avec l’intégration. Désormais un canal peut être en lecture seule, et les boutons disparaissent de la carte au lieu de se contenter de refuser quand on appuie dessus.

Se connecter est maintenant une installation ordinaire

Jira et Slack se connectent par leurs propres parcours d’installation, avec le bouton que chaque éditeur demande d’utiliser, plutôt qu’avec quelque chose de fait maison. La commande Jira reste masquée tant que son installation n’est pas réellement terminée, et un connecteur Jira indique le compte Atlassian sous lequel il fonctionne - ce qui compte le jour où cette personne s’en va.

Deux autres choses sur cette page :

• Vous pouvez tester un connecteur sans attendre l’arrivée d’un vrai bogue. Collez une URL, écrivez votre vérification de signature d’après la recette figurant sur la même page, appuyez sur le bouton, et regardez la livraison aboutir ou échouer. Avant, la réponse était d’attendre en espérant.
• Chaque ligne de destination indique de quel type elle est, et les webhooks ont une carte à eux au lieu d’être la moitié sans nom d’une liste.

Un connecteur est par ailleurs rattaché au domaine qu’il dessert, si bien qu’un même espace de travail Slack ou un même outil de suivi peut porter plusieurs de vos sites sans qu’ils se mélangent.

L’extension 1.7.0 est dans le magasin

Le panneau explique mieux ce qu’il fait, ce qui semble anodin et fait la différence entre une personne qui signale un bogue et une personne qui renonce.

Un enregistrement refusé dit maintenant ce qui le corrige vraiment. Enregistrer un onglet exige que l’extension ait été invoquée sur cet onglet-là, et Chrome retire cette permission dès que l’onglet navigue vers une autre adresse - la séquence ordinaire la dépense donc : vous ouvrez le panneau, vous tapez l’adresse de la page que vous vouliez signaler, et la navigation que vous venez d’effectuer a emporté la permission avec elle. Le panneau suggérait auparavant d’autoriser l’extension sur tous les sites, ce qui n’aide en rien ici, si bien que suivre notre propre conseil produisait un second échec et aucune explication. Il dit maintenant ce qui rétablit réellement la permission, et pourquoi cela se reproduit.

La personne qui signale est prévenue que la copie d’écran est publique avant de la prendre, comme elle l’était déjà pour l’enregistrement. Celui qui capture est le seul à savoir si la fiche client ouverte derrière le bogue a de l’importance.

Et le nom du navigateur dans un rapport est déduit plutôt que supposé, si bien qu’un rapport envoyé depuis Edge n’annonce plus Chrome.

Des identifiants capturés, partout cette fois

La page du rapport et le téléchargement HAR ont toujours écarté les en-têtes d’autorisation, les cookies et leurs semblables avant d’afficher quoi que ce soit, parce que lire un lien de partage ne demande aucune connexion. Le même rapport récupéré par l’API renvoyait ces en-têtes tels qu’ils avaient été capturés.

Le même filtre s’applique désormais partout où un rapport peut être lu, ce que tout le monde supposait raisonnablement déjà acquis.

Les envois de courrier - réinitialisations de mot de passe, confirmations - sont eux aussi limités en fréquence, par adresse et par IP.

Un rapport ouvert sur un téléphone

La page de rapport partagé servait au téléphone exactement ce qu’elle servait à un ordinateur de bureau, y compris un lien d’installation dont le Chrome Web Store ne peut rien faire depuis un mobile.

C’était pris à l’envers, car le téléphone est l’endroit où un très grand nombre de ces liens sont ouverts : quelqu’un partage un rapport, le destinataire le touche en chemin. Elle propose maintenant quelque chose qu’un téléphone peut réellement faire.

À côté de cela : la barre d’état n’entre plus en collision avec l’en-tête, la notification ou la boîte de dialogue sous iOS, Android cesse de repeindre le site parce que le schéma de couleurs est déclaré, et le thème est fixé avant que la page ne s’affiche, au lieu de faire clignoter le mauvais.

Choses plus petites

• Une requête réseau isolée peut être téléchargée en fichier HAR par l’API, et pas seulement depuis la page du rapport.
• Le menu du compte sort de la navigation repliée sur les petits écrans et reçoit son propre panneau.
• La page Connecteurs a été relue quant à ce qu’elle dit et à l’ordre dans lequel elle le dit.