Change Details

tl;dr: publishing REST modules to the REST Sandbox currently requires a config change/deploy. Make publishing the default for audience designations that allow it. Adjust overrides to maintain existing production behavior. ====Details==== Publishing a MW REST API module to the REST Sandbox currently requires adding an entry to the RestSandboxSpecs config variable. However, the most common case is that module authors want their module published. Change the system so that enabled modules are automatically published. Special-case modules that should not be published can prevent this via the RestModuleOverrides config variable. The set of published modules is determined in the ModuleManager::getApiSpecDefs() function. Right now, this function combines the hard-coded set of specs in ModuleManager::CORE_SPECS with the specs listed in RestSandboxSpecs. Change ModuleManager::getApiSpecDefs() to include all enabled modules, unless their audience designation or RestModuleOverrides indicates they should not be published. ====Notes==== The site.v1 module should not be published in the REST Sandbox. Before merging the core change that will be created as part of this task, create and deploy a change to RestModuleOverrides marking it as "discoverable".

tl;dr: publishing REST modules to the REST Sandbox currently requires a config change/deploy. Make publishing the default for audience designations that allow it. Adjust overrides to maintain existing production behavior. ====Details==== Publishing a MW REST API module to the REST Sandbox currently requires adding an entry to the RestSandboxSpecs config variable. However, the most common case is that module authors want their module published. Change the system so that enabled modules are automatically published. Special-case modules that should not be published can prevent this via the RestModuleOverrides config variable. The set of published modules is determined in the ModuleManager::getApiSpecDefs() function. Right now, this function combines the hard-coded set of specs in ModuleManager::CORE_SPECS with the specs listed in RestSandboxSpecs. Change ModuleManager::getApiSpecDefs() to include all enabled modules, unless their audience designation or RestModuleOverrides indicates they should not be published. The mapping of functionality sets to audience designations can also be changed: * public => published * beta => opt-in (This is possible at this time because the config change mentioned below will prevent any undesired publishing.) ====Notes==== We have to special cases: * the site.v1 module should not be published in the REST Sandbox * the attribution.v0-beta module should only be published to the REST Sandbox on testwiki Before merging the core change that will be created as part of this task, create and deploy a change to RestModuleOverrides marking both of these as "discoverable".

tl;dr: publishing REST modules to the REST Sandbox currently requires a config change/deploy. Make publishing the default for audience designations that allow it. Adjust overrides to maintain existing production behavior. ====Details==== Publishing a MW REST API module to the REST Sandbox currently requires adding an entry to the RestSandboxSpecs config variable. However, the most common case is that module authors want their module published. Change the system so that enabled modules are automatically published. Special-case modules that should not be published can prevent this via the RestModuleOverrides config variable. The set of published modules is determined in the ModuleManager::getApiSpecDefs() function. Right now, this function combines the hard-coded set of specs in ModuleManager::CORE_SPECS with the specs listed in RestSandboxSpecs. Change ModuleManager::getApiSpecDefs() to include all enabled modules, unless their audience designation or RestModuleOverrides indicates they should not be published. The mapping of functionality sets to audience designations can also be changed: * public => published * beta => opt-in (This is possible at this time because the config change mentioned below will prevent any undesired publishing.) ====Notes==== TheWe have to special cases: * the site.v1 module should not be published in the REST Sandbox. * the attribution.v0-beta module should only be published to the REST Sandbox on testwiki Before merging the core change that will be created as part of this task, create and deploy a change to RestModuleOverrides marking itboth of these as "discoverable".