Vis pakker bruker ikke har ved søk på brukersiden - #2406
Conversation
|
Warning Review limit reached
Next review available in: 34 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 Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughSearch mode now filters available packages by party type and displays assigned and unassigned areas in separate localized sections. ChangesAccess package search results
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ActiveDelegations
participant AccessPackageList
participant useAreaPackageList
ActiveDelegations->>AccessPackageList: enable search display modes
AccessPackageList->>useAreaPackageList: request area package results
useAreaPackageList-->>AccessPackageList: return filtered matching areas
AccessPackageList-->>ActiveDelegations: render localized grouped results
Suggested labels: Suggested reviewers: 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: 1
🧹 Nitpick comments (1)
src/features/amUI/common/AccessPackageList/AccessPackageList.tsx (1)
157-158: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConfusing variable naming: "assignable" vs "unassignable" reads backwards here.
areasAssignablePackagesholds areas that already have an assigned/matched package, whileareasUnassignablePackagesholds areas that don't. That's the opposite of what "assignable"/"unassignable" typically implies (available-to-assign vs not), which risks future misreads.♻️ Suggested rename
- const areasAssignablePackages = combinedAreas.filter((x) => x.packages.assigned.length > 0); - const areasUnassignablePackages = combinedAreas.filter((x) => x.packages.assigned.length === 0); + const areasWithActiveMatches = combinedAreas.filter((x) => x.packages.assigned.length > 0); + const areasWithoutActiveMatches = combinedAreas.filter((x) => x.packages.assigned.length === 0);(and update the corresponding usages below)
🤖 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 `@src/features/amUI/common/AccessPackageList/AccessPackageList.tsx` around lines 157 - 158, Rename areasAssignablePackages and its corresponding usages to reflect that these areas already have assigned packages, and rename areasUnassignablePackages and all usages to reflect that these areas have no assigned packages; preserve the existing filter conditions and behavior.
🤖 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 `@src/features/amUI/common/AccessPackageList/useAreaPackageList.ts`:
- Around line 153-159: Update the showAllAreas filtering in useAreaPackageList
to compare area.typeName with the same Person/Organization values used by
AccessPackageList rather than Norwegian labels, and only apply the party-type
predicate when filterByType is enabled. Include filterByType in the useMemo
dependency array so memoized results update correctly.
---
Nitpick comments:
In `@src/features/amUI/common/AccessPackageList/AccessPackageList.tsx`:
- Around line 157-158: Rename areasAssignablePackages and its corresponding
usages to reflect that these areas already have assigned packages, and rename
areasUnassignablePackages and all usages to reflect that these areas have no
assigned packages; preserve the existing filter conditions and behavior.
🪄 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 Plus
Run ID: 05d037bf-f8a4-461f-a986-de76a164b106
📒 Files selected for processing (7)
src/features/amUI/common/AccessPackageList/AccessPackageList.module.csssrc/features/amUI/common/AccessPackageList/AccessPackageList.tsxsrc/features/amUI/common/AccessPackageList/useAreaPackageList.tssrc/features/amUI/userRightsPage/AccessPackageSection/ActiveDelegations.tsxsrc/localizations/en.jsonsrc/localizations/no_nb.jsonsrc/localizations/no_nn.json
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@src/features/amUI/common/AccessPackageList/useAreaPackageList.ts`:
- Around line 55-58: Align the organization type value in the typeName mapping
with the canonical area value by using “Organization” instead of “Organisasjon”.
Update the post-query filtering logic around the useMemo at lines 154–183 so it
only filters by party type when filterByType is true, and add filterByType to
that useMemo’s dependency array.
🪄 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 Plus
Run ID: a800776d-39b2-47f2-8de4-3b64a5512414
📒 Files selected for processing (1)
src/features/amUI/common/AccessPackageList/useAreaPackageList.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/features/amUI/common/AccessPackageList/AccessPackageList.tsx (1)
204-225: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winPreserve the grouped empty state for searches.
When
showUnassignedAvailableAreasis enabled and a search returns no areas, these early returns bypassTreff i aktive fullmakter:and its dedicated empty message. Keep the generic no-match/no-packages returns for ungrouped lists only, or let the grouped renderer handle empty search results.Proposed fix
+ const isGroupedSearch = showUnassignedAvailableAreas && Boolean(searchString); + if ( searchString && searchString.length > 0 && + !isGroupedSearch && (allPackageAreas === undefined || allPackageAreas.length === 0 || displayAreas.length === 0) ) { ... - if (displayAreas.length === 0 && !searchError && !activeDelegationsError) { + if (displayAreas.length === 0 && !isGroupedSearch && !searchError && !activeDelegationsError) {🤖 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 `@src/features/amUI/common/AccessPackageList/AccessPackageList.tsx` around lines 204 - 225, Update the early empty-state returns in the AccessPackageList render flow so they apply only to ungrouped lists when showUnassignedAvailableAreas is disabled. When grouped rendering is enabled, allow empty search results to reach the grouped renderer so it preserves “Treff i aktive fullmakter:” and its dedicated empty message.
🤖 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 `@src/features/amUI/common/AccessPackageList/AreaItem.tsx`:
- Line 70: Update the titleAs construction in AreaItem so an omitted
headingLevel defaults to 3 before interpolation, preserving the existing h3
fallback while retaining explicitly provided heading levels.
---
Outside diff comments:
In `@src/features/amUI/common/AccessPackageList/AccessPackageList.tsx`:
- Around line 204-225: Update the early empty-state returns in the
AccessPackageList render flow so they apply only to ungrouped lists when
showUnassignedAvailableAreas is disabled. When grouped rendering is enabled,
allow empty search results to reach the grouped renderer so it preserves “Treff
i aktive fullmakter:” and its dedicated empty message.
🪄 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 Plus
Run ID: dd94680c-3f94-4515-82d4-6e4141194730
📒 Files selected for processing (5)
src/features/amUI/common/AccessPackageList/AccessPackageList.tsxsrc/features/amUI/common/AccessPackageList/AreaItem.tsxsrc/features/amUI/common/AccessPackageList/AreaItemContent.tsxsrc/features/amUI/poaOverview/AccessPackagePermissions.tsxsrc/features/amUI/poaOverview/GuardianshipPermissions.tsx
Description
Related Issue(s)
Verification
Documentation
Summary by CodeRabbit