Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03e204ae31
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| items: props.bill.items.map((item) => ({ | ||
| ...item, | ||
| optionalityChecked: null, | ||
| })), |
There was a problem hiding this comment.
This change stops sending totalAmount: props.total and relies on raw items totals, so createPayment now trusts posBillItemLine.totalAmount for the persisted payment amount. In this codebase that field can diverge from the UI total when quantity is incremented (see useBill.addItem math), so a bill with repeated items can be saved with an incorrect paid amount. Keep using the computed bill total here (or recompute from price × quantity) when creating the payment.
Useful? React with 👍 / 👎.
| "invoiceSettings.defaultDueDateDays as defaultDueDateDays", | ||
| "invoiceSettings.defaultPaymentMethod as defaultPaymentMethod", |
There was a problem hiding this comment.
New-invoice defaults are now read only from invoiceSettings, but this commit also moved those fields out of billingSettings without a backfill path for existing profiles (only onboarding seeds new rows). For existing installations, invoiceSettings will be empty and previously configured due-date/payment defaults silently reset to fallbacks, changing invoice behavior until users manually re-save settings. Add a migration (or legacy fallback reads) before depending solely on this table.
Useful? React with 👍 / 👎.
| nextCursor = { | ||
| id: last.id, | ||
| [sortingField]: last[sortingField], | ||
| }; |
There was a problem hiding this comment.
The cursor is written under sortingField (for example createdAt), but the next-page query reads previousCursor[finalSorting.id] where finalSorting.id is a qualified column name (for example reconciliationClaim.createdAt). Because those keys differ, subsequent page filters compare against undefined, which can break pagination after the first page. Write the cursor value using the same key that the query later reads.
Useful? React with 👍 / 👎.
1 participant
No description provided.