Include surface settings in Configuration Import/Export
Is this a feature relevant to companion itself, and not a module?
- [x] I believe this to be a feature for companion, not a module
Is there an existing issue for this?
- [x] I have searched the existing issues
Describe the feature
This is something I find a bit frustrating - every time I export and import configuration (as I often edit it on other computers to re-import on the actual server) I have to change the surface pages and settings again. This breaks all my tallies, phone emulators I provide to people so they can perform duties wirelessly etc.
Can these settings please be included in the configuration backup?
Thank you!
Usecases
Quality of life, as per description.
https://github.com/bitfocus/companion/pull/2875 is probably relevant to this.
I experienced this too, although I notice that the surface Row and Column count is maintained, but not the Offset.
It turns out that this issue is not related to saving config settings (#2875, #3538), but is in fact a bug in the current import/export code!
If you look at human-readable versions of the export files, it turns out that surface settings are already being saved on export and read on import (current beta 4.1, but no doubt 4.0 stable and even earlier). The main problem is that page numbers/id are not being saved properly and/or rematched. So in YAML for example, page id's are not saved in the page definition but the nanoid() of the page is being used in the surface config for start/last page.
pages:
"1":
name: Page 1
...
...
streamdeck:<serialID>:
groupConfig:
name: Unnamed group
last_page_id: rihBOgFWIpgpE8NQqBfLP
startup_page_id: rihBOgFWIpgpE8NQqBfLP
use_last_page: false
...
I started tracing where best to fix it but would be just as happy if one of the experts take it on. (If you want me to do it, just LMK/assign this to me.)
And here's a bit of irony (or what in tech jargon is called the source of a "reversion," I believe)... whenever this deprecation happened is likely when this Issue became an issue. So now we'll have to convert to/from page numbers when exporting/importing, I suppose... (Using internal ID's isn't a bad thing, if it allows pages to be tracked when they are moved...) This change appears to have been added in v3.5 as part of the upgraded page handling. shared-lib/lib/model/Surface.ts
export interface SurfaceGroupConfig {
name: string
last_page_id: string
startup_page_id: string
use_last_page: boolean
/** @deprecated. replaced by last_page_id */
last_page?: number
/** @deprecated. replaced by startup_page_id */
startup_page?: number
}
I might as well take a shot at fixing this issue "just for fun"...
I just want to say it more directly: this issue should be classified as a bug, not a feature request -- see my explanation in the previous two comments. (Consequently, the PR that I will submit shortly should be considered for inclusion in a minor release...)