Falco
12 Novembre 2022, 5:44pm
1
A partire da oggi, la notifica di Discourse Chat consente agli utenti di rispondere inline direttamente nella notifica stessa
L’interfaccia utente per questo è diversa su ogni sistema operativo, poiché si integra nel sistema di notifica nativo.
Se tutto va bene, i possibili prossimi passi per questa funzionalità potrebbero essere:
Aggiunta del supporto per le reazioni inline
Invio delle risposte inline come “in risposta a” al messaggio a cui si sta rispondendo
Aggiunta del supporto per le risposte inline per argomenti/post
Gestione degli errori durante l’invio delle risposte inline, siano essi errori di rete o di logica di business.
i18n del pulsante di risposta e del segnaposto
26 Mi Piace
Questa è un’ottima aggiunta. Ero così confuso quando ho pensato: “wow, un’immagine di esempio dinamica che mostra il mio nome utente”, e poi mi sono reso conto che era solo uno screenshot del mio nome utente.
Adoro quanto velocemente questa funzionalità di chat sta crescendo: non vedo l’ora che arrivi il momento giusto per aggiungerla alla nostra community. Per quanto ami Discord, dal nostro caso d’uso aziendale, non voglio davvero un’altra piattaforma da gestire e in cui frammentare i miei utenti.
Una bella funzionalità sarebbe quella di selezionare uno o più messaggi di chat e separarli in un argomento.
9 Mi Piace
Quando avverrà il supporto per iOS? Ho ancora bisogno di un’app di terze parti per ricevere notifiche push istantanee con contenuto.
2 Mi Piace
Falco
12 Novembre 2022, 11:02pm
7
Non ne ho idea, quello dipende da Apple. Noi implementiamo lo standard aperto del web e funziona su ogni sistema operativo che implementa le specifiche, come Windows, Android, Chrome OS, ecc. Si può sperare che quando/se Apple implementerà WebPush nel 2023 lo farà correttamente, ma tutto ciò che possiamo fare è sperare.
15 Mi Piace
Falco
11 Maggio 2026, 8:12pm
8
Questo era rotto per un po’ di tempo, e ho ripristinato il supporto in modo più robusto
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.
Ora catturiamo anche le risposte composte da un singolo emoji come reazione e supportiamo le chat thread! .
5 Mi Piace
Wow! È davvero figo! Avete in programma di fare lo stesso per gli argomenti?
1 Mi Piace
