[19.0][MIG] mass_mailing*/marketing_card/snailmail/survey_crm: 5 modules#9
Closed
dnplkndll wants to merge 20 commits into
Closed
[19.0][MIG] mass_mailing*/marketing_card/snailmail/survey_crm: 5 modules#9dnplkndll wants to merge 20 commits into
dnplkndll wants to merge 20 commits into
Conversation
`rename_fields()` (via `rename_field_references` in openupgradelib)
renames the field column and quoted occurrences in ir.filters.domain,
but it doesn't process:
* ir.rule.domain_force (not touched at all)
* unquoted dotted references like `user.groups_id.ids` in Python
expressions inside domain_force / ir.filters.domain / ir.act_server.code
Concretely, an ir.rule with
domain_force = "[('groups_id', 'in', user.groups_id.ids)]"
has its LHS migrated to `'group_ids'` but the RHS is left untouched,
which then crashes any view that triggers the rule with
AttributeError: 'res.users' object has no attribute 'groups_id'
Add a post-step in base/19.0.1.3 pre-migration that does a word-boundary
regex_replace of `user.groups_id` → `user.group_ids` in:
* ir_rule.domain_force
* ir_filters.domain
* ir_act_server.code
Reproduced migrating a real prod 18.0 database (Ledo Enterprises) to
19.0: the login page returned HTTP 500 with the AttributeError until
the ir.rule for `Website menu: group_ids` was patched manually.
Three workflows + a Dockerfile that turn the ledoent/OpenUpgrade fork
into a self-maintaining mirror with custom CI:
* mirror-upstream.yml — daily cron + workflow_dispatch. Force-pushes
OCA/OpenUpgrade `19.0` to `ledoent/OpenUpgrade:19.0`. Opens an issue
if `ledoent` (default branch) has drifted from upstream and needs
rebase.
* aggregate.yml — on push to `ledoent` or any `19.0-fix-*` branch,
runs `git-aggregator` against an inline config that merges
`ledoent` + every active fix branch and force-pushes the result to
`aggregated`.
* build-image.yml — on push to `aggregated`, builds Dockerfile.openupgrade
(FROM odoo:19.0 + lab pip deps + openupgradelib from git master + the
full aggregated checkout at /opt/openupgrade) and pushes to
registry.ledoweb.com/openupgrade:{latest,sha}.
Secrets required on this fork: ZOT_USERNAME, ZOT_PASSWORD (for Zot push),
AGGREGATE_PUSH_TOKEN (fine-scoped PAT with contents:write — falls back
to GITHUB_TOKEN if absent), and optionally GIT_PUSH_TOKEN for mirror.
…tion Mirrors the existing ledoent build patterns (openobserve, erp): pushes to europe-west3-docker.pkg.dev/kendall-ledo/docker/openupgrade with no stored secrets — auth via google-github-actions/auth WIF using the ci-github@kendall-ledo service account and the existing ledoent provider. Removes ZOT_USERNAME/ZOT_PASSWORD secrets dependency.
GAR was wrong — ledoent runs its own Zot at registry.hz.ledoweb.com (confirmed via kubectl ingress in the zot namespace). Robot user `robot-ci` already exists; CI auth needs ZOT_USERNAME + ZOT_PASSWORD secrets on this repo.
Auto-trigger image build after each aggregation: - aggregate.yml: after force-pushing `aggregated`, fires a repository_dispatch event_type=aggregated-updated using AGGREGATE_PUSH_TOKEN (skips if unset). - build-image.yml: adds a repository_dispatch trigger listening for the same event_type. GITHUB_TOKEN-driven branch pushes don't fire downstream workflows by design (loop protection), so a PAT is required for the dispatch. Manual workflow_dispatch on build-image still works as a fallback.
odoo:19.0 base ships without git; pip+git URL requires it.
GitHub Actions doesn't permit `secrets.*` in step-level `if:` conditions, so the previous workflow failed at parse time. Check the PAT inside the step itself via env, skip gracefully if missing.
Local dev on Apple Silicon needs arm64 manifests. Cluster is amd64. Add docker/setup-qemu-action for cross-build, set platforms list on build-push-action.
Zot intermittently 400s on the arm64 cross-build's many slow blob
uploads ("provided digest did not match uploaded content" after
~6 min of QEMU). Cluster is amd64 — Apple Silicon dev can pull via
Docker Desktop's Rosetta amd64 emulation.
Add the merges introduced by today's PR series so the auto-built image includes them and the lab can `OPENUPGRADE_PULL_POLICY=always` again: - 19.0-fix-hr-null-write-date (OCA#5628) - 19.0-fix-loyalty-stale-mail-template-fields (OCA#5629) - 19.0-fix-hr-obsolete-fields-cleanup (OCA#5630) - 19.0-fix-partner-autocomplete-cleanup (OCA#5631) - 19.0-fix-l10n-fr-cleanup (OCA#5632) The companion lab repos.yaml is updated separately so local `make sync-repos` matches.
…ual fixes The five 19.0-fix-* branches from today's PR series can't be merged individually by gitaggregate's `git pull --no-rebase` because 19.0-fix-hr-null-write-date and 19.0-fix-hr-obsolete-fields-cleanup both add new functions to the same file (hr/19.0.1.1/pre-migration.py) at overlapping locations. gitaggregate doesn't ask for conflict resolution and aborts. 19.0-fix-rollup is a hand-crafted branch (cherry-picked from each of the five fix branches onto origin/19.0 with a single manual resolution) that applies cleanly as a single merge. The five individual branches remain the source of truth for the OCA PRs; the rollup tracks their tip and must be rebuilt when any of the source PRs is updated.
…egated / ledoent Without these patterns the migration workflow only ran on the PR sync to OCA (using OCA's Actions context). Now pushing any work-branch on the fork triggers the migration test locally so we can validate before opening upstream PRs.
The workflow checks out a 'documentation' branch that exists only on
OCA/OpenUpgrade — forks 404 at the checkout step. Add a branch filter
("19.0") AND a github.repository_owner == 'OCA' job guard so fork
pushes don't fire the workflow uselessly. Fork CI now reports only
the migration test and pre-commit, matching intent.
… seed Parallel to test-migration.yml. Restores 18.0-ledoent.psql from the fork's databases release (built by scripts/build-fork-seed.sh in the lab repo: OCA's 18.0.psql + populate-factory volume + curated edge cases from scripts/seed-edge-cases.py). Gated to fork-only via 'if: github.repository_owner == ledoent' so OCA upstream doesn't try to download our seed. Catches edge-case migration regressions that vanilla demo data misses — VATEX_ legacy selection codes on account.tax, crm.stage with team_id set, archived parents, etc. Per-PR tests/data_*.py fixtures still needed for OCA-side validation; this workflow validates that fork-side the same migrations also handle real-shape data.
PG14 can't restore custom-format dumps written by PG16 (file header version 1.15 > max-supported 1.14). The lab uses postgres:16-alpine for the build, so the enriched seed dump is always PG16. Match here.
dnplkndll
force-pushed
the
19.0-mig-test-mass-mailing-marketing-trivial
branch
from
ef4b46d to
ddf3efd
Compare
github-actions
Bot
force-pushed
the
aggregated
branch
from
1f4675c to
b4f778e
Compare
dnplkndll
force-pushed
the
19.0-mig-test-mass-mailing-marketing-trivial
branch
from
ddf3efd to
d8fe72f
Compare
Author
|
Promoted to OCA as draft: OCA#5651 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Annotation-only analysis for mass_mailing, mass_mailing_crm, mass_mailing_event_sms_mobile, marketing_card, snailmail. All DEL fields left for database_cleanup.