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: Community configuration: Define architecture of the system. 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. For simplicity, MediaWiki namespace is the preferred solution at this point.

Permissions

Currently, admins have full access to the underlying configuration files, as they're stored in the MediaWiki namespace. Longer-term, this is likely not desirable, but considering the likely-to-be implemented usecases (Automoderator, Web), it is an acceptable limitation. In the future, the namespace might have to be changed into a dedicated one, to support usecases when admins aren't supposed to be able to edit certain configuration.

Access layer

There should be a central class to process writing requests for a given provider, to be called from the API, CLI, the form submission logic in the dashboard as well as outside of CommunityConfiguration. It needs to support both replacing the whole configuration with new content and also per-variable changes.