Change Details

This task serves to define how should the Configuration store component of //Community configuration 2.0// project work like. For a high-level technical overview of //Community configuration 2.0// (including description of other components), please see {T341884}. This task assumes high-level familiarity with other components the feature is consisted of. ==== Description Community configuration stores the configuration in on-wiki JSON pages (one page per featureset). Each configuration is validated via the schema provider (T342575). The Configuration store needs to handle all read/write requests and ensure that: * configuration is written by authorized users only, * configuration passes the T342575 validation before being written/returned, * configuration users can see the configuration in a reasonably stable way, even if the underlying storage changes. ===== Storage Configuration storage is responsible for determining which on-wiki JSON page has given configuration. There are several options to where config can be stored. Currently, it is stored in the `MediaWiki` namespace. This selection was made, because it is restricted to admin editing by default (guarded through `editinterface` permission) and the #growth-team wanted admins to have full access to configuration. With Community configuration 2.0 being a wide configuration tool, we might not want admins to have unconditional full access to configuration (see `Permissions` section below for details). This would be difficult to implement with configuration in the `MediaWiki` namespace, but we could do that if Community configuration stored its data in a dedicated namespace, such as `Config`.However, the Config namespace (which would be the most obvious name to use) is already used by #jsonconfig. ===== Permissions Currently, admins have full access to the underlying configuration files, as they're stored in the MediaWiki namespace. This is probably not a good setup for community configuration expansion. For example, #editing-team mentioned Edit check configuration (T327959, T327563) should be opened to the same group of users as Abuse filter configuration, which sometimes doesn't include admins (for example, on enwiki, only Abuse filter maintainers have this capability). Other similar usecases which would benefit from limited configuration editing permissions can be expected. This means at least page-level configuration permissions are needed. TODO We will probably also have other usecases which would benefit from the ability to grant configuration editing permissions to different group of users depending on the featureset (in other words, at least on the page level). ===== Validation TODO ===== Access layer TODO ==== Open questions [ ] Decide which namespace should have the configuration

This task serves to define how should the Configuration store component of //Community configuration 2.0// project work like. For a high-level technical overview of //Community configuration 2.0// (including description of other components), please see {T341884}. This task assumes high-level familiarity with other components the feature is consisted of. ==== Description Community configuration stores the configuration in on-wiki JSON pages (one page per featureset). Each configuration is validated via the schema provider (T342575). The Configuration store needs to handle all read/write requests and ensure that: * configuration is written by authorized users only, * configuration passes the T342575 validation before being written/returned, * configuration users can see the configuration in a reasonably stable way, even if the underlying storage changes. ===== Storage Configuration storage is responsible for determining where the configuration is stored (which on-wiki JSON page, for example) and for providing an interface for accessing and manipulating the configuration data. There are several options to where config can be stored. Currently, it is stored in the `MediaWiki` namespace. This selection was made, because it is restricted to admin editing by default (guarded through `editinterface` permission) and the #growth-team wanted admins to have full access to configuration. With Community configuration 2.0 being a wide configuration tool, we might not want admins to have unconditional full access to configuration (see `Permissions` section below for details). This would be difficult to implement with configuration in the `MediaWiki` namespace, but we could do that if Community configuration stored its data in a dedicated namespace, such as `Config`.However, the Config namespace (which would be the most obvious name to use) is already used by #jsonconfig. ===== Permissions Currently, admins have full access to the underlying configuration files, as they're stored in the MediaWiki namespace. This is probably not a good setup for community configuration expansion. For example, #editing-team mentioned Edit check configuration (T327959, T327563) should be opened to the same group of users as Abuse filter configuration, which sometimes doesn't include admins (for example, on enwiki, only Abuse filter maintainers have this capability). Other similar usecases which would benefit from limited configuration editing permissions can be expected. This means at least page-level configuration permissions are needed. TODO We will probably also have other usecases which would benefit from the ability to grant configuration editing permissions to different group of users depending on the featureset (in other words, at least on the page level). ===== Validation TODO ===== Access layer TODO ==== Open questions [ ] Decide which namespace should have the configuration

This task serves to define how should the Configuration store component of //Community configuration 2.0// project work like. For a high-level technical overview of //Community configuration 2.0// (including description of other components), please see {T341884}. This task assumes high-level familiarity with other components the feature is consisted of. ==== Description Community configuration stores the configuration in on-wiki JSON pages (one page per featureset). Each configuration is validated via the schema provider (T342575). The Configuration store needs to handle all read/write requests and ensure that: * configuration is written by authorized users only, * configuration passes the T342575 validation before being written/returned, * configuration users can see the configuration in a reasonably stable way, even if the underlying storage changes. ===== Storage Configuration storage is responsible for determining which on-wiki JSON page has given configuration.where the configuration is stored (which on-wiki JSON page, for example) and for providing an interface for accessing and manipulating the configuration data. There are several options to where config can be stored. Currently, it is stored in the `MediaWiki` namespace. This selection was made, because it is restricted to admin editing by default (guarded through `editinterface` permission) and the #growth-team wanted admins to have full access to configuration. With Community configuration 2.0 being a wide configuration tool, we might not want admins to have unconditional full access to configuration (see `Permissions` section below for details). This would be difficult to implement with configuration in the `MediaWiki` namespace, but we could do that if Community configuration stored its data in a dedicated namespace, such as `Config`.However, the Config namespace (which would be the most obvious name to use) is already used by #jsonconfig. ===== Permissions Currently, admins have full access to the underlying configuration files, as they're stored in the MediaWiki namespace. This is probably not a good setup for community configuration expansion. For example, #editing-team mentioned Edit check configuration (T327959, T327563) should be opened to the same group of users as Abuse filter configuration, which sometimes doesn't include admins (for example, on enwiki, only Abuse filter maintainers have this capability). Other similar usecases which would benefit from limited configuration editing permissions can be expected. This means at least page-level configuration permissions are needed. TODO We will probably also have other usecases which would benefit from the ability to grant configuration editing permissions to different group of users depending on the featureset (in other words, at least on the page level). ===== Validation TODO ===== Access layer TODO ==== Open questions [ ] Decide which namespace should have the configuration