Expand description
Maps a rendered rpc::TransactionDraft (a flat list of signed splits)
onto the create form’s transfer-row model (each row is a from→to pair that
process_split_data later expands back into two splits).
Lossless-or-nothing. The form’s transfer-row model is strictly LESS
expressive than a flat split list, so a naive sign-pairing would invent
structure that submitting can’t reconstruct — silently persisting a
different transaction than the template rendered. To never do that,
draft_to_prefilled only accepts drafts it can represent EXACTLY and
returns None otherwise (the create page then simply shows no prefill). The
accepted shape matches how favourite-transaction templates are written:
consecutive (from −x) then (to +x) draft-split pairs, each amount an
exact terminating decimal, and same-commodity pairs balancing to equal
magnitude. Ambiguous 1→N drafts, non-terminating ratios (1/3), and
unparseable dates all fail closed rather than degrade.
Structs§
- Prefilled
Draft - Prefilled
Row - One transfer row for the create form. Account/commodity are uuids; the
browser resolves display names via
/api/account/list(as the from-account prefill already does), so the server side stays name-free. - Prefilled
Tag
Functions§
- draft_
to_ prefilled - Builds a prefill for the create form, or
Nonewhen the draft cannot be represented EXACTLY as transfer rows (ambiguous split structure, non-terminating amount, or unparseable date). ReturningNonemeans “show no prefill” — never a silently-altered transaction. - to_
script_ safe_ json - Serializes a value to JSON safe for inlining inside an HTML
<script>block.serde_jsondoes not escape<,>, or&, so a string field containing</script>would otherwise break out of the tag (a template author controls the note/tag text → stored self-XSS). Escaping</>/&to their\uXXXXforms is still valid JSON thatJSON.parse/window.x = …reads identically, and cannot terminate the script element.