Both Item Price lookups order by valid_from desc and take the first valid row.
MariaDB sorts NULL valid_from last; Postgres first, so the undated base price was
winning over a dated one. Order by (valid_from IS NULL) asc, valid_from desc (the
get_all is converted to qb since its order_by won't take such an expression).
MariaDB output is unchanged.
get_items orders Item Price by valid_from and picks the first match. MariaDB sorts
NULL valid_from last under DESC (so a dated price wins); Postgres sorts it first,
so the undated base price wins and POS shows the wrong rate. Order by
(valid_from IS NULL) asc, valid_from desc so NULLs sort last on both backends
regardless of any real date value (MariaDB unchanged).
Measured A/B on the self-hosted setup: warm-bench restore 85s vs full
bench init 82s — no gain (slightly slower). bench init is already fast
because the uv/pip caches are mounted warm, so the cache only replaces a
~13s init while adding a ~200MB untar and still running bench build.
Drop BENCH_CACHE_DIR so warm-bench stays inert (the helper functions
remain, matching develop's install.sh).
- Wire up warm-bench: set BENCH_CACHE_DIR on the setup job so the bench-base
cache actually activates (was inert with no dir set, so every run did a
full bench init). Lives on the node-local bench-staging hostPath; any
miss/failure still falls back to a full init.
- run_ci_step: capture the timeout exit code under `set -e` (the previous
`timeout ...` + `ec=$?` aborted at the timeout line on failure, skipping
::endgroup:: and the exit-code return).
- Raise the per-step timeout 600s -> 1800s so a contended reinstall isn't
killed before the 40-min job timeout.
- Propagate DB through the su re-exec in start-db.sh / hydrate.sh so a
DB=postgres invocation can't silently fall back to the mariadb branch.
- Simplify the coverage job `if` to the equivalent plain non-PR gate.
The fan-out moved fsync/synchronous_commit/full_page_writes=off into
start-db.sh startup flags, but the Postgres workflow runs a postgres:13.3
service container and calls install.sh directly — it never runs start-db.sh.
So those flags never reached the Postgres CI, regressing it to full durability
on a commit-heavy suite. Re-apply them via ALTER SYSTEM (reloadable) in the
DB == "postgres" path, where the service-container workflow executes. MariaDB
is unaffected (DB != postgres).
Remove the `|| 'develop'` fallback on FRAPPE_BRANCH so install.sh resolves the
frappe framework branch from the git context (GITHUB_BASE_REF/GITHUB_REF), the
same as the Postgres workflow. This makes the workflow backportable unchanged:
on version-15-hotfix / version-16-hotfix it now clones the matching frappe
branch instead of develop.
Replaces the previous over-engineered stub with 7 short functions.
Account data, Account Closing Balance, and all metadata come from
frappe.db as normal; only tabGL Entry is read from the duckdb_conn.
Reuses get_opening_balance() for Account Closing Balance unchanged,
reuses all downstream compute helpers (calculate_values, prepare_data,
etc.) unchanged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replaces the placeholder stub with 8 focused functions that mirror the
normal execute() flow using parameterized DuckDB SQL queries: account
fetch, period GL entries, opening balances (with Period Closing Voucher
path), and all filters (cost center, project, finance book, accounting
dimensions). Reuses existing pure-Python processing functions unchanged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The calendar view sends filters as a list of [doctype, field, op, value]
conditions (filter_area.get()); get_filter_conditions_qb accepts dict or list.
create_prospect_against_crm_deal and create_customer read `contacts`
from form_dict (json.loads(doc.contacts) / customer_data.get("contacts")),
which arrives as a native list under JSON body mode. Use frappe.parse_json.
make_payment_request(**args) is whitelisted and the client passes
`schedules` as a list, so json.loads(args.get("schedules")) raised
TypeError under JSON body mode. Use frappe.parse_json.
Opt ERPNext into native application/json request bodies (frappe#40237).
Non-GET requests to erpnext.* endpoints now send args as a JSON body
instead of form-encoded, per-key JSON-stringified values. Safe after the
preceding commits hardened every whitelisted endpoint with frappe.parse_json.
