Tool descriptions were leaking internal vocabulary (Django superuser,
Postgres bcrypt update, htpasswd in protectionauth.yml, gitea admin
user change-password CLI, trusted_domains list, …) and repeating the
label as a full sentence. Beginners don't care, and even experienced
users don't need the CLI name to know what a button does.
Rewrites every tool description to a single short sentence plain
enough that a first-time installer can read it without context.
Conventions applied across the board:
- One sentence, sentence-case
- Plain English: "Set a new password", "Add a new user",
"Permanently remove a user", "List every user"
- "Leave blank to generate one" only where it's actually useful
(password fields), and matches the field placeholder text
- No CLI names, no schema field names, no internal file paths
- Destructive actions stop saying "permanently" twice (the action
label + the confirm modal already cover that)
- Field placeholders harmonised: "Leave blank for random" /
"Leave blank to generate" → consistently "Leave blank to generate"
Touched files (descriptions only — no logic, no fields removed):
containers/adguard/tools/adguard.tools.json
containers/bookstack/tools/bookstack.tools.json
containers/dashy/tools/dashy.tools.json
containers/focalboard/tools/focalboard.tools.json
containers/gitea/tools/gitea.tools.json
containers/gluetun/tools/gluetun.tools.json
containers/invidious/tools/invidious.tools.json
containers/linkding/tools/linkding.tools.json
containers/nextcloud/tools/nextcloud.tools.json
containers/pihole/tools/pihole.tools.json
containers/traefik/tools/traefik.tools.json
Signed-off-by: librelad <librelad@digitalangels.vip>
Linkding has shipped without any Tools-tab actions since v0.1.0 — the only
artifact was scripts/menu/tools/manage_linkding.sh, a dead legacy CLI menu
referencing an `appLinkdingSetupUser` function that was never defined.
Build the real thing, mirroring bookstack's pattern (manifest + thin tool
wrappers + auth_adapter that drives the app's native admin shell):
containers/linkding/tools/linkding.tools.json — manifest, 5 tools
containers/linkding/tools/linkding_<id>.sh — one wrapper per tool
containers/linkding/scripts/linkding_auth.sh — Django shell driver
Tools (all category=users, so the WebUI's custom user-list panel and its
row-level 🔑 / 👑 / 🗑 buttons light up):
reset_password — set_password on an existing user (random if blank)
create_account — create_user / create_superuser
list_users — emits EZ_USER\t<username>\t<username>\t<role> rows
(linkding is username-primary, so username goes into
both display slots — keeps the panel click-through
identifier consistent with the other tools' fields)
delete_user — delete by username (destructive, confirm gated)
set_admin — toggle is_superuser + is_staff
Implementation runs entirely inside the linkding-service container via
`runFileOp docker exec ... python manage.py shell -c "<code>"`, reading
inputs through `-e` env vars so quoting stays safe. Django's default
get_user_model() User is used directly — passwords hash exactly the way
the web UI does, admin flags map to the same fields the UI reads.
Also drop the dead legacy stub (scripts/menu/tools/manage_linkding.sh)
and regenerate files_menu.sh so the source-scan no longer pulls it in.
Nothing referenced linkdingToolsMenu — verified by tree-wide grep.
Verified live on dev-ai (Debian 12, linkding installed, Django 5 + sqlite):
$ libreportal app tool linkding create_account 'username=alice|password=…|admin=true'
✓ Linkding user created — Username: alice — Password: …
$ libreportal app tool linkding list_users ''
EZ_USER alice alice admin
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: librelad <librelad@digitalangels.vip>
