# User Widget Improvement

**URL:** <https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368>\
**Category:** Demande de fonctionnalités\
**Tags:** feature-request-ux\
**Created:** [October 19, 2026, 12:49pm UTC](https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368 "2026-10-19T12:49:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![stefanbauer](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stefanbauer/32/23593_2.png) [@stefanbauer](https://community.gladysassistant.com/u/stefanbauer)\
**Post date:** [October 19, 2026, 12:49pm UTC](https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368/1 "2026-10-19T12:49:10Z")

</div>

Got it, I’ll try to figure it out. It’s a bit off-topic here, but I don’t know where else to ask this specific question because it fits thematically quite well:

I built a major change to the user presence widget today (haven’t created the PR yet). A screenshot speaks more than a thousand words. This is both a visual and functional improvement (I think). Are such changes to the core desired, or should I rather build my own external integration that simply provides such a widget? I’m really not sure. In this context, I also added an action for scenes to set the location/coordinates, for example from device trackers, and integrated this into the MCP server.

Don’t get me wrong: I just don’t want to invest time if it’s a path you absolutely don’t want to take. Then I’ll stop here and rather build the whole thing as an external integration 🙂

I just don’t know who to contact specifically with such questions and be sure to get a corresponding (correct) answer.

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/a/0/a00d1e904c86779bd49bd47fd82f4ff011375a03.jpeg)

---

<div class="post-metadata">

**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\
**Post date:** [October 19, 2026, 2:08pm UTC](https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368/2 "2026-10-19T14:08:10Z")

</div>

Hello,

I’ve moved your message to a new conversation for clarity.  
This widget is part of the core of Gladys, like user localization. I think it should stay there and improvements should be made without external integrations.  
However, one of the strong values of Gladys is simplicity (to go against excessive customization to be exactly as each person would like to see their dashboard).

I think the three options make sense (but not text customization).

---

<div class="post-metadata">

**Author:** ![stefanbauer](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stefanbauer/32/23593_2.png) [@stefanbauer](https://community.gladysassistant.com/u/stefanbauer)\
**Post date:** [October 19, 2026, 2:21pm UTC](https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368/3 "2026-10-19T14:21:48Z")

</div>

Hey! All good, I’ll just push the PR later. Then you can take a look at it. There are still a few minor things here and there that we might want to move into their own PR. But we can discuss that in the PR.

First and foremost, it wasn’t about the options, but that the «&nbsp;time away&nbsp;» was previously displayed in the badge, which, graphically speaking, was… let’s just call it «&nbsp;not pretty&nbsp;» 😉

---

<div class="post-metadata">

**Author:** ![stefanbauer](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/stefanbauer/32/23593_2.png) [@stefanbauer](https://community.gladysassistant.com/u/stefanbauer)\
**Post date:** [October 19, 2026, 2:57pm UTC](https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368/4 "2026-10-19T14:57:36Z")

</div>

> <https://github.com/GladysAssistant/Gladys/pull/3241>
>
> \## Description
> 
> Improve the dashboard user-presence widget and add a native scen…e action for updating a user's GPS location. The widget improvements relate to the forum discussion below; the location action also lets existing automations update coordinates without an HTTP action or an OwnTracks-compatible webhook.
> 
> \### User-presence widget
> 
> \- Keep badges compact and show only the localized presence status in them.
> \- Move the elapsed time to a smaller, muted, right-aligned line immediately below the badge.
> \- Fix German relative durations: \`seit 7 Stunden\`, not \`seit vor 7 Stunden\`, including the correct singular/dative forms. Normal relative dates elsewhere in the app are unchanged.
> \- Add three independent widget settings:
> - \*\*Show last names\*\* — disabled by default.
> - \*\*Show time away\*\* — enabled by default, preserving the existing information.
> - \*\*Show time at home\*\* — disabled by default.
> \- Display \*\*all users when the selection is empty or omitted\*\*. Selecting specific users filters the widget; clearing the selection restores everyone, including after save/reload.
> \- Keep status labels fixed and localized: there are \*\*no customizable status-text fields\*\*.
> \- Preserve minute-by-minute updates, presence WebSocket updates, and the “Never Seen At Home” state when no house-change timestamp exists. Missing timestamps do not produce invented durations.
> \- Support narrow cards and mobile layouts without overflowing names, badges or durations.
> 
> \### Native user-location scene action
> 
> \- Add \*\*Set a user's location\*\* (\`user.set-location\`) to the scene action picker, with a selected user, latitude and longitude.
> \- Accept fixed numeric coordinates or existing scene variables from a trigger or a previous action, using the usual variable-aware inputs. For example, latitude can reference \`{{0.0.value}}\` and longitude \`{{1.0.value}}\`.
> \- Validate both resolved coordinates before writing: latitude −90…90, longitude −180…180, finite and nonempty; zero and negative values are valid. Invalid/missing variables abort subsequent sequential actions rather than recording an incorrect location.
> \- Reuse \`location.create\`, preserving location history, the user's last-location fields, location WebSocket updates, and area entry/exit events.
> \- \*\*Do not directly change home/away presence.\*\* Existing area-triggered scenes and home/away actions remain responsible for that, under the existing scene permission model.
> \- Keep coordinate variable references correct when scene steps are inserted, deleted or reordered; add the action to collapsed summaries and the MCP scene-creation schema as well.
> \- This does \*\*not\*\* add a Find My integration, a new webhook or a new REST endpoint. The automation must already have access to its location data.
> 
> All additions have English, French, German and Spanish translations. The existing dashboard specification is updated, and the location action has its own contract specification. No SQL migration is required; legacy widgets retain their defaults.
> 
> \## Related request
> 
> Forum: https://community.gladysassistant.com/t/amelioration-widget-utilisateurs/11368
> 
> \## Screenshots
> 
> All screenshots use synthetic test users and coordinates.
> 
> | Default widget | Widget settings |
> | --- | --- |
> | !\[Compact presence badges with elapsed time underneath\](https://ampcode.com/user-content/artifacts/e73708cd3d89c09fcd74474fd88c3e51048142ca2d90911280ce2fbfab422fad-file.png) | !\[User selector and three independent presence options\](https://ampcode.com/user-content/artifacts/3883efdec233a506113724a7fba0e5fb929e2202d9b6c498cf9c1fd5f7f9045d-file.png) |
> 
> \### User-location scene action
> 
> !\[Native scene action with user selector and latitude/longitude fields\](https://ampcode.com/user-content/artifacts/c241a08508e3a1024be9ebe478a8b24a68b8342fbf3c7532357e1958f8d34181-file.png)
> 
> \<details\>
> \<summary\>Mobile layouts\</summary\>
> 
> | Presence widget with last names and both durations | Location scene action |
> | --- | --- |
> | !\[Mobile presence widget\](https://ampcode.com/user-content/artifacts/d34e71fbfb1585873c993abd77a9cc8528dfa55131acc7969c60cbce0f234733-file.png) | !\[Mobile coordinate editor\](https://ampcode.com/user-content/artifacts/e0a7f625ecaf81e4ad2beda10e1ab984c13997b729c6726dfc1f0dfd10bfbaaf-file.png) |
> 
> \</details\>
> 
> \## Verification
> 
> \- Front: \`npm run prettier\`, \`npm run prettier-check\`, \`npm run eslint\`, \`npm run compare-translations\`, and \`npm run build\` passed.
> \- Server: \`npm run prettier\`, \`npm run prettier-check\`, and \`npm run eslint\` passed (existing lint warnings remain).
> \- 19 relevant Cypress tests passed on a fresh, isolated instance: existing dashboard/scene flows plus the new widget and location-action regressions. The selection regression was reproduced before the fix. Desktop/mobile screenshots were inspected.
> \- Targeted server regressions cover dashboard persistence/defaults/validation, coordinate bounds/zero/negative values, trigger and previous-action variables, invalid-input aborts, unchanged house presence, area entry/repeated locations/exit, and MCP schema acceptance/rejection.
> \- Latest local \`TZ=UTC npm run coverage\`: \*\*8,447 passed, 1 pending, 1 failed\*\*. The remaining failure is the existing HomeKit test binding port \`47129\`, already occupied by another local Gladys instance. This was reproduced against unchanged code; that instance was not stopped or modified. Full Linux CI results are tracked below by GitHub checks; the local full-suite result is not being reported as green.
> 
> \## Checklist
> 
> \- \[x\] Related forum topic linked above.
> \- \[x\] Front and server lint/format checks pass.
> \- \[x\] Front translations and production build pass.
> \- \[x\] Relevant end-to-end flows pass, including persisted empty selections and reordered coordinate variables.
> \- \[x\] Living specifications updated; no SQL migration or undocumented API/permission change.
> \- \[\] Full server coverage and the complete CI workflow pass (see GitHub checks).

Feel free 🙂
