feat(erp-seed): AD_Form + ad_val_rule manifest entries (ship blocked — see body) - #91
Merged
Merged
Conversation
…fest Extends scripts/ad_seed_manifest.json (383 tables now) so export_ad_seed.js can carry the 2 structural categories missing from the shipped erp/ad_seed.db: AD_Form (0 rows shipped vs 53 in the real PG) and ad_val_rule (table absent entirely vs 332 rows real). Entries follow the established convention: AD_Form as "canonical" case + activeOnly (matches AD_Window/AD_Reference, the other UI-list tables); ad_val_rule as "lower" case, all rows (matches ad_process, the other engine-consumed table). Verified against the live docker PG (postgres/idempiere): a scratch run of export_ad_seed.js landed AD_Form=49 rows (53 real, 4 inactive - exact match to a direct PG query) and ad_val_rule=332 rows (exact match), both with correct DDL/PK inferred from the PG catalog, zero errors. NOT shipped further than this: re-running the full export against the CURRENT live PG container produces a severely regressed seed relative to what's actually deployed (ad_client 6->1, ad_role 14->4, C_BPartner 113->18, ad_window_access 4448->1080, and fact_acct/HR_*/C_Subscription* missing entirely - none of those tables are even in this manifest). Neither `idempiere` nor `idempiere_test` on the live container currently holds the richer data state that built the shipped erp/ad_seed.db (2026-07-05) - the container has drifted or been reset since. Shipping a fresh export now would regress production. Root-caused and left for a real fix (locate or rebuild the pipeline stage that adds fact_acct/HR/Subscription/client-13 shard data before re-exporting), not guessed at here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GmNVMG9ZGcKygz4zXuCe6m
…eed manifest" This reverts commit cf3e288.
…fest Extends scripts/ad_seed_manifest.json (383 tables now, minimal diff — the prior commit on this branch reformatted the whole file via json.dump and is reverted) so export_ad_seed.js can carry the 2 structural categories missing from the shipped erp/ad_seed.db: AD_Form (0 rows shipped vs 53 in the real PG) and ad_val_rule (table absent entirely vs 332 rows real). Entries follow the established convention: AD_Form as "canonical" case + activeOnly (matches AD_Window/AD_Reference, the other UI-list tables); ad_val_rule as "lower" case, all rows (matches ad_process, the other engine-consumed table). Verified against the live docker PG (postgres/idempiere): export_ad_seed.js lands AD_Form=49 rows (53 real, 4 inactive - exact match to a direct PG query) and ad_val_rule=332 rows (exact match), correct DDL/PK inferred from the PG catalog, zero errors, re-run twice with identical results. NOT shipped further than this: re-running the full export against the CURRENT live PG container produces a severely regressed seed relative to what's actually deployed (ad_client 6->1, ad_role 14->4, C_BPartner 113->18, ad_window_access 4448->1080, and fact_acct/HR_*/C_Subscription* missing entirely - none of those tables are even in this manifest, and neither `idempiere` nor `idempiere_test` on the live container currently holds anywhere near the richer data state that built the shipped erp/ad_seed.db, 2026-07-05). The container has drifted or been reset since. Shipping a fresh export now would regress production. Root-caused, not shipped, left for a real fix: locate or rebuild whatever pipeline stage originally added fact_acct/HR/Subscription/client-13 shard data before ever re-exporting against this container again. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GmNVMG9ZGcKygz4zXuCe6m
… the seed-pipeline showstopper found Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GmNVMG9ZGcKygz4zXuCe6m
# Conflicts: # docs/ERP_PROJECT_REVIEW.md
# Conflicts: # docs/ERP_PROJECT_REVIEW.md
red1oon
added a commit
that referenced
this pull request
Aug 23, 2026
… 2026-08-23 Access-gate + Forms/ValRules T-0 items closed this session (bim-ootb #1495/#1496, bim-compiler #91). Written so a new session can pick up the remaining T-0 items (enumerable ledger, lane-index write-back) and the standing 454/476-process gap without re-deriving today's findings from docs/ERP_PROJECT_REVIEW.md §2.1/§7/§8. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GmNVMG9ZGcKygz4zXuCe6m
red1oon
added a commit
that referenced
this pull request
Aug 23, 2026
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.
Summary
Adds
AD_Formandad_val_ruletoscripts/ad_seed_manifest.json(383 tables), closing the manifest-side gap found in this session's fresh ERP triage against the live iDempiere Postgres. Verified against the live dockerpostgres/idempierecontainer:export_ad_seed.jslandsAD_Form=49rows (53 real, 4 inactive — exact match to a direct PG query) andad_val_rule=332rows (exact match), correct DDL/PK inferred from the PG catalog, zero errors, reproduced twice.NOT shipped — a real showstopper, not a detail
Running the full export against the current live PG container produces a severely regressed seed vs. what's actually deployed:
ad_seed.db(2026-07-05)Neither
idempierenoridempiere_teston the live container currently holds anywhere near the richer data state that built the shipped seed. The container has drifted or been reset since July. Re-exporting from it right now would regress production.Root cause, not a fix
The shipped
ad_seed.dbwas clearly built by a multi-stage pipeline beyondexport_ad_seed.jsalone — something addsfact_acct(likely fromidempiere_test, the posted-oracle DB perreference_idempiere_source.md), HR module rows, subscription rows, and client-13 shard data on top of the base GardenWorld export. That stage isn't identified here — this PR stops at the manifest fix and names the gap rather than guessing at a merge.Test plan
export_ad_seed.jsruns clean, 383/383 tables, 0 missingAD_Form/ad_val_rulerow counts verified against direct PG queriesClaude-Session: https://claude.ai/code/session_01GmNVMG9ZGcKygz4zXuCe6m