Falco
Novembre 12, 2022, 5:44
1
À partir d’aujourd’hui, la notification de discussion Discourse permet aux utilisateurs de répondre directement dans la notification elle-même
L’interface utilisateur pour cela est différente sur chaque système d’exploitation, car elle s’intègre au système de notification natif.
Si tout va bien, les prochaines étapes possibles pour cette fonctionnalité pourraient être :
Ajouter la prise en charge des réactions en ligne
Envoyer les réponses en ligne comme « en réponse à » le message auquel elles répondent
Ajouter la prise en charge des réponses en ligne pour les sujets / publications
Gérer les erreurs lors de l’envoi de réponses en ligne, qu’il s’agisse d’erreurs réseau ou de logique métier.
i18n du bouton de réponse et du placeholder
27 « J'aime »
C’est un excellent ajout. J’étais tellement confus quand j’ai pensé : « wow, une image d’exemple dynamique montrant mon nom d’utilisateur », puis j’ai réalisé que ce n’était qu’une capture d’écran de mon nom d’utilisateur.
J’adore la rapidité avec laquelle cette fonctionnalité de chat se développe - j’ai hâte que le moment soit venu de l’ajouter à notre communauté. Autant j’aime Discord, autant, dans notre cas d’utilisation commerciale, je ne veux vraiment pas avoir une autre plateforme à gérer et à fragmenter mes utilisateurs.
Une fonctionnalité agréable serait de pouvoir sélectionner un ou plusieurs messages de chat et de les transformer en un sujet.
9 « J'aime »
Quand la prise en charge d’iOS sera-t-elle disponible ? Je dois toujours utiliser une application tierce pour recevoir des notifications push instantanées avec du contenu.
2 « J'aime »
Falco
Novembre 12, 2022, 11:02
7
Aucune idée, c’est à Apple. Nous implémentons la norme ouverte du web et cela fonctionne sur tous les systèmes d’exploitation qui implémentent la spécification, comme Windows, Android, Chrome OS, etc. On peut espérer que lorsque/si Apple implémente WebPush en 2023, ils le feront correctement, mais tout ce que nous pouvons faire, c’est espérer.
15 « J'aime »
Falco
Mai 11, 2026, 8:12
8
Cela ne fonctionnait pas depuis un certain temps, et j’ai réintégré la prise en charge de manière plus robuste
main ← chat-push-quick-reply
merged 03:36PM - 29 Apr 26 UTC
**Previously**, the "Reply" action on chat web push notifications was silently b… roken — the service worker's chat URL regex stopped matching when chat routes moved to `/chat/c/:slug/:id`, and the chat-specific code lived in core with no thread support, URL encoding, or error handling.
**In this update**, generalize the core service worker into a plugin-extensible action registry, move chat reply handling into the chat plugin with proper thread/encoding/fallback support, and convert single-emoji replies into reactions on the source message (falling back to a regular message post on any failure).
## Architecture
Core (`app/views/static/service-worker.js.erb`) now exposes:
```js
self.registerNotificationActionHandler(action, handler);
```
Push payloads can carry `actions` (Web Notifications API format) and `action_data` (an arbitrary object surfaced to the handler at `event.notification.data.actionData`). The click handler dispatches by `event.action` name and falls back to the existing focus-or-open behavior when no handler matches or a handler throws.
`PushNotificationPusher` forwards `actions` / `action_data` when present.
The chat plugin owns its own service worker (`plugins/chat/assets/javascripts/service-worker.js`), registered via `register_service_worker`. It registers a `chat-reply` handler that:
1. Fetches a CSRF token.
2. If the reply is a single emoji grapheme (detected via `Intl.Segmenter`, with a `\p{Extended_Pictographic}` regex fallback), `PUT`s to `/chat/:channel_id/react/:message_id`.
3. Otherwise — or if the reaction request fails — `POST`s to `/chat/:channel_id` with proper `URLSearchParams` encoding and the source `thread_id` if present.
4. If everything fails, opens the channel so the user can retype.
`Chat::Notifier.push_notification_reply_action(chat_message, user)` builds the payload in the user's locale with `channel_id`, `message_id`, and optional `thread_id`.
`Chat::MessageReactor#react!` resolves raw Unicode via `Emoji.unicode_replacements[emoji] || emoji` before validation, so smartwatch quick-reply chips (which send raw Unicode like `👍🏽` or ZWJ sequences) just work. Existing shortcode callers are unaffected.
## Why this matters
Smartwatch notification UIs expose a single "reply" affordance with canned chips that include short text and emoji. The user can't choose between "send as message" and "react"; they tap a chip and a string comes through. Treating a single-grapheme pictographic reply as a reaction matches user intent on the watch UX without any new product surface.
## Test plan
- [ ] On a chat-enabled site, subscribe to web push notifications.
- [ ] Have another user post a message that mentions you, or a watched channel message.
- [ ] On the resulting OS notification, confirm a "Reply" action button appears.
- [ ] Type a text reply and submit — verify it posts as a message in the right channel/thread.
- [ ] Submit a single emoji (e.g. 👍 or 👍🏽 with skin tone) — verify it lands as a reaction on the source message instead of posting a message.
- [ ] Submit a ZWJ sequence (e.g. 👨👩👧) — verify it lands as a reaction (or falls back to message post if not in the emoji DB).
- [ ] Sign out / let session expire and submit a reply — verify the channel opens as a fallback rather than silently failing.
- [ ] Watch via Wear OS / watchOS quick-reply chips and confirm the same behavior end-to-end.
Désormais, nous capturons également les réponses constituées d’un seul emoji en tant que réaction, et nous prenons en charge les threads de chat ! .
5 « J'aime »
Wow ! C’est vraiment génial ! Avez-vous prévu de faire de même pour les sujets ?
1 « J'aime »
Petite question: cela fonctionne sur Apple ?
Falco
Mai 16, 2026, 4:02
11
