You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There are some configuration elements that should apply globally and not change when a snapshot is recalled. There are others that should be recalled from a snapshot and others that should be recalled from a zs3. There is overlap of these sets of configuration that different user workflows may require different behaviour.
Describe the solution you'd like
Consolidate the configuration into a single, consistent format. (Currently stored in files, envvars, etc.)
Have a set of configuration that are global and not saved in snapshot.
Have a set of configuartion that are set in snapshot.
Have a set of configuartion that are set in zs3.
Identify configurations that may be beneficial to store in zs3/snapshot/global. Add a mechanism to flag these to indicate where they are stored and/or restored.
Describe alternatives you've considered
Resave all ZS3 & sanpshots when a setting has changed due to workflow change.
Additional context
An example of where you might want to store a configuration differently, depending on workflow is mentioned in #1279. The tools to decide whether options should be stored in / recalled from zs3/snapshot need to be simple, maybe listbox accessible via zs3/snapshot context menus and ideally also in webconf.
State is stored in snapshot in json matching the state schema. This could be expanded so that the snapshot is a branch of the full configuration including global configuration - or an overlay so that saved elements may be restored over existing ones and non-saved elements don't change value on recall.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
There are some configuration elements that should apply globally and not change when a snapshot is recalled. There are others that should be recalled from a snapshot and others that should be recalled from a zs3. There is overlap of these sets of configuration that different user workflows may require different behaviour.
Describe the solution you'd like
Consolidate the configuration into a single, consistent format. (Currently stored in files, envvars, etc.)
Have a set of configuration that are global and not saved in snapshot.
Have a set of configuartion that are set in snapshot.
Have a set of configuartion that are set in zs3.
Identify configurations that may be beneficial to store in zs3/snapshot/global. Add a mechanism to flag these to indicate where they are stored and/or restored.
Describe alternatives you've considered
Resave all ZS3 & sanpshots when a setting has changed due to workflow change.
Additional context
An example of where you might want to store a configuration differently, depending on workflow is mentioned in #1279. The tools to decide whether options should be stored in / recalled from zs3/snapshot need to be simple, maybe listbox accessible via zs3/snapshot context menus and ideally also in webconf.
State is stored in snapshot in json matching the state schema. This could be expanded so that the snapshot is a branch of the full configuration including global configuration - or an overlay so that saved elements may be restored over existing ones and non-saved elements don't change value on recall.
The text was updated successfully, but these errors were encountered: