Seit gestern ist ein Bericht, der in Slack angekündigt wird, etwas, womit Sie arbeiten können, ohne den Channel zu verlassen.

Die Karte enthielt schon bisher genug, um zu entscheiden, ob ein Fehler wichtig ist. Jetzt enthält sie die beiden Entscheidungen, mit denen Triage tatsächlich endet: die Status-Schaltflächen und die drei Schweregrade, in denselben Worten, die auch der Posteingang verwendet. Ein Druck darauf, und der Bericht wandert weiter. Der Link zum vollständigen Bericht behält seinen Platz und bleibt die einzige farbige Schaltfläche auf der Karte, denn ihn zu öffnen ist immer noch das, was die meisten wollen.

Wenn Ihr Team lieber möchte, dass der Channel ein reiner Feed bleibt, gibt es dafür einen Schalter. Bisher konnte ein verbundener Channel einen Bericht verändern, ob das nun jemand so gewählt hatte oder nicht - die Schaltflächen kamen einfach mit der Integration. Jetzt kann ein Channel nur lesend sein, und die Schaltflächen verschwinden von der Karte, statt beim Drücken lediglich abzulehnen.

Verbinden ist jetzt eine ganz normale Installation

Jira und Slack werden über ihre eigenen Installationsabläufe verbunden, mit der Schaltfläche, die der jeweilige Anbieter dafür vorschreibt, statt über etwas Selbstgebautes. Das Jira-Bedienelement bleibt ausgeblendet, bis die Installation wirklich abgeschlossen ist, und ein Jira-Connector nennt das Atlassian-Konto, unter dem er läuft - was an dem Tag zählt, an dem diese Person geht.

Zwei weitere Dinge auf dieser Seite:

  • Sie können einen Connector testen, ohne auf einen echten Fehler zu warten. Fügen Sie eine URL ein, schreiben Sie Ihre Signaturprüfung anhand der Anleitung auf derselben Seite, drücken Sie die Schaltfläche und sehen Sie zu, wie die Zustellung ankommt oder fehlschlägt. Bisher blieb nur warten und hoffen.
  • Jede Zeile eines Ziels sagt, um welche Art es sich handelt, und Webhooks haben eine eigene Karte, statt die namenlose Hälfte einer Liste zu sein.

Ein Connector ist außerdem an die Domain gebunden, für die er arbeitet, sodass ein Slack-Workspace oder ein Tracker mehrere Ihrer Websites tragen kann, ohne dass sie sich in die Quere kommen.

Erweiterung 1.7.0 ist im Store

Das Panel erklärt sich jetzt besser, was klein klingt und den Unterschied ausmacht zwischen jemandem, der einen Fehler meldet, und jemandem, der aufgibt.

Eine abgelehnte Aufzeichnung sagt jetzt, was sie tatsächlich behebt. Um einen Tab aufzuzeichnen, muss die Erweiterung auf genau diesem Tab aufgerufen worden sein, und Chrome nimmt diese Berechtigung in dem Moment zurück, in dem der Tab zu einer anderen Seite wechselt - der gewöhnliche Ablauf verbraucht sie also: Sie öffnen das Panel, tippen die Adresse der Seite ein, die Sie melden wollten, und der Seitenwechsel, den Sie gerade ausgelöst haben, hat die Berechtigung mitgenommen. Bisher schlug das Panel vor, die Erweiterung für alle Websites zuzulassen, was hier überhaupt nichts hilft - wer unserem eigenen Rat folgte, bekam also einen zweiten Fehlschlag und keine Erklärung. Jetzt sagt es, was die Berechtigung wirklich wiederherstellt, und warum das immer wieder passiert.

Wer meldet, erfährt vor der Aufnahme, dass der Screenshot öffentlich ist, so wie es bei der Aufzeichnung schon der Fall war. Nur die Person, die aufnimmt, weiß, ob der Kundendatensatz, der hinter dem Fehler geöffnet ist, eine Rolle spielt.

Und der Browsername in einem Bericht wird ermittelt statt angenommen, sodass ein Bericht aus Edge nicht länger Chrome nennt.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen.

Erweiterung installieren

Erfasste Zugangsdaten, diesmal überall

Die Berichtsseite und der HAR-Download haben Autorisierungs-Header, Cookies und Verwandtes immer entfernt, bevor überhaupt etwas dargestellt wurde, denn zum Lesen eines geteilten Links braucht es keine Anmeldung. Derselbe Bericht, über die API abgerufen, lieferte diese Header so aus, wie sie erfasst worden waren.

Derselbe Filter gilt jetzt überall dort, wo ein Bericht gelesen werden kann - was alle vernünftigerweise ohnehin angenommen hatten.

Endpunkte, die E-Mails versenden - Passwort-Zurücksetzungen, Bestätigungen -, sind jetzt außerdem pro Adresse und pro IP in der Rate begrenzt.

Ein Bericht, der auf dem Telefon geöffnet wird

Die geteilte Berichtsseite lieferte einem Telefon bisher genau das, was sie einem Desktop lieferte, samt eines Installationslinks, mit dem der Chrome Web Store vom Handy aus nichts anfangen kann.

Das war verkehrt herum, denn sehr viele dieser Links werden auf dem Telefon geöffnet: Jemand teilt einen Bericht, und der Empfänger tippt ihn unterwegs an. Jetzt bietet die Seite etwas an, was ein Telefon auch tatsächlich tun kann.

Dazu kommt: Die Statusleiste kollidiert unter iOS nicht mehr mit der Kopfzeile, der Einblendung oder dem Dialog, Android färbt die Website nicht mehr um, weil das Farbschema deklariert ist, und das Design steht fest, bevor die Seite gezeichnet wird, statt kurz das falsche aufblitzen zu lassen.

Kleinere Dinge

  • Eine einzelne Netzwerkanfrage lässt sich über die API als HAR-Datei herunterladen, nicht nur von der Berichtsseite aus.
  • Das Kontomenü verlässt auf kleinen Bildschirmen die eingeklappte Navigation und bekommt ein eigenes Panel.
  • Die Connectors-Seite wurde daraufhin durchgesehen, was sie sagt und in welcher Reihenfolge.