New settings file format, and duplicate values in settings #12
-
After a little while of trying out this plugin, I've ended up with these settings: {
"globalFilter": "",
"removeGlobalFilter": false,
"setDoneDate": true,
"status_types": [
[
"",
"",
""
]
],
"statusTypes": [],
"features": {
"TASK_STATUS_MENU": true,
"APPEND_GLOBAL_FILTER": false,
"ENABLE_SQL_QUERY": false
},
"generalSettings": {
"globalFilter": "",
"removeGlobalFilter": false,
"setDoneDate": true,
"appendGlobalFilter": false
},
"headingOpened": {
"Tasks, SQL Powered": true,
"Task Settings": true,
"Documentation and Support": true,
"Tasks Status Types": true,
"Optional or in development features": true
}
} Note the duplicate values: "globalFilter": "",
"removeGlobalFilter": false,
"setDoneDate": true,
"status_types": [ and: "generalSettings": {
"globalFilter": "",
"removeGlobalFilter": false,
"setDoneDate": true,
...
}, Was that intentional? Thinking about when the new settings are (I hope) released in Tasks, is there some kind of migration path to read the old-style settings and move them to the new |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
yes it is intentional, the general settings are synced with the old ones off the root. The new model is in place to allow flexibility of configuration based on the Json document powering the configuration. When the configuration is updated both are toggled in sync so any older code using the original settings picks it up. This way I can avoid touching the Tasks V1 model which makes keeping it in sync simpler. |
Beta Was this translation helpful? Give feedback.
yes it is intentional, the general settings are synced with the old ones off the root. The new model is in place to allow flexibility of configuration based on the Json document powering the configuration.
When the configuration is updated both are toggled in sync so any older code using the original settings picks it up. This way I can avoid touching the Tasks V1 model which makes keeping it in sync simpler.