Typ: bug — ett dokumenterat konfigurationsfält har aldrig fungerat i listvyn.
Description
The optional name field for dashboard services is documented in the config schema as
"Optional alternative display name", but it is never used by the service list endpoint.
The list always falls back to the unit name with .service stripped.
The cause is a dictionary lookup with a literal string instead of the loop variable.
endpoints/system/misc.py, getDashboardServices():
known = {service["unit"]: service for service in Config["options"]["dashboard"]["services"]}
if len(known) == 0:
return jsonify(services=[])
with Service("systemd") as sysd:
units = [{"name": known.get("unit", {}).get("name") or unit["unit"].replace(".service", ""), **unit}
for unit in sysd.getServices(*known).values()]
known is keyed by unit name ("rspamd.service", "mariadb.service", …), so
known.get("unit", {}) looks up the literal string "unit", never matches, returns {}, and
.get("name") yields None. The fallback is therefore always used.
The neighbouring single-service endpoint getDashboardService() handles this correctly:
unit["name"] = service.get("name", service["unit"].replace(".service", ""))
so a configured name appears in the detail view but not in the list.
Steps to reproduce
-
Add a display name to a dashboard service in /etc/grommunio-admin-api/conf.d/:
options:
dashboard:
services:
- unit: rspamd.service
name: Antispam
-
systemctl restart grommunio-admin-api
-
Open the admin web interface → Dashboard → service list.
Expected: the entry is shown as Antispam.
Actual: the entry is shown as rspamd.
grommunio-admin config dump shows the name field correctly, so the configuration is loaded —
only the list endpoint discards it.
Suggested fix
- units = [{"name": known.get("unit", {}).get("name") or unit["unit"].replace(".service", ""), **unit}
+ units = [{"name": known.get(unit["unit"], {}).get("name") or unit["unit"].replace(".service", ""), **unit}
for unit in sysd.getServices(*known).values()]
Note that **unit is expanded after "name", so if getServices() ever returns a name key it
will override the configured one. Setting it after the expansion — as getDashboardService() does —
would be more robust.
Environment
grommunio-admin-api 1.20.23.m9ff33fc-1+43.1
gromox 3.9.195.m185aab5-1+34.1
OS Ubuntu 24.04.4 LTS
Repo community/Ubuntu_24.04
Why it matters on Debian/Ubuntu
On openSUSE the unit names are grommunio's own packages and read as descriptions
(grommunio-antispam), so the missing display name is not obvious. On Debian/Ubuntu the same
services are distribution packages named after the product (rspamd, mariadb,
redis-server@grommunio), which says nothing about their role. The name field is exactly the
mechanism that would fix this — and it is the platform where it does not work that needs it most.
Description
The optional
namefield for dashboard services is documented in the config schema as"Optional alternative display name", but it is never used by the service list endpoint.
The list always falls back to the unit name with
.servicestripped.The cause is a dictionary lookup with a literal string instead of the loop variable.
endpoints/system/misc.py,getDashboardServices():knownis keyed by unit name ("rspamd.service","mariadb.service", …), soknown.get("unit", {})looks up the literal string"unit", never matches, returns{}, and.get("name")yieldsNone. The fallback is therefore always used.The neighbouring single-service endpoint
getDashboardService()handles this correctly:so a configured name appears in the detail view but not in the list.
Steps to reproduce
Add a display name to a dashboard service in
/etc/grommunio-admin-api/conf.d/:systemctl restart grommunio-admin-apiOpen the admin web interface → Dashboard → service list.
Expected: the entry is shown as
Antispam.Actual: the entry is shown as
rspamd.grommunio-admin config dumpshows thenamefield correctly, so the configuration is loaded —only the list endpoint discards it.
Suggested fix
Note that
**unitis expanded after"name", so ifgetServices()ever returns anamekey itwill override the configured one. Setting it after the expansion — as
getDashboardService()does —would be more robust.
Environment
Why it matters on Debian/Ubuntu
On openSUSE the unit names are grommunio's own packages and read as descriptions
(
grommunio-antispam), so the missing display name is not obvious. On Debian/Ubuntu the sameservices are distribution packages named after the product (
rspamd,mariadb,redis-server@grommunio), which says nothing about their role. Thenamefield is exactly themechanism that would fix this — and it is the platform where it does not work that needs it most.