Change Details

Ultraviolet v0.1.0 overwrites the old RedWarn configuration file (`redwarnConfig.js`) using a new schema, which dropped old configuration values in the process. This means we essentially now have `redwarnConfig.js` files that have either a RedWarn configuration or an Ultraviolet configuration (which likely lacks the settings the user had on RedWarn). v0.1.4 moves settings to MediaWiki preferences, so this means all those settings are surely compatible with Ultraviolet. So that there won't be any configuration loss for users when switching from RedWarn 16.1 to Ultraviolet 1.0.0, the current configuration schema has to be updated to accommodate old values from RedWarn. Attempting to do this without modifying configuration version 1 will cause data loss, so this requires **retroactive editing of the configuration schema at version 1**. Options to re-import this data into Ultraviolet for users who already had their configurations wiped (UV v0.1.0 to current) should also be provided. Implementation details: - [ ] Update Ultraviolet configuration version 1 to accommodate old RedWarn configuration fields - All RedWarn configuration fields *must* be accommodated in configuration version 1. - Any old RedWarn configuration values incompatible with Ultraviolet should only be changed with an upgrade to configuration version 2. This ensures version 0.1.0 to 0.1.4 won't read incompatible configuration versions. - [ ] Add a check for detecting old RedWarn configurations in the page history of a user's `redwarnConfig.js` - [ ] Run this check on the preferences page - [ ] If an old RedWarn configuration was detected, show a pop-up on the preferences page with a button to re-import the old schema - [ ] (optional) Add button for requesting deletion of the old `redwarnConfig.js` file. - This may annoy local wiki interface administrators. Consider consulting prior to adding in this feature. - As much as possible, this should be done along with CSD features.

Ultraviolet v0.1.0 overwrites the old RedWarn configuration file (`redwarnConfig.js`) using a new schema, which dropped old configuration values in the process. This means we essentially now have `redwarnConfig.js` files that have either a RedWarn configuration or an Ultraviolet configuration (which likely lacks the settings the user had on RedWarn). v0.1.4 moves settings to MediaWiki preferences, so this means all those settings are surely compatible with Ultraviolet. So that there won't be any configuration loss for users when switching from RedWarn 16.1 to Ultraviolet 1.0.0, the current configuration schema has to be updated to accommodate old values from RedWarn. Attempting to do this without modifying configuration version 1 will cause data loss, so this requires **retroactive editing of the configuration schema at version 1**. Options to re-import this data into Ultraviolet for users who already had their configurations wiped (UV v0.1.0 to current) should also be provided. Implementation details: - [ ] Update Ultraviolet configuration version 1 to accommodate old RedWarn configuration fields - All RedWarn configuration fields _must_ be accommodated in configuration version 1. - Any old RedWarn configuration values incompatible with Ultraviolet should only be changed with an upgrade to configuration version 2. This ensures version 0.1.0 to 0.1.4 won't read incompatible configuration versions. - [ ] Add a check for detecting old RedWarn configurations in the page history of a user's `redwarnConfig.js` - Obviously, a missing `redwarnConfig.js` file should mean an immediate `false`. - This check should be removed by Ultraviolet 1.0.0. - [ ] Run this check on the preferences page - [ ] If an old RedWarn configuration was detected, show a pop-up on the preferences page with a button to re-import the old schema - [ ] (optional) Add button for requesting deletion of the old `redwarnConfig.js` file. - This may annoy local wiki interface administrators. Consider consulting prior to adding in this feature. - As much as possible, this should be done along with CSD features.

Ultraviolet v0.1.0 overwrites the old RedWarn configuration file (`redwarnConfig.js`) using a new schema, which dropped old configuration values in the process. This means we essentially now have `redwarnConfig.js` files that have either a RedWarn configuration or an Ultraviolet configuration (which likely lacks the settings the user had on RedWarn). v0.1.4 moves settings to MediaWiki preferences, so this means all those settings are surely compatible with Ultraviolet. So that there won't be any configuration loss for users when switching from RedWarn 16.1 to Ultraviolet 1.0.0, the current configuration schema has to be updated to accommodate old values from RedWarn. Attempting to do this without modifying configuration version 1 will cause data loss, so this requires **retroactive editing of the configuration schema at version 1**. Options to re-import this data into Ultraviolet for users who already had their configurations wiped (UV v0.1.0 to current) should also be provided. Implementation details: - [ ] Update Ultraviolet configuration version 1 to accommodate old RedWarn configuration fields - All RedWarn configuration fields *_must*_ be accommodated in configuration version 1. - Any old RedWarn configuration values incompatible with Ultraviolet should only be changed with an upgrade to configuration version 2. This ensures version 0.1.0 to 0.1.4 won't read incompatible configuration versions. - [ ] Add a check for detecting old RedWarn configurations in the page history of a user's `redwarnConfig.js` - Obviously, a missing `redwarnConfig.js` file should mean an immediate `false`. - This check should be removed by Ultraviolet 1.0.0. - [ ] Run this check on the preferences page - [ ] If an old RedWarn configuration was detected, show a pop-up on the preferences page with a button to re-import the old schema - [ ] (optional) Add button for requesting deletion of the old `redwarnConfig.js` file. - This may annoy local wiki interface administrators. Consider consulting prior to adding in this feature. - As much as possible, this should be done along with CSD features.