Zugferd-Refactoring#570
Conversation
|
Warning Review limit reached
Next review available in: 49 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughDiese PR ersetzt fest kodierte ZUGFeRD-Standardwerte durch ChangesZUGFeRD-Settings-Integration
Toast Dismiss-Verhalten
Estimated code review effort: 2 (Simple) | ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
resources/js/Components/twc-ui/sonner.tsx (1)
171-187: 🎯 Functional Correctness | 🔴 Critical | ⚡ Quick winBuild-Fehler:
propsexistiert nicht intoast.promise.In Zeile 183 wird
props.isDismissiblereferenziert, obwohl im Scope vontoast.promisenuroptionsdestrukturiert wird (Zeile 172:title, message, loading, success, error, duration– keinisDismissible). Das bestätigt auch der Build-Fehler aus der statischen Analyse: „Cannot find name 'props'". Zusätzlich fehltisDismissibleals Feld inPromiseToastOptions(Zeile 134-142), sodass selbst nach Korrektur der Variable das Feld nicht existiert.🐛 Vorschlag zur Behebung
interface PromiseToastOptions<T = unknown> { type?: ToastVariant title?: string message: string loading?: string success?: string | ((data: T) => string) error?: string | ((error: unknown) => string) duration?: number + isDismissible?: boolean }toast.promise = <T,>(promise: Promise<T>, options: PromiseToastOptions<T>) => { - const { type, title, message, loading, success, error, duration } = options + const { type, title, message, loading, success, error, duration, isDismissible } = options const id = crypto.randomUUID() sonnerToast.custom( id => ( <Toast id={id} title={title} message={loading ?? message} type={type ?? 'default'} isLoading - isDismissible={!loading && !props.isDismissible} + isDismissible={isDismissible ?? false} /> ), { id, duration: Infinity } )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@resources/js/Components/twc-ui/sonner.tsx` around lines 171 - 187, `toast.promise` references an undefined `props` symbol and also relies on an `isDismissible` field that is missing from `PromiseToastOptions`. Update `toast.promise` in `sonner.tsx` to read dismissibility from the destructured options (or another valid local source) instead of `props`, and add `isDismissible` to `PromiseToastOptions` if it should be configurable there. Ensure the `Toast` call in `toast.promise` uses the corrected dismissible flag and keeps the existing loading/message behavior intact.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@resources/js/Components/twc-ui/sonner.tsx`:
- Line 158: The isDismissible prop in the Sonner wrapper is being inverted, so
explicit caller values are ignored in favor of the opposite boolean. Update the
logic in sonner.tsx where isDismissible is passed so props.isDismissible is used
directly, and only fall back to a loading-based default when the prop is not
provided. Keep the fix localized to the Sonner component/props handling around
isDismissible.
In `@resources/js/Pages/App/Invoice/InvoiceForm.tsx`:
- Around line 110-113: The contact-change sync in InvoiceForm is leaving a stale
zugferd_route_id in the form when the newly selected contact has no Leitweg-ID.
Update the existing useEffect logic around selectedContact so zugferd_route_id
is always synchronized on every contact change, just like invoice_contact_id,
dunning_block, payment_deadline_id, and tax_id, and explicitly clear it to an
empty value when selectedContact.zugferd_route_id is missing.
---
Outside diff comments:
In `@resources/js/Components/twc-ui/sonner.tsx`:
- Around line 171-187: `toast.promise` references an undefined `props` symbol
and also relies on an `isDismissible` field that is missing from
`PromiseToastOptions`. Update `toast.promise` in `sonner.tsx` to read
dismissibility from the destructured options (or another valid local source)
instead of `props`, and add `isDismissible` to `PromiseToastOptions` if it
should be configurable there. Ensure the `Toast` call in `toast.promise` uses
the corrected dismissible flag and keeps the existing loading/message behavior
intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 1c0b6e99-49c6-4fde-b5ed-93a589c32f5d
📒 Files selected for processing (6)
app/Http/Controllers/App/InvoiceController.phpapp/Models/Invoice.phpresources/js/Components/twc-ui/sonner.tsxresources/js/Pages/App/Invoice/InvoiceCreate.tsxresources/js/Pages/App/Invoice/InvoiceDetailsEditBaseData.tsxresources/js/Pages/App/Invoice/InvoiceForm.tsx
| <Toast | ||
| id={id} | ||
| isLoading={props.isLoading} | ||
| isDismissible={!props.isLoading && !props.isDismissible} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file outline =="
ast-grep outline resources/js/Components/twc-ui/sonner.tsx --view expanded || true
echo "== relevant lines =="
nl -ba resources/js/Components/twc-ui/sonner.tsx | sed -n '130,210p'
echo "== search isDismissible usages =="
rg -n "isDismissible" resources/js -S || trueRepository: dspangenberg/opsc
Length of output: 1119
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== file size =="
wc -l resources/js/Components/twc-ui/sonner.tsx
echo "== slice around line 158 =="
sed -n '145,175p' resources/js/Components/twc-ui/sonner.tsx | cat -n
echo "== slice around line 183 =="
sed -n '175,195p' resources/js/Components/twc-ui/sonner.tsx | cat -n
echo "== all isDismissible occurrences with context =="
grep -n -C 2 "isDismissible" resources/js/Components/twc-ui/sonner.tsx || trueRepository: dspangenberg/opsc
Length of output: 2861
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Toast component section =="
sed -n '72,130p' resources/js/Components/twc-ui/sonner.tsx | cat -n
echo "== promise toast section =="
sed -n '175,220p' resources/js/Components/twc-ui/sonner.tsx | cat -nRepository: dspangenberg/opsc
Length of output: 3855
isDismissible nicht negieren
!props.isLoading && !props.isDismissible kehrt einen expliziten Wert um: true wird zu false, false wird im Nicht-Ladezustand zu true. Der Aufruferwert sollte direkt gelten; nur ohne Angabe sollte der Ladezustand den Default bestimmen.
🐛 Vorschlag zur Behebung
- isDismissible={!props.isLoading && !props.isDismissible}
+ isDismissible={props.isDismissible ?? !props.isLoading}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| isDismissible={!props.isLoading && !props.isDismissible} | |
| isDismissible={props.isDismissible ?? !props.isLoading} |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@resources/js/Components/twc-ui/sonner.tsx` at line 158, The isDismissible
prop in the Sonner wrapper is being inverted, so explicit caller values are
ignored in favor of the opposite boolean. Update the logic in sonner.tsx where
isDismissible is passed so props.isDismissible is used directly, and only fall
back to a loading-based default when the prop is not provided. Keep the fix
localized to the Sonner component/props handling around isDismissible.
Summary by CodeRabbit
Neue Funktionen
Verbesserungen
Bug Fixes