Request: Text input in export options for custom config filenames
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
PROBLEM:
I work on lots of different events with individual companion configs. I always need to rename exported config files according to the event for future use, because the filename defaults to something like ${HOST}_custom-config_${DATE}-${TIME}.companionconfig. Not a dealbreaker, but it annoys me from time to time.
SOLUTION: A text input to enter a custom filename as an export option would be highly welcomed. Event more if it would support variables (maybe only "internal" and "custom variables") or another form of placeholders for time, date etc.
Using variables e.g., the name would still default to $(internal:hostname)_custom-config_$(internal:date_y)$(internal:date_m)$(internal:date_d)-$(internal:time_h)$(internal:time_m) but can be customized to something like $(internal:custom_configname)_$(internal:date_y)$(internal:date_m)$(internal:date_d)$(internal:time_h)$(internal:time_m)$(internal:time_s) (typical scheme I like to use).
I'm not sure what should happen if companion gets reset, a config gets imported or whether to export the current naming scheme to a config file. Maybe it would be best to have a little checkbox in all 3 scenarios to have the option to keep the current scheme after reset, overwrite a scheme from an imported config file (if available) or export current scheme to config file.
In addition some UI indicators would be a nice to have, to make this feature more convenient.
- If the naming scheme includes custom variables and the config gets exported including the current naming scheme but not with "custom variables" selected, something should inform the user about that and the possible impact.
- The same situation as described above but for importing a config. If a naming scheme includes custom variables but the config doesn't have any or available custom variables don't get imported, the user should be informed about that and possible effects.
- Some visual reminder to add custom variables used in the naming scheme after reset when still keeping the naming scheme. Or even better, keep any used custom variables from the naming scheme to ensure functionality and inform the user that those variables can't be reset because they are currently in use.
Usecases
I for myself would manifest a workflow of adding a custom variable "configname" to dynamically change the config filename for each specific event/project and keep the naming scheme no matter if companion gets reset or a config gets imported. This way I only ever need to set this variable to a suitable name once and all exports (daily backups or whatever) will include this name.
In general, I also think that this flexibility would be appreciated by other users a lot since it adds more/better possibilities to manage config files by having individual naming schemes/templates, without manually renaming each config file.