[gonzalesedwin1123]

Fixes #582.

Problem

spp_base_common extends web.FormView so a module can hide the form's control-panel New button by setting this.hideFormCreateButton = true. The extension replaced the button's t-if instead of extending it, so Odoo's own canCreate guard was dropped. canCreate is the single switch behind every way a form is opened without create: {'create': False} in the action context, create="0" on the form arch, and a role without create access. In all three cases the form still rendered a live, keyboard-reachable New that opened a blank editable record, or failed with an access error on save.

Only the control-panel button was affected. Stock Odoo has a second o_form_button_create in the separate web.FormView.Buttons template (dialog footers); the extension never touched it, so forms in dialogs always behaved. For the same reason the fourth input to canCreate, preventCreate, was never exposed: it is only passed by FormViewDialog, which also turns the control panel off.

On stacks with spp_programs the defect was masked by spp_programs/static/src/js/form_controller_create.js, which hides the rendered button with display: none; its comment blames Odoo 19, but stock Odoo hides the button correctly. Stacks without spp_programs showed New on every read-only form.

Fix

spp_base_common/static/src/xml/custom_list_create_template.xml: the condition is now canCreate and !hideFormCreateButton. The flag can only hide the button, never show it; the three modules that set it (spp_programs, spp_change_request_v2, spp_drims) keep working unchanged. spp_base_common → 19.0.2.0.3, HISTORY fragment added.

Impact on other modules

The new condition can only hide the button in more cases. No module forces it on. Screens that lose New are exactly the ones that declared they should not have it: 19 form archs with create="0" (logs, audit, approval reviews, entitlements, memberships, payment batches, scoring, studio), the three spp_programs actions with {'create': False} that reach a form (in-kind entitlements, cash entitlements, program memberships; the spp_consent expired-consents action is list-only) and about 45 Python-returned action dicts across 12 modules that pass create: False, each judged a read-only "view X" screen or a dialog, CR detail forms opened from the Change Requests list, and every read-only ACL. The spp_programs DOM workaround and the .o_form_button_create selector in spp_farmer_registry's restriction patch become redundant (follow-up issue, not changed here). The e2e suite's six New clicks are all by admin where create is allowed.

Tests

• Python (CI gate, red before the fix): spp_base_common/tests/test_form_create_button_template.py applies the extension to the real stock web.FormView template with Odoo's own odoo.tools.template_inheritance and asserts the resulting button condition keeps canCreate (and still !hideFormCreateButton); a second test asserts the dialog-button template is untouched. Before the fix: Regex didn't match: '\bcanCreate\b' not found in '!hideFormCreateButton', 1 failed of 9. After: 0 failed of 9.
• Playwright (spec 01): .o_form_button_create has DOM count 0 on the change-request detail form the create wizard opens with context: {create: False} (test 16, admin; nothing on that arch or in a FormController patch hides the button, so this is the pure context path) and on an approval review form as the HQ validator (test 20; create="0" on the arch and no create ACL for the role). Count rather than visibility, because the spp_programs workaround only sets display:none. Not run locally (port 8069 is taken on my machine); dispatched on this branch: run 37724359788 is green (spec 01: 24 passed, spec 02: 1 passed; both new assertions executed) — https://github.com/OpenSPP/OpenSPP2/actions/runs/37724359788
• Why no tour/Hoot test: the test image has no Chrome, so HttpCase browser tests are skipped silently in CI and would be green before and after.
• Browser check (Claude in Chrome, MIS demo stack with spp_programs): before, a form opened with {'create': False} had the button in the DOM with display:none and the live template condition read !hideFormCreateButton; after, count 0 and the condition reads canCreate and !hideFormCreateButton. A normal registrant form as admin still shows New; a hazard incident form as the demo CR HQ validator (read, no create; arch has no create="0") renders none.

Follow-ups

• Follow-up for the spp_programs workaround and the stale comments: spp_programs: retire the DOM workaround for the form "New" button now that #582 keeps canCreate #589.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.08%. Comparing base (6db1d94) to head (d7ef2ba).

Additional details and impacted files

@@            Coverage Diff             @@
##             19.0     #588      +/-   ##
==========================================
- Coverage   77.09%   77.08%   -0.02%     
==========================================
  Files         727      736       +9     
  Lines       46864    47835     +971     
==========================================
+ Hits        36131    36874     +743     
- Misses      10733    10961     +228     

Flag	Coverage Δ
spp_analytics	93.25% <ø> (ø)
spp_api_v2_change_request	73.37% <ø> (ø)
spp_api_v2_cycles	71.03% <ø> (ø)
spp_api_v2_data	77.77% <ø> (ø)
spp_api_v2_entitlements	70.23% <ø> (ø)
spp_api_v2_gis	74.60% <ø> (ø)
spp_api_v2_programs	94.55% <ø> (+2.74%)	⬆️
spp_api_v2_service_points	71.03% <ø> (ø)
spp_api_v2_simulation	71.19% <ø> (ø)
spp_approval	50.85% <ø> (ø)
spp_area	80.16% <ø> (ø)
spp_area_hdx	81.60% <ø> (ø)
spp_audit	72.13% <ø> (?)
spp_base_common	91.07% <ø> (ø)
spp_case_cel	89.50% <ø> (ø)
spp_case_demo	94.82% <ø> (ø)
spp_programs	67.58% <ø> (ø)
spp_registry	89.00% <ø> (ø)
spp_security	69.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 12 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[reichie020212]

Approve. No blocking findings. Hostile review at head cf398db9597f37ae315ba79c05cf229f86e05188 (0 commits behind 19.0).

The one-line fix restores stock behaviour. Stock Odoo 19 renders the control-panel button as t-if="canCreate" (web/static/src/views/form/form_controller.xml:9). canCreate = create && !this.props.preventCreate (form_controller.js:170). canCreate and !hideFormCreateButton therefore can only hide the button relative to stock, never show it.

Checked and cleared

• The regression test runs, and it fails on the old code. The test (spp_base_common) CI job logs both TestFormCreateButtonTemplate cases starting, then 0 failed, 0 error(s) of 9 tests. The exact-equality assertion rejects both the old !hideFormCreateButton and an or re-spelling. apply_inheritance_specs accepts a list of specs (template_inheritance.py: specs = specs_tree if isinstance(specs_tree, list) else [specs_tree]). hasclass is registered globally by ir_ui_view.py (xpath_utils['hasclass']), so the plain lxml .xpath() in the test resolves.
• The cited e2e run still describes this head. Run 37724359788 ran on 8f0bf8445 (both specs green). git diff --stat 8f0bf8445 cf398db95 touches only README.rst and static/description/index.html, so no runtime file changed since.
• The e2e assertions would fail on the old code.
  • Test 16: open_cr_close_modal opens the detail model (change_request.detail_res_model, not spp.change.request) with context: {create: False} (create_wizard.py). The only hideFormCreateButton patches are keyed to spp.change.request, spp.program and the DRIMS dispatch model, so before the fix the button rendered on that form.
  • Test 20: spp.approval.review's form declares <form create="0"> (approval_review_views.xml:53).
  • Both tests assert toHaveCount(0) rather than visibility, so spp_programs' display:none workaround cannot hide a failure.
• Blast radius. custom_list_create_template.xml is the only OpenSPP template that touches o_form_button_create. The dialog-footer copy (web.FormView.Buttons) was never extended. The three hideFormCreateButton users only ever set it to true, so and-ing in canCreate changes nothing for them.
• Manifest and changelog. 19.0.2.0.2 → 19.0.2.0.3 is above base. The HISTORY fragment is present and the README was regenerated. Closes links #582. The spp_programs DOM workaround and its comment wrongly blaming Odoo are tracked in #589, which is fine to defer: with this fix the workaround is redundant but harmless.

Note (not a finding)

• The pre-commit check is still pending (since 04:00Z), so mergeStateStatus reads UNSTABLE. It is worth letting that finish before merging.