Skip to content

Resolve native lifecycle meaning of the actual calendar and device-log schema warnings #321

Closed

Description

@shiny-code-app

Objective

Determine whether two nonfatal core-schema warnings in the actual OPW19→20 run settle through native20's ordinary lifecycle or require a narrow source correction. Read-only source investigation under #277 / cbusillo/odoo-tenant-opw#314, Track https://github.com/cbusillo/direction/issues/4 . These warnings are not the fatal Discuss error and must not become invented per-PR proof gates.

Actual evidence

The independently qualified Calendar batch used source a35858e/devkit7c42c527 and artifact artifact-opw-d207d853fea08335. Core setup logs failure to add resource_calendar_attendance_check_duration_hours and to make res_device_log.user_agent NOT NULL; migration continues past those logs and later fails on Discuss uniqueness.

Original retained19 metadata:15attendance rows, five zero/nonpositive/NULL/out-of-range duration rows, all five are day_period=lunch with positive hour ranges and no display_type. Target20 no longer accepts lunch as a working attendance period; do not turn those five lunch intervals into extra work by blindly filling hour differences. There are954legacy device logs and the source table has no user_agent column; it has older structured attributes instead. A fabricated user-agent string or silent loss of audit data is not a correction.

Finish Line

Read exact artifact-bound20 resource/device declarations, module XML/cleanup/recompute/constraint scheduling and relevant19/OCA/OpenUpgrade source. Before suggesting a migration script, check current OpenUpgrade20 coverage and pending work and reuse native behavior where it fits. Return one source-backed disposition for EACH warning: whether normal later module processing already removes/recomputes/validates it; the exact readback root should fold into the next existing actual batch; or a concrete smallest missing source treatment and its semantics/owner. Distinguish code inference from executed proof. Do not demand a new19run or extra heavy job. Do not invent an archive/telemetry framework or new business policy.

This bounded investigation completes on that actionable disposition, not on a full migration pass. No maintained source edit or PR is requested; a reproduced required source correction can be returned to the lead for its existing shared delivery. No new Director wait is assumed before investigation.

Technical scope

Allowed root inputs under /Volumes/Developer-Artifacts/task-evidence/odoo-tenant-opw/opw323-calendar-batch-1030/ are core-transition-source-shape.json, core-transition-schema.sql, core-source-binding.json and core-source/. They contain aggregate counts/defaults/DDL and exact public core source, not business values/people/record IDs. Do not open private raw dumps/logs or the private identity index. Source only: no Odoo19execution, runtime/data/guest/route/helper/marker/credential/grant change, transfer, restore, provider action or heavy submission. Root retains canonical OPW323, all data/original/native/preview/production custody. Source workers on the fatal Discuss correction are independent. Report Removed: and Net lines:.

Current Status

Source-only investigation complete. Disposition: #321 (comment) . Native constraint retry is not a data repair. Lunch breaks must remain nonworking; old parsed device attributes cannot reconstruct a raw User-Agent. Current/pending OpenUpgrade coverage was checked. No source, data, runtime, gate, or PR changed.

Next actor: agent:ODOO20LEAD2-1027
Next action: consume this disposition in the existing shared 19-to-20 delivery under #277 and cbusillo/odoo-tenant-opw#314 / cbusillo/odoo-tenant-opw#323; qualify the narrow lunch treatment and historical device compatibility, then fold the specified readback into the next already planned actual batch. This investigation adds no job or product gate and does not select a new telemetry or retention policy.
Last verified: October 31, 2026, source inspection only. Later module loading was not executed here.

Activity

  1. shiny-code-app commented on Oct 31, 2026

    @shiny-code-app
    ContributorAuthor

    Claimed by DK321-1031

    Session: 01a19048-5f3d-7432-b2b4-9846d984717a
    Branch: work/dk321-1031
    Claimed at: 2026-10-31T00:48:02-04:00
    Next action: Trace artifact-bound native20 lifecycle for lunch duration and legacy device user_agent warnings; return source-only disposition.

    Admission: milestone; https://github.com/cbusillo/direction/issues/4, #277 (comment)

    Work record

  2. shiny-code-app commented on Oct 31, 2026

    @shiny-code-app
    ContributorAuthor

    DK321-1031 source-only disposition. Neither warning is evidence that ordinary later native loading repairs the legacy data. Both need explicit treatment in the existing shared 19→20 delivery; no new run or gate is requested.

    Source binding: the allowed core-source-binding.json identifies artifact artifact-opw-d207d853fea08335, tenant source a35858e4320f71f0ea51e88d4e60669167132dc4, and devkit 7c42c527f28fb791c1aa2b909bb0dd89cc4df102. The retained resource attendance and device model bytes match clean public Odoo snapshot d60b687b047701f0bac45f47f4dee875dea5ba3e by SHA-256. The accompanying calendar model matches too. Loader/ORM references below are that public snapshot; the supplied artifact binding hashes the model files, not the loader. Odoo 19 977f36dc9a6f473b9cb32fa6f9e3db396fb4de13 is a semantics comparison, not additional proof of original18 lineage. Overall direction was read; this repository has no DIRECTION.md (local absence and GitHub contents 404), as AGENTS.md states.

    Five lunch attendances: native cleanup does not implement the required semantic transition.

    In 19's attendance model, lunch deliberately has zero working duration. _is_work_period() explicitly excludes lunch and section lines. Thus the supplied five lunch rows with positive clock ranges and no display_type are not evidence of missing working hours.

    20's attendance model removes lunch from day_period and requires duration_hours > 0 AND duration_hours <= 24. Its compute methods derive duration from the positive clock range and classify the interval as morning/afternoon/full_day; _is_work_period now returns True in core. Recomputing/filling those five durations would turn breaks into working intervals. It could remove a constraint symptom while corrupting schedule meaning.

    Native calendar cleanup removes rows by calendar type/date and normalizes recurrence; it has no lunch predicate. The resource data XML updates the standard calendar/company linkage under noupdate and creates missing company calendars; it does not migrate all legacy break rows. Removed selection metadata is not a blanket record deletion: selection cleanup does nothing without an applicable ondelete policy, and core day_period has none for lunch. Field initialization does not schedule a whole-table recompute merely because an existing stored field's compute code changed.

    Smallest missing source treatment: in the existing shared pre-upgrade bridge, recognize the old nonworking lunch rows before native recomputation can erase their identity, and omit those break-only rows from the new working-attendance representation. Preserve the actual morning/afternoon work intervals so the lunch gap stays a gap. This is a semantic migration, not a blanket duration_hours = hour_to - hour_from repair or deletion of all invalid-duration records. The supplied aggregate does not establish attendance references/custom extensions; root must use its existing source/data custody to qualify those before implementing a narrow removal. No data was removed here.

    954 device logs: native loading cannot recover a raw User-Agent that was never stored.

    20's log declaration requires user_agent but provides no default, compute or init_storage. New request logging INSERTs the request's raw user_agent; it does not backfill old rows. Autovacuum deduplicates/prunes/revokes by its own conditions, not by migration completeness. SQL equality on NULL user_agent does not make the soft-GC join match these rows. Configured hard retention is conditional data deletion, not preservation or reconstruction.

    The supplied source DDL has platform/browser/device_type and no user_agent. 19's source stores parsed attributes, whereas 20's reader parses the raw string again. A browser label is not an invertible raw User-Agent. Leaving NULL without reader treatment also fails: the parser uses regex.search on its argument, so simply dropping required=True is not a complete compatibility treatment.

    Concrete missing treatment: the shared transition must preserve the 954 historical rows and their old parsed attributes, explicitly support their unavailable raw User-Agent in the native20 schema/read path, and continue using actual request telemetry for new logs. There is no lossless SQL backfill from the supplied columns that also satisfies unchanged native20 NOT NULL. This investigation does not select a new history-retention/telemetry policy, weaken the constraint, fabricate a string, or build an archive framework. Root/ODOO20LEAD2 owns the compatibility source treatment in its existing shared delivery; an exact representation choice, if needed, remains the Director's design decision rather than an investigator's implied permission.

    OpenUpgrade checked before recommending source work.

    At the read, 20.0 has no scripts/base or scripts/resource migration directories. Migration tracker OCA/OpenUpgrade#6044 lists base as pending PR OCA/OpenUpgrade#6068; no resource migration PR was found by the 20.0 resource search. The pending PR at 2d9eb6bab7e7e579953e38d7ad3b96aad6fcc44d includes resource analysis/XML but no executable resource migration. Its base pre-migration renames browser to user_agent and substitutes 'unknown' for NULL, along with other required-field defaults. That is pending source, not native lifecycle, and it does not meet this brief's truthful-telemetry requirement. Do not adopt it as an exact raw-agent reconstruction. The tenant's pinned OpenUpgrade 89e649728027a8ab656b3aa4be18f4bd364db417 supplies 19-series base/resource scripts, not a 20 treatment.

    Scheduling and the readback for root's next existing actual batch.

    Constraint application and registry scheduling savepoint failed DDL and queue a retry. Loading runs end migrations, then finalize_constraints, then orphan-data cleanup/autovacuum scheduling. A retry may succeed if an explicit intervening treatment changed rows; it does not supply that treatment. Final retry failures remain warnings. The final not-null check reports missing constraints; it does not fill data or make them pass.

    Fold into the already planned actual batch, after full module loading/end scripts (not at the earlier Discuss failure):

    • Attendance: aggregate legacy-lunch/unsupported-period counts, invalid durations including NULL explicitly, validated presence/definition of resource_calendar_attendance_check_duration_hours, and unchanged working intervals/hours with the original lunch gap excluded. A passed duration constraint alone cannot prove the semantics.
    • Devices: preserved legacy-row count and parsed attributes, historical missing-user-agent count under the chosen compatibility treatment, actual user_agent column nullability/constraint state, and whether that representation can be read without claiming invented telemetry. Compare the preserved historical cohort rather than all rows if new logs were created.

    These are the precise observations needed to reconcile the two warnings inside root's existing run, not a new per-PR proof gate, 19 rerun, standalone heavy job, or claim that migration/staff readiness already passed. The actual batch stopped earlier on Discuss; no later native lifecycle was executed or proved by this investigation. The source-only investigation is complete; delivery remains with root on #277 and cbusillo/odoo-tenant-opw#314 / existing cbusillo/odoo-tenant-opw#323.

    Removed: nothing; no maintained source, runtime, data, or gate changed.
    Net lines: 0 maintained lines. No PR.

  3. shiny-code-app commented on Oct 31, 2026

    @shiny-code-app
    ContributorAuthor

    Source-only investigation completed with the actionable disposition at #321 (comment) . Current Status names root for the existing shared delivery; this closes the investigation only, not migration or staff readiness. Removed: nothing. Net lines: 0. No PR.

  4. shiny-code-app commented on Oct 31, 2026

    @shiny-code-app
    ContributorAuthor

    Released claim 6539196586

    DK321-1031 complete: source-only disposition posted at #321 (comment) and Current Status updated. Both warnings require explicit semantic treatment; native retry supplies no missing data repair. No code, PR, worktree, runtime, data operation or heavy job was created.

    Next actor: agent:ODOO20LEAD2-1027
    Next action: consume the source findings in the existing shared delivery on #277 and cbusillo/odoo-tenant-opw#314; qualify lunch omission preserving the nonworking gap and historical-device compatibility preserving unavailable telemetry and parsed history. Use the already planned actual batch for the specified readback. No additional product gate or job.

    Retained local evidence: /Volumes/Developer-Artifacts/task-evidence/odoo-devkit/dk321-1031 . No retained delivery branch, worktree or PR belongs to this claim.
    Removed: nothing.
    Net lines: 0 maintained lines.

  5. shiny-code-app commented on Oct 31, 2026

    @shiny-code-app
    ContributorAuthor

    Both warnings now have explicit source treatment rather than being dismissed as harmless. The lunch-gap correction is integrated with Discuss on devkit323: preserve work intervals/totals and remove only qualified redundant nonworking break rows before recomputation. The historical-device compatibility is shared-addons100: preserve the original parsed fields and NULL telemetry, claim field ownership and mark only the original cohort in the SAME native20 update/init, retaining native access/session selection and new-request requirements. All 223 native addon CI tests pass, including the eight new regressions.

    Both engineering source deliveries are enqueued through the train. Source delivery is not final warning disposition on actual data. Root's next changed-input OPW batch must compare work gaps and totals, original device IDs/parsed values/NULL raw agents/cohort flag, field ownership/final constraint, and native owner/session reads. Keep migration, full filestore/final E2E and staff-readiness claims separate. OPW314 remains root-owned. No actual data, runtime, production18, access or Client action occurred in this source integration. Removed: no warning or historical data. Net lines: +185 for the lunch follow-up and +368 for the device addon, within the existing shared deliveries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions