Repository navigation
fix: keep invoice fields consistent across creation modes - #314
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Hooray! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
There was a problem hiding this comment.
🟡 Changes recommended
CSS-only ordering leaves screen-reader and keyboard navigation sequences inconsistent with the displayed fields.
1 open issue
What changed in this PR
Improves API reference consistency across invoice creation modes without changing downloadable contracts.
Changes:
- Uses native Issue/Draft tabs and consistent customer/product labels.
- Stabilizes visual field order for invoices and retentions.
- Improves select readability in dark mode.
| File | Description |
|---|---|
| website/src/pages/api.tsx | Normalizes presentation labels, mode tabs, and descriptions. |
| website/src/css/custom.css | Adds stable visual ordering and dark-mode select colors. |
Review effort: Balanced
Switching between issuing an invoice and saving a draft changes the field order and customer labels. The status selector also makes an optional request field look like the first step, and its text is unreadable in dark mode.
Native oneOf tabs separate Issue/Draft from the request fields while retaining the invoice-type tabs. Both modes keep customer, items and payment_form first, followed by the same field order. Customer descriptions and labels match; drafts retain a No customer option for their allowed null value. Equivalent customer choices in receipts, receipt invoicing, and retentions use the same labels while keeping their operation-specific guidance. Invoice item variants use Product details / Registered product without changing their distinct fiscal structures. Complete and draft retentions also retain a stable field order. Property insertion order and the supported required-first sorting option keep the DOM reading order aligned with the visual order, without CSS reordering; required fields retain their original constraints. The type description explains its relationship to the selected invoice type, and native selects use dark-mode colors.
These changes affect only the reference presentation. The downloadable OpenAPI files and SDK contracts are unchanged. No ReDoc internals are patched, and request samples keep their independent selection.
Validation: the complete Spanish/English site build passes without a heap override. Browser checks cover mode switching, the required draft status, stable invoice and retention field order, receipt customer alternatives, product labels, and item expansion. Additional browser checks verify matching DOM/visual order for all ten invoice modes and both retention modes, preserved required markers, and keyboard traversal from customer to items. No screen reader application was exercised. No new test cases were added.