Repository navigation
chore: back-merge main into develop after v2.3(Verawood.1) - #668
IvanStepanok wants to merge 17 commits into
Conversation
Develop to main v1.4
Develop to main v1.5
Develop to main v1.5.1
Develop to main. Release v2
Develop to main v2.1
Release v2.2 (Ulmo.1)
fix: typo in translation.py inline comments
Release v2.3 (Verawood.1)
openedx-webhooks
added
open-source-contribution
|
Thanks for the pull request, @IvanStepanok! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #668 +/- ##
==============================
==============================
☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Adds the Sendable Tenant value type and TenantsConfig container that later multi-tenant layers build on: per-tenant API/SSO/OAuth config, UI feature flags (UIComponentsConfig, now @unchecked Sendable), and raw branding fields for a later theming layer to render. Tenant(dictionary:) parses config.yaml's new TENANTS block. Not included here: remote catalog fetching, tenant selection/session state, and anything reading TenantProvider — those land as separate PRs. TENANTS data in config.yaml is illustrative, not real tenants.
Renames the Tenant domain model and its wire schema to Instance, per community naming feedback. Tenant -> Instance, TenantsConfig -> InstancesConfig, TenantProvider -> InstanceProvider, TenantThemeColors -> InstanceThemeColors; config.yaml's TENANTS block -> INSTANCES, TENANT_NAME -> INSTANCE_NAME, IS_SWITCH_TENANT_LOGIN_ENABLED -> IS_SWITCH_INSTANCE_LOGIN_ENABLED. Pure rename, no behavior change. KEY is left as-is (already generic). SSO_URL_SUCCESSFUL_LOGIN/successfulSSOLoginURL is untouched here too -- its rename to SSO_FINISHED_URL is separate, upcoming work.
Adds ThemeColorSet/ThemeDefinition/ThemeFontSet and ThemeManager: derives a tenant's palette from its accent hex plus any per-field THEME overrides, and resolves its logo/header banner from a remote URL (cached in-memory, falling back to the bundled default) or a bundled asset name. Looked up by the tenant's stable key, not a localized display-name string. Takes primitives, not Core's Tenant struct -- Theme has no build dependency on Core. Not called from anywhere yet -- RouteController wires up applyTheme(...) in a later PR. With one generic placeholder asset for customer logo, matching config.yaml's example-tenant entry.
Renames the theme engine's tenant-facing surface to instance (ThemeColorSet/ThemeDefinition/ThemeManager doc comments and params, TenantLogoImage/TenantHeaderBackgroundImage -> InstanceLogoImage/ InstanceHeaderBackgroundImage, exampleTenantAppLogo asset -> exampleInstanceAppLogo), per the community's naming feedback.
feat: add per-instance theme engine
Brings
developback in line withmainafter the Verawood release.developis strictly behind — 9 commits, nothing ahead — so this is a clean catch-up with no conflicts.What it carries over
swiftlint.yml,unit_tests.ymlandvalidate-translations.ymlto full commit SHAs. It landed onmainonly, sodevelopstill refers to those actions by tag.v2.3(Verawood.1)release merge commit itself.Why it matters now
mainanddevelophad been drifting since 2026-05-28. #660 touched the same two workflow files that #666 rewrote during the release, and that was resolved once, in the release merge — cleanly, because the two changed different lines. Leavingdevelopbehind means the next release merge would have to resolve the same overlap again, against adevelopthat has moved on further.Verified on
mainafter the release merge: both changes survived — the actions are SHA-pinned andruby/setup-rubywithruby-version: 3.3andxcodes select 26.2are present.