Hello,
I couldn’t find a topic where feature requests related to this are made, but I think it would be great to be able to choose the preferred communication channel at the global level as well as a choice between the different configured communication channels to send messages.
Indeed, after installing the external integration Olvid, I have a duplicate with Telegram.
While I would potentially like to send messages to one or the other integration.
For example, if the Olvid integration fails, the notification should be sent to Telegram and vice versa.
I know the case is a bit far-fetched, but it’s up for discussion
Already thought about it and the PR has been merged this morning, it will be in the next Gladys update.
However, this is a choice that needs to be made manually in the scenes
It’s clear, and with the amount of integrations you’re pulling out, you can’t keep up with all the topics.
And there are more on the way
you fully optimize the claude plan
Yes, we have until the 19th, even though I hope they will keep this limit or increase it.
I have an issue with the message sending channel selection:
And if I choose the first « Telegram » it works, but not if I choose the second one
Actually, there are 3 native CallMeBot, Telegram, and Nextcloud Talk integrations that are enabled each time. We’ll fix that.
external: you should specify that in the selection
mutmut
August 14, 2026, 8:31pm
13
Is it possible to only display the configured and therefore active integrations?
@pierre-gilles , here’s the PR
master ← William-De71:fix/message-service-selector-configured-only
ouvert 09:34AM - 19 Aug 26 UTC
### Description
The "send message" scene action offered CallMeBot, Telegram a… nd Nextcloud Talk even when the user had never configured them, and showed a duplicate Telegram entry next to the external Telegram integration.
getMessageServices() only checked that a service was loaded and exposed message.sendToUser. That proves nothing about configuration: a core service whose start() throws a ServiceNotConfiguredError stays RUNNING, stays in the stateManager and keeps its sendToUser method.
Filter on the isUsed() hook instead, the convention getUsage() already relies on. External integrations are kept as-is (installed means configured, and a proxied service exposes no hook), and a core service without the hook is kept too, as there is nothing to check it against.
Telegram had no isUsed() hook: add one, based on TELEGRAM_API_KEY, exactly like start() does. CallMeBot and Nextcloud Talk already had theirs.
Also disambiguate the selector labels: a native service and an external integration can display the very same name, so append "built-in integration" / "external integration" when two channels would otherwise be identical.
<img width="594" height="248" alt="image" src="https://github.com/user-attachments/assets/08a7fbd6-921b-407c-858b-c1d5b60d6b87" />
## Forum
Reported at https://community.gladysassistant.com/t/choix-canal-communication/10549
### Checklist
- [x] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [x] No undocumented breaking change
## Summary by CodeRabbit
* **New Features**
* Message service selectors now distinguish external integrations from built-in services, including when names overlap.
* Unavailable services are clearly indicated while remaining selectable where applicable.
* Added German, English, and French translations for service type labels.
* **Bug Fixes**
* Service discovery now excludes unconfigured or invalid built-in messaging services while retaining valid integrations.
* **Documentation**
* Updated API examples to reflect service type information.
Thanks, that works for me
