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. The mapping of functionality sets to audience designations can also be changed: * public => published * beta => published This is possible at this time because the config change mentioned below will prevent any undesired publishing. Also, beta will eventually become "opt-in", but we won't yet have the ability to visually distinguish modules in the REST Sandbox. For now, "published" will maintain existing production behavior. ====Notes==== We have at least one special case, and maybe two: * the site.v1 module should not be published in the REST Sandbox. This is not expected to change. * the attribution.v0-beta module should only be published to the REST Sandbox on testwiki. This may change if {T422771} is implemented first. In that case, attribution.v0-beta is no longer a special case and can be published everywhere. 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". ====Checklist==== [] create/deploy config change to prevent the special case(s) from being published in undesired places [] change ModuleManager::getApiSpecDefs() behavior per the task description [] change the designation/functionality set mapping per the task description

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 audience designations to modes (aka functionality sets) can also be changed: * published => published * beta => published, group "beta" * internal => published, group "internal" ====Notes==== We have one special case. 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 site.v1 as "discoverable". ====Checklist==== [x] create/deploy config change to prevent the special case(s) from being published in undesired places [] change ModuleManager::getApiSpecDefs() behavior per the task description [] change the designation/functionality set mapping per the task description

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 designationsaudience designations to modes (aka functionality sets) can also be changed: * publicshed => published * beta => published, group "beta" This is possible at this time because the config change mentioned below will prevent any undesired publishing. Also, beta will eventually become "opt-in", but we won't yet have the ability to visually distinguish modules in the REST Sandbox. For now* internal => published, "published" will maintain existing production behavior.group "internal" ====Notes==== We have at least one special case,. and maybe two: * tThe site.v1 module should not be published in the REST Sandbox. This is not expected to change. * the attribution.v0-beta module should only be published to the REST Sandbox on testwiki. This may change if {T422771} is implemented first. InBefore merging the core change that casewill be created as part of this task, attribution.v0-beta is no longer a special case and can be published everywhere. Before merging the core change that will be created as part of this task, create and deploy a change to RestModuleOverrides marking both of thesesite.v1 as "discoverable". ====Checklist==== [x] create/deploy config change to prevent the special case(s) from being published in undesired places [] change ModuleManager::getApiSpecDefs() behavior per the task description [] change the designation/functionality set mapping per the task description