* Add one-shot app_config linter migration workflow * Add app_config linter compatibility action * Add add-on map compatibility normalizer * Test add-on map compatibility normalizer * Run app_config compatibility preparation on pull request * Validate app_config short and long map forms separately * Export validated workflow updates * Use app_config-compatible linter for PR checks * Use app_config-compatible linter for builds * Remove temporary linter preparation workflow * Add one-shot app_config manifest migration * Migrate legacy addon_config maps to app_config * Preserve upstream legacy aliases without deprecated literals * Test legacy alias compatibility without deprecated literals * Validate completed app_config migration * Count only add-on manifests during migration validation * Remove temporary migration validation workflow * Document legacy alias construction * Remove obsolete local linter compatibility script * Remove obsolete local linter compatibility tests * fix(pr-2937-review): address reviewer findings on app_config migration - Remove the orphaned .github/actions/addon-linter composite action: it references .github/scripts/prepare_addon_lint_config.py, which was never added (the normalization approach was superseded by pinning frenck/action-addon-linter directly in #2936). Confirmed unused - no workflow invokes it. - cleanuparr: HA_DATA_DIR pointed at /app_configs/cleanuparr, a path not mounted inside the container. cleanuparr's map is app_config:rw, which Supervisor mounts at /config, so data was living on the ephemeral container filesystem. Point it at /config instead (pre-existing bug, not introduced by this PR - just carried the wrong path forward). - joplin/README.md: joplin's config.yaml still declares config:rw, not app_config (it was never part of the 86-manifest migration). Revert the doc text that incorrectly started calling it the app_config mapping. - qbittorrent/00-folders.sh: fix a pre-existing copy/paste bug in the migration marker/log for the main-folder migration block - it referenced "openvpn" and a "qBitorrent" typo instead of qBittorrent. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
7.8 KiB
Home assistant add-on: Collabora
I maintain this and other Home Assistant add-ons in my free time: keeping up with upstream changes, HA changes, and testing on real hardware takes a lot of time (and some money). I use around 5-10 of my >110 addons so regularly I install test machines (and purchase some test services such as vpn) that I don't use myself to troubleshoot and improve the addons
If this add-on saves you time or makes your setup easier, I would be very grateful for your support!
Addon informations
Thanks to everyone having starred my repo! To star it click on the image below, then it will be on top right. Thanks!
About
Collabora Online is a collaborative office suite based on LibreOffice technology.
Installation
- Add my add-ons repository to your Home Assistant instance or click the My link below.
- Install the add-on.
- Start the add-on.
- Check the add-on logs to verify successful startup.
Configuration
Webui can be found at https://homeassistant:9980/browser/dist/admin/admin.html.
Options
| Option | Type | Default | Description |
|---|---|---|---|
aliasgroup1 |
str | External address of the Nextcloud server allowed to use this Collabora (e.g. https://nextcloud_domain\.com:443) |
|
aliasgroup2 |
str | A second Nextcloud server, same format as aliasgroup1 |
|
aliasgroup3 |
str | A third Nextcloud server, same format as aliasgroup1 |
|
server_name |
str | External hostname (and port) of this Collabora server, as the browser reaches it (e.g. code_domain.com:9980). Set it when Collabora sits behind a reverse proxy |
|
ssl_termination |
bool | false |
Set to true when ssl is false but the browser reaches Collabora over https through a reverse proxy |
extra_params |
str | Extra parameters passed to the Collabora start script | |
ssl |
bool | false |
Enable SSL using certificates from /ssl |
certfile |
str | fullchain.pem |
Certificate file name located in /ssl |
keyfile |
str | privkey.pem |
Private key file name located in /ssl |
cert_domain |
str | Common name of the self-signed certificate generated when ssl is false |
|
username |
str | Username for the Collabora admin console | |
password |
str | Password for the Collabora admin console | |
dictionaries |
str | Space-separated list of dictionary languages to install | |
domain1 |
str | Deprecated, use server_name instead |
About the escaped dots in aliasgroup*
Collabora matches the aliasgroup* addresses as regular expressions, so a dot
has to be escaped with a single backslash: next\.duckdns\.org, not
next\\.duckdns\\.org. A doubled backslash means "a literal backslash followed by
any character", which never matches a real hostname, and Collabora then rejects the
Nextcloud server.
Earlier versions of this page asked for two backslashes, which was wrong. The add-on
now normalises whatever you type, so next.duckdns.org, next\.duckdns\.org and
next\\.duckdns\\.org all end up as the same correct pattern. The value that is
really handed to Collabora is printed in the add-on log at startup:
Allowed Nextcloud host aliasgroup1: https://next\.duckdns\.org:443
Values containing other regex characters (*, |, (, [, …) are left untouched,
so hand-written patterns keep working.
server_name is not a regular expression: write it as a plain hostname, without
backslashes.
Example configuration
Nextcloud on https://next.duckdns.org and Collabora reachable on
https://code.duckdns.org:9980, with a reverse proxy handling the certificates:
aliasgroup1: https://next\.duckdns\.org:443
server_name: code.duckdns.org:9980
ssl_termination: true
ssl: false
username: admin
password: changeme
Same setup, but letting the add-on serve the certificates itself from /ssl:
aliasgroup1: https://next\.duckdns\.org:443
server_name: code.duckdns.org:9980
ssl: true
certfile: fullchain.pem
keyfile: privkey.pem
username: admin
password: changeme
Using Collabora with Nextcloud
- Install the Collabora add-on and configure the options above.
- Start the add-on and expose the Collabora server to an external domain.
- Install and configure the Nextcloud add-on.
- Inside Nextcloud, install the Nextcloud Office app.
- In Nextcloud Administration Settings → Office, set the Collabora server URL to
the Collabora address, not the Nextcloud one — with the example above that is
https://code.duckdns.org:9980— and enable Disable certificate validation if the add-on serves a self-signed certificate. - Add both hostnames to the Nextcloud
trusted_domains.
The two hostnames have different roles, and swapping them is the most common cause of
Could not establish connection to the Collabora Online server:
aliasgroup1is the Nextcloud address, it tells Collabora which server is allowed to ask it to open documents.server_nameis the Collabora address, it tells Collabora which URL to hand back to the browser.
Custom Scripts and Environment Variables
This addon supports custom scripts and environment variables through the app_config mapping:
- Custom scripts: See Running Custom Scripts in Addons
- env_vars option: Use the add-on
env_varsoption to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.
Support
Create an issue on GitHub
