# Annotated discount-approval review

Reviewed 2026-11-05. This is an original editorial Python specimen, not client code or an installable Odoo addon.

## Approved example contract

User 7 may approve the current revision of a draft quotation in company A for an invented discount from 0% through 10.00%. The command records the trusted actor and one audit effect per quotation revision. A rejected input or injected failure must leave the agreed batch unchanged. Approval does not confirm the quotation or post accounting.

## Confirmed local findings

| ID | Finding and consequence | Reproducer | Required correction |
|---|---|---|---|
| F01 | Missing current authority/company checks permits an unauthorized approval. | actor_without_approval_role; record_in_unauthorized_company | Validate the trusted execution identity against the target before mutation. |
| F02 | Missing current revision/lifecycle/limit checks approves stale, cancelled or 10.01% work. | reviewed_revision_is_stale; cancelled_quotation; 10_01_percent_requires_another_decision | Compare actual current values with the approved business contract. |
| F03 | Caller-selected attribution writes user 99 instead of trusted user 7. | caller_supplies_false_approver | Derive the recorded actor from trusted identity. |
| F04 | Repeated selection creates multiple audit effects. | duplicate_selection_in_one_request; repeat_same_approval | Recognize the completed approval revision, including duplicate IDs within a request. |
| F05 | Failure leaves partial state or a partly processed batch. | audit_failure_after_state_assignment; batch_second_company_is_unauthorized; batch_second_audit_write_fails | Prove the agreed all-or-nothing outcome; the Python copy is only an illustration. |

The two positive controls, ordinary 5.00% approval and the inclusive 10.00% boundary, pass both specimens. The flawed specimen violates 11 of 13 contract cases; the corrected specimen meets 13 of 13. These are constructed cases, not an AI reliability rate or native Odoo measurement.

## Code annotations

The comments A–D in flawed_approve identify missing checks, caller-controlled attribution, mutation before failure and repeated effects. corrected_approve checks the contract against a staged copy, normalizes duplicate selection IDs and swaps the state only after successful completion.

This does not implement Odoo ACLs, domains, SQL transactions, concurrency control or upgrade logic. No claim is made that copying the function into a module would be correct.

## Native release gate

native-acceptance.json is separate and remains NOT_RUN. Before release, approve the actual rule, identify the Odoo/module/dependency revisions, execute relevant entry points under real authorized and denied identities, and retain final records. Verify native transaction/concurrency behavior, test discovery, a clean install and an existing-data upgrade rehearsal. Business policy approval is separate from technical evidence.

Primary source context: Odoo 20 public-method security guidance, coding guidelines, testing documentation and customized-database upgrade guide. Exact links and support are in the article and research ledger.