Purchasing: supplier-alias-search (30/40 specs) - #66
Conversation
CompanyLookup gains a supplier mode over purchasing_suppliers_search_retrieve and CompanyDetailPage gains a Supplier Aliases tab, so staff-entered nicknames let the PO-creation supplier picker find a company whose paperwork/Xero name diverges from its canonical CRM name. The backend (SupplierSearchAlias model, alias CRUD, the alias-aware search endpoint) was already built and tested in an earlier session but never wired to any UI — this slice is frontend-only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WENcwU8rC6o7bxuHL6md2L
… aliases Adversarial pre-PR review found two low-severity gaps in SupplierAliasesPanel: a double-click on remove could 404 on the second race and show a false failure toast, and a failed alias-list fetch rendered nothing (no error affordance, unlike the page's outer QueryState). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WENcwU8rC6o7bxuHL6md2L
Warning Review limit reached
Next review available in:41 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe frontend now supports supplier aliases in CRM and supplier-mode lookup during purchase-order creation. It exports the required API helpers, adds alias CRUD states, validates the flow with an E2E test, and updates rewrite progress documentation. ChangesSupplier alias search
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
actor User
participant CompanyDetailPage
participant SupplierAliasAPI
participant CompanyLookup
User->>CompanyDetailPage: Add supplier alias
CompanyDetailPage->>SupplierAliasAPI: Create alias
SupplierAliasAPI-->>CompanyDetailPage: Return alias
User->>CompanyLookup: Search by alias in PO creation
CompanyLookup->>SupplierAliasAPI: Query supplier search
SupplierAliasAPI-->>CompanyLookup: Return canonical supplier
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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: 3
🧹 Nitpick comments (1)
frontend/tests/e2e/purchasing/supplier-alias-search.spec.ts (1)
4-18: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRemove step narration from test comments.
Lines 27, 42, and 67 only restate the following test actions. Remove them.
If you retain the file-level comment, state the rejected alternative and the constraint. For example, state that direct API setup is rejected because this spec must validate the UI integration path.
As per coding guidelines, comments must document the rejected obvious alternative and factual constraint that rejected it; remove code narration and review-feedback echoes.
Also applies to: 27-27, 42-42, 67-67
🤖 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 `@frontend/tests/e2e/purchasing/supplier-alias-search.spec.ts` around lines 4 - 18, Remove the step-narrating comments near the test actions in the supplier alias search spec, including the sections around the visible line references. Retain or revise the file-level comment only to document that direct API setup is intentionally rejected because this spec must validate the UI integration path, including its required Xero-backed quick-create constraint; remove any review-feedback echoes.Source: Coding guidelines
🤖 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 `@docs/rewrite-status.md`:
- Around line 17-28: Update the supplier-alias-search status in the
rewrite-status documentation so it is not listed as green while live Xero
contact creation remains unreliable. Mark it as blocked by the Xero
authentication dependency, and apply the same status correction to the
corresponding entry near the later referenced section.
In `@frontend/src/api/index.ts`:
- Line 159: Remove the code-narration comments at frontend/src/api/index.ts
lines 159-159 and frontend/src/features/crm/CompanyDetailPage.tsx lines 51-55;
do not replace them unless each comment documents a rejected obvious alternative
and the factual constraint that rules it out.
In `@frontend/src/features/crm/CompanyDetailPage.tsx`:
- Around line 68-92: Prevent duplicate synchronous submissions in handleAdd and
handleRemove by adding separate useRef in-flight locks, checking and setting
each lock before mutateAsync, and clearing it in finally blocks. Keep
createAlias.isPending and destroyAlias.isPending for button state, and add tests
covering duplicate add and remove events.
---
Nitpick comments:
In `@frontend/tests/e2e/purchasing/supplier-alias-search.spec.ts`:
- Around line 4-18: Remove the step-narrating comments near the test actions in
the supplier alias search spec, including the sections around the visible line
references. Retain or revise the file-level comment only to document that direct
API setup is intentionally rejected because this spec must validate the UI
integration path, including its required Xero-backed quick-create constraint;
remove any review-feedback echoes.
🪄 Autofix
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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 04b2aa02-9704-4753-a65e-851f78f89086
📒 Files selected for processing (6)
docs/rewrite-status.mdfrontend/src/api/index.tsfrontend/src/features/crm/CompanyDetailPage.tsxfrontend/src/features/purchasing/PoSummaryCard.tsxfrontend/src/features/shared/company/CompanyLookup.tsxfrontend/tests/e2e/purchasing/supplier-alias-search.spec.ts
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
CompanyDetailPage: isPending is last-render state, so two clicks inside one render frame could both dispatch a mutation before it flips true. Add synchronous useRef in-flight locks for both alias handlers, checked and set before mutateAsync and cleared in finally, keeping isPending for button disabled-state only. rewrite-status.md: CodeRabbit was right to flag the earlier "green" claim. Root-caused via manage.py shell, outside the E2E harness entirely: this dev environment's Xero connection 403s with AuthenticationUnsuccessful on the first live API call in the create-company path (apps/xero/provider.py search_contact_by_name -> get_contacts), despite a valid-looking token and no rate-limit exhaustion. apps/xero is unmodified by this branch. Recorded as an environment blocker, not code defect, and the spec's status corrected to reflect it passed once but isn't yet confirmed reliable. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WENcwU8rC6o7bxuHL6md2L
corrin
commented
Aug 11, 2026
Re the nitpick on Replied inline to the other three threads (rewrite-status.md, the two comment-narration findings, and the double-submit race) — summary in the latest commit message (5b12533). |
Uh oh!
There was an error while loading. Please reload this page.
Summary
CompanyLookupgains amode?: 'company' | 'supplier'prop, swapping itsquery source to the already-built, alias-aware
purchasing_suppliers_search_retrieveendpoint.PoSummaryCard'screate-mode supplier picker now uses it.
SupplierSearchResultturnedout to be an exact structural superset of
CompanySearchResult, so noother prop or consumer needed to change.
CompanyDetailPagegains a third "Supplier Aliases" tab(
SupplierAliasesPanel) for adding/listing/removing a company's searchaliases, wired to the already-built alias CRUD endpoints.
SupplierSearchAlias, its CRUD API, and thealias-aware search endpoint already existed from an earlier session but
were never wired to any UI. This slice is frontend-only.
frontend/tests/e2e/purchasing/supplier-alias-search.spec.ts:quick-creates a supplier via live Xero push, adds an alias on the detail
page, then confirms searching by the alias on PO create resolves to the
canonical company name.
low-severity gaps in
SupplierAliasesPanel, fixed in the second commit:a double-click race on "remove alias" could show a false failure toast,
and a failed alias-list fetch rendered nothing instead of an error/retry
affordance.
docs/rewrite-status.mdupdated: specs-ported count regenerated viascripts/checks/status_table.py(29→30), "next in cluster" now pointsat
pickup-address.Verification
npm run type-check,pre-commit run --all-files --hook-stage pre-push(full expensive tier, whole repo): all green.
uv run pytest apps/company apps/purchasing: 356 passed, no regressions(backend code is unchanged).
./scripts/ops/run_e2e.sh supplier-alias-search: passed once, cleanly,end to end (before the two review-driven fixes above).
same pre-existing, unmodified-by-this-branch step —
/api/companies/create/pushing a new contact to the live Xero demo tenant — with Xero-side auth
errors (
Xero pingreportedconnected=Truein every run; the failure isspecific to the contact-create call, not general connectivity).
apps/xeroand
apps/company's push logic are untouched by this branch, and the veryfirst run — before any of the review fixes — passed cleanly, so this looks
like environmental flakiness on the live demo tenant (plausibly triggered by
my own rapid repeated pushes) rather than a regression. CI does not run
the Playwright/Xero E2E suite at all (checked
.github/workflows/ci.yml— only lint/type/unit tests), so this doesn't block CI. Worth a clean rerun
of
./scripts/ops/run_e2e.sh supplier-alias-searchbefore merge, once thedemo tenant has had time to settle.
Test plan
🤖 Generated with Claude Code
https://claude.ai/code/session_01WENcwU8rC6o7bxuHL6md2L
Summary by CodeRabbit