Skip to content

Conversation

@codycooperross
Copy link
Contributor

@codycooperross codycooperross commented Dec 12, 2025

Purpose

This PR is intended to implement the following:

closes: https://github.com/datacite/product-backlog/issues/515
closes: https://github.com/datacite/product-backlog/issues/516
closes: https://github.com/datacite/product-backlog/issues/517

Approach

Open Questions and Pre-Merge TODOs

Learning

Types of changes

  • Bug fix (non-breaking change which fixes an issue)

  • New feature (non-breaking change which adds functionality)

  • Breaking change (fix or feature that would cause existing functionality to change)

Reviewer, please remember our guidelines:

  • Be humble in the language and feedback you give, ask don't tell.
  • Consider using positive language as opposed to neutral when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
  • Offer suggestions on how to improve code e.g. simplification or expanding clarity.
  • Ensure you give reasons for the changes you are proposing.

Summary by CodeRabbit

  • New Features

    • Organization relation-type filter and new clients/repository facets.
    • Info tooltips for facets and improved keyboard/click navigation for facet items.
    • Conditional metrics display integrated into work listings based on relation type.
    • client-id added to search variables across relevant search pages.
  • Refactor

    • Simplified layout consolidating summary metrics and related content presentation.
  • Style

    • Spacing and metrics layout adjustments; dashboard spacing updated.
  • Tests

    • Facet-related assertions updated for new ordering.
  • Chores

    • Minor framework update.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 12, 2025

Walkthrough

Removes rorFundingIds and RelatedContent embedding from Content, introduces organizationRelationType and clientId in mapped search params, threads vars and showMetrics into WorksListing → SummarySearchMetrics → MetricsDisplay, adds InfoTooltip and organization-relation-type facet, updates facets/types/styles, and bumps Next.js.

Changes

Cohort / File(s) Summary
ROR page layout & search params
src/app/(main)/ror.org/[rorid]/page.tsx, src/app/(main)/ror.org/[rorid]/Content.tsx, src/app/(main)/ror.org/[rorid]/RelatedContent.tsx, src/app/(main)/ror.org/[rorid]/mapSearchParams.ts
Remove rorFundingIds usage from Content; RelatedContent now omits funding IDs, builds vars without them and computes showMetrics; mapSearchParams adds organizationRelationType (default allRelated) and clientId; page imports/renders RelatedContent.
Search query & types
src/data/queries/searchDoiQuery.ts, src/data/types.ts
Replace rorFundingIds with organizationRelationType in QueryVar and buildOrgQuery; buildOrgQuery chooses relation-specific query fragments via switch; add tooltipText?: string to Facet and clients?: Facet[] to Works.
Works listing & metrics wiring
src/components/WorksListing/WorksListing.tsx, src/components/SummarySearchMetrics/SummarySearchMetrics.tsx, src/components/MetricsDisplay/MetricsDisplay.tsx, src/components/MetricsDisplay/MetricsDisplay.module.scss
WorksListing gains vars?: QueryVar and showMetrics?: boolean and conditionally renders SummarySearchMetrics; SummarySearchMetrics computes displayWorksTotal from variables and forwards it; MetricsDisplay adds displayWorksTotal?: boolean to optionally hide "Works"; minor metrics spacing CSS changes.
Facets & tooltip UI
src/components/WorkFacets/WorkFacets.tsx, src/components/FacetList/FacetList.tsx, src/components/FacetList/FacetListItem.tsx, src/components/InfoTooltip/InfoTooltip.tsx
Add organization-relation-type facet and render clients/repository facets; introduce shared InfoTooltip component; FacetList/FacetListItem accept and render tooltipText; FacetListItem switches to programmatic router.push with click/keyboard handlers.
Dashboard & styling
src/components/WorksDashboard/WorksDashboard.tsx, src/components/WorksDashboard/WorksDashboard.module.scss, src/components/MetricsDisplay/MetricsDisplay.module.scss
Remove .graphsContainer rule and replace usage with utility classes (mt-5 mb-5); adjust metrics spacing/padding.
Pagination / search params in other apps
src/app/(main)/doi.org/[...doi]/mapSearchParams.ts, src/app/(main)/doi.org/page.tsx, src/app/(main)/orcid.org/[orcid]/mapSearchParams.ts
Add clientId mapping from searchParams['client-id'] to variables and include it where SearchWork vars are built.
Query facets & constants
src/data/queries/searchDoiFacetsQuery.ts, src/data/constants.ts
Include clients in convertToQueryData output (sliced to 10) and add 'clients' to FACETS.DEFAULT.
Tests & misc
cypress/e2e/searchWork.test.ts, package.json
Adjust facet label assertions for reordering; bump next from 15.4.8 to 15.4.10.

Sequence Diagram(s)

sequenceDiagram
    actor Browser
    participant mapSP as mapSearchParams
    participant Page as ROR Page
    participant Related as RelatedContent
    participant Works as WorksListing
    participant Query as searchDoiQuery
    participant API as Data/API
    participant Metrics as SummarySearchMetrics/MetricsDisplay

    Browser->>mapSP: request URL + search params (organization-relation-type, client-id)
    mapSP-->>Page: return variables (organizationRelationType, clientId, ...)
    Page->>Related: render RelatedContent with rorId
    Related->>Related: build vars (exclude rorFundingIds) and compute showMetrics
    Related->>Works: pass vars + showMetrics
    Works->>Query: buildQuery using rorId + variables.organizationRelationType
    alt relation-specific fragment
        Query->>Query: construct chosen relation fragment (fundedBy / createdBy / affiliatedResearchers / default union)
    end
    Query->>API: execute constructed query
    API-->>Works: return works/results (+ meta.clients)
    Works->>Metrics: if showMetrics then render SummarySearchMetrics with vars
    Metrics->>Metrics: set displayWorksTotal based on variables and render MetricsDisplay
    Works->>Works: render works/results UI
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

Possibly related PRs

Suggested reviewers

  • jrhoads
  • bklaing2

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check ❓ Inconclusive The PR title 'Funded by' is vague and does not clearly convey the main changes; it is overly broad and lacks specificity about what functionality is being added. Consider a more descriptive title that captures the primary feature, such as 'Add organization relation type filtering for ROR pages' or 'Implement organization-relation-type query support'.
✅ Passed checks (1 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2881ddd and 5d7c10a.

📒 Files selected for processing (1)
  • src/components/WorkFacets/WorkFacets.tsx
🧰 Additional context used
🧬 Code graph analysis (1)
src/components/WorkFacets/WorkFacets.tsx (4)
src/data/types.ts (1)
  • Facet (326-331)
src/components/FacetList/FacetList.tsx (1)
  • FacetList (25-52)
src/data/clients/ror-v2-client.ts (1)
  • RORFacet (85-89)
src/data/queries/searchOrganizationQuery.ts (2)
  • convertRORTypeFacet (205-211)
  • convertRORCountriesFacet (197-203)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: test / cypress (2)
  • GitHub Check: test / cypress (4)
  • GitHub Check: test / cypress (5)
  • GitHub Check: test / cypress (3)
  • GitHub Check: test / cypress (1)
🔇 Additional comments (5)
src/components/WorkFacets/WorkFacets.tsx (5)

60-67: Past review comments already cover this segment.

The hardcoded counts and missing data source have been flagged in previous reviews.


70-70: LGTM!

The isOrganizationRelationTypeSet check follows the same pattern as the existing isConnectionTypeSet on line 69 and is correctly implemented.


83-85: Good additions to defaultActiveKeys.

The new facet keys for repository-related and organization-relation-type facets are correctly added to ensure they expand by default.

Note: The typo on line 82 ("conection-type-facets") was already flagged in previous reviews.


107-117: Past review comments already cover this segment.

The URL validation vulnerability and other concerns have been flagged in previous reviews as critical issues.


172-193: I do not have a review comment to rewrite. Please provide the review comment within <review_comment> tags along with the code context and any verification results needed to complete the task.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (4)
src/components/SummarySearchMetrics/SummarySearchMetrics.tsx (1)

38-48: Potential logic mismatch: displayWorksTotal will be false when organizationRelationType defaults to 'allRelated'.

If 'allRelated' is meant to behave like “no special filter”, consider aligning semantics, e.g. treat only specific relation filters as the signal:

-  const displayWorksTotal = !variables.organizationRelationType
+  const displayWorksTotal =
+    !variables.organizationRelationType || variables.organizationRelationType === 'allRelated'
src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (1)

1-30: Fix SearchParams typing: missing "repository-type" and "organization-relation-type" keys.

This file types searchParams, so indexing with undeclared keys should fail TS checks. Add the keys:

 export interface SearchParams {
   id: string
   filterQuery?: string
   cursor?: string
   contributor?: string
   published?: string
   "resource-type"?: string
   language?: string
   license?: string
   "field-of-science"?: string
   "registration-agency"?: string
+  "repository-type"?: string
+  "organization-relation-type"?: string
 
   isBot: string
 }
src/app/(main)/ror.org/[rorid]/page.tsx (1)

1-62: Pass the isBot prop to RelatedContent to ensure bot traffic doesn't load related works data. Currently, isBot defaults to false across all page renders, making the bot-detection check in RelatedContent non-functional. Without this prop, search engines and crawlers will fetch and render the full related works list. The useSearchParams() usage and metrics logic are correct.

src/components/MetricsDisplay/MetricsDisplay.tsx (1)

16-27: links is optional but dereferenced—can crash at runtime / violates TS intent.

links?: { ... } but metricsData uses links.works etc. This should be links?.works (same for others), or make links required.

   const metricsData = [
     {
       "label": "Works",
       "count": counts.works,
-      "link": links.works
+      "link": links?.works
     },
     {
       "label": "Citations",
       "count": counts.citations,
-      "link": links.citations
+      "link": links?.citations
     },
     {
       "label": "Views",
       "count": counts.views,
-      "link": links.views
+      "link": links?.views
     },
     {
       "label": "Downloads",
       "count": counts.downloads,
-      "link": links.downloads
+      "link": links?.downloads
     }
   ];

Also applies to: 28-57

🧹 Nitpick comments (3)
src/components/WorksDashboard/WorksDashboard.tsx (1)

43-45: Prefer plain string + verify layout parity after removing the CSS-module container styles.

className={'mt-5 mb-5'} can be simplified to className="mt-5 mb-5". More importantly, since this replaces the old graphsContainer CSS-module styling, please verify there’s no regression in chart spacing/wrapping across breakpoints (xs/sm) and in the OrganizationDashboard embedding case.

-    <div className={'mt-5 mb-5'}>
+    <div className="mt-5 mb-5">
src/data/queries/searchDoiQuery.ts (2)

13-35: Tighten organizationRelationType to a union type (avoid “stringly-typed” switch).

Right now any string will fall into default, which can mask invalid values coming from routing/UI. Consider exporting a shared union type and using it in both QueryVar and buildOrgQuery.

-function buildOrgQuery(rorId: string | undefined, organizationRelationType: string | undefined): string {
+export type OrganizationRelationType =
+  | 'allRelated'
+  | 'fundedBy'
+  | 'createdContributedOrPublishedBy'
+  | 'createdOrContributedByAffiliatedResearcher'
+  | 'connectedToOrganizationOMPs'
+
+function buildOrgQuery(
+  rorId: string | undefined,
+  organizationRelationType: OrganizationRelationType | undefined
+): string {

226-243: Update QueryVar.organizationRelationType to the shared union type.

 export interface QueryVar {
   query?: string
   filterQuery?: string
   rorId?: string,
-  organizationRelationType?: string,
+  organizationRelationType?: OrganizationRelationType,
   userId?: string
   clientId?: string
   cursor?: string
   contributor?: string
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9a15f49 and 89f7c5f.

📒 Files selected for processing (16)
  • src/app/(main)/ror.org/[rorid]/Content.tsx (1 hunks)
  • src/app/(main)/ror.org/[rorid]/RelatedContent.tsx (2 hunks)
  • src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (1 hunks)
  • src/app/(main)/ror.org/[rorid]/page.tsx (2 hunks)
  • src/components/FacetList/FacetList.tsx (2 hunks)
  • src/components/FacetList/FacetListItem.tsx (3 hunks)
  • src/components/InfoTooltip/InfoTooltip.tsx (1 hunks)
  • src/components/MetricsDisplay/MetricsDisplay.module.scss (2 hunks)
  • src/components/MetricsDisplay/MetricsDisplay.tsx (2 hunks)
  • src/components/SummarySearchMetrics/SummarySearchMetrics.tsx (1 hunks)
  • src/components/WorkFacets/WorkFacets.tsx (4 hunks)
  • src/components/WorksDashboard/WorksDashboard.module.scss (0 hunks)
  • src/components/WorksDashboard/WorksDashboard.tsx (1 hunks)
  • src/components/WorksListing/WorksListing.tsx (3 hunks)
  • src/data/queries/searchDoiQuery.ts (2 hunks)
  • src/data/types.ts (1 hunks)
💤 Files with no reviewable changes (1)
  • src/components/WorksDashboard/WorksDashboard.module.scss
🧰 Additional context used
🧬 Code graph analysis (10)
src/components/SummarySearchMetrics/SummarySearchMetrics.tsx (1)
src/components/MetricsDisplay/MetricsDisplay.tsx (1)
  • MetricsDisplay (26-65)
src/data/types.ts (3)
src/components/SankeyGraph/SankeyGraph.tsx (1)
  • facet (25-42)
src/components/OrganizationDashboard/OrganizationDashboard.tsx (1)
  • ContentFacet (12-16)
src/data/clients/ror-v2-client.ts (1)
  • RORFacet (85-89)
src/app/(main)/ror.org/[rorid]/RelatedContent.tsx (1)
src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (1)
  • mapSearchparams (16-34)
src/components/WorkFacets/WorkFacets.tsx (3)
src/data/types.ts (1)
  • Facet (325-330)
src/components/FacetList/FacetList.tsx (1)
  • FacetList (25-52)
src/data/queries/searchOrganizationQuery.ts (2)
  • convertRORTypeFacet (205-211)
  • convertRORCountriesFacet (197-203)
src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (3)
src/app/(main)/repositories/[...repoid]/mapSearchParams.ts (2)
  • mapSearchparams (16-33)
  • SearchParams (1-14)
src/app/(main)/orcid.org/[orcid]/mapSearchParams.ts (2)
  • mapSearchparams (15-31)
  • SearchParams (1-13)
src/app/(main)/doi.org/[...doi]/mapSearchParams.ts (2)
  • mapSearchparams (17-34)
  • SearchParams (1-15)
src/app/(main)/ror.org/[rorid]/page.tsx (1)
src/app/(main)/ror.org/[rorid]/RelatedContent.tsx (1)
  • RelatedContent (22-77)
src/components/InfoTooltip/InfoTooltip.tsx (1)
src/components/HelpIcon/HelpIcon.tsx (1)
  • Icon (23-36)
src/components/FacetList/FacetListItem.tsx (2)
src/data/types.ts (1)
  • Facet (325-330)
src/components/InfoTooltip/InfoTooltip.tsx (1)
  • InfoTooltip (11-24)
src/data/queries/searchDoiQuery.ts (1)
src/data/queries/searchOrganizationQuery.ts (1)
  • QueryVar (278-283)
src/components/MetricsDisplay/MetricsDisplay.tsx (2)
src/components/MetricsCounter/MetricsCounter.tsx (1)
  • MetricsCounter (13-44)
src/components/RepositoryDetail/RepositoryDetail.tsx (1)
  • Metrics (23-33)
🪛 GitHub Check: CodeQL
src/components/WorkFacets/WorkFacets.tsx

[failure] 105-105: Incomplete URL substring sanitization
'ror.org/' can be anywhere in the URL, and arbitrary hosts may come before or after it.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: test / cypress (3)
  • GitHub Check: test / cypress (4)
🔇 Additional comments (5)
src/components/MetricsDisplay/MetricsDisplay.module.scss (1)

1-25: SCSS changes look safe for layout (padding/centering only).

src/components/FacetList/FacetList.tsx (1)

8-47: Good centralization of tooltip UX; just ensure InfoTooltip a11y fix lands.

src/data/types.ts (1)

325-334: [rewritten comment]
[classification tag]

src/data/queries/searchDoiQuery.ts (1)

39-54: Inconsistent quoting on line 20 may cause unintended query behavior. The organization_id field uses an unquoted ROR format (ror.org/02k3smh20) while the provider.ror_id field uses a quoted URL ("https://ror.org/02k3smh20"). This inconsistency within the same clause could produce incorrect Elasticsearch results if the backend requires consistent formatting. Additionally, these field names (funder_rors, provider.ror_id, organization_id, affiliation_id, related_dmp_organization_id) do not appear in DataCite's public API documentation; verify with backend Elasticsearch mappings that these fields are correct and accept the mixed quoting patterns used here.

src/components/WorkFacets/WorkFacets.tsx (1)

59-70: Brittle url?.includes('ror.org/') gate (CodeQL) + duplicate facet titles.

  • Line 105: The substring check can be accidentally true for unintended URLs; prefer a stricter predicate like url?.startsWith('/ror.org/') or pass an explicit isRorPage boolean from the route layer.
  • Lines 96 and 108: Both FacetList components use the title "Connection Types", creating duplicate headers. The second should be "Organization Relationships" or similar to clarify the distinction.

Example tightening for line 105-108:

-      {url?.includes('ror.org/') && (
+      {url?.startsWith('/ror.org/') && (
         <FacetList
           data={organizationRelationTypeList}
-          title="Connection Types"
+          title="Organization Relationships"
           id="organization-relation-type-facets"
           param="organization-relation-type"
           url={url}
           checked={(i) => !isOrganizationRelationTypeSet && i == 0}
           radio
         />
       )}

Also: defaultActiveKeys (line 72–84) contains a typo on line 81: "conection-type-facets" (missing 'n') does not match any rendered FacetList id and makes accordion defaults harder to reason about. Remove or correct to "connection-type-facets".

Likely an incorrect or invalid review comment.

Comment on lines +23 to 32
const { isBot = false, rorId } = props

const searchParams = useSearchParams()
const { variables } = mapSearchparams(Object.fromEntries(searchParams.entries()) as any)

const vars = { rorId, rorFundingIds, ...variables }
const vars = { rorId, ...variables }
const { loading, data, error } = useOrganizationRelatedContentQuery(vars)

const showMetrics = Boolean(vars.organizationRelationType && vars.organizationRelationType !== 'allRelated')

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

git ls-files | grep -E "(tsx|ts)$" | grep -i "ror" | head -20

Repository: datacite/akita

Length of output: 517


🏁 Script executed:

fd . -type f -name "*.tsx" | head -30

Repository: datacite/akita

Length of output: 228


🏁 Script executed:

find . -type f -name "*.tsx" 2>/dev/null | wc -l

Repository: datacite/akita

Length of output: 61


🏁 Script executed:

find . -path "*ror.org*" -type f 2>/dev/null | head -30

Repository: datacite/akita

Length of output: 282


🏁 Script executed:

find . -path "*RelatedContent*" -type f 2>/dev/null

Repository: datacite/akita

Length of output: 476


🏁 Script executed:

rg "const { isBot = false, rorId }" -t tsx -t ts -A 10

Repository: datacite/akita

Length of output: 178


🏁 Script executed:

cat -n src/app/\(main\)/ror.org/\[rorid\]/RelatedContent.tsx | head -80

Repository: datacite/akita

Length of output: 2873


🏁 Script executed:

wc -l src/app/\(main\)/ror.org/\[rorid\]/RelatedContent.tsx

Repository: datacite/akita

Length of output: 110


🏁 Script executed:

sed -n '1,80p' src/app/\(main\)/ror.org/\[rorid\]/RelatedContent.tsx | cat -n

Repository: datacite/akita

Length of output: 2873


🏁 Script executed:

head -80 "src/app/(main)/ror.org/[rorid]/RelatedContent.tsx" | cat -n

Repository: datacite/akita

Length of output: 2873


🏁 Script executed:

find . -name "WorksListing*" -type f | head -10

Repository: datacite/akita

Length of output: 104


🏁 Script executed:

cat -n src/app/\(main\)/ror.org/\[rorid\]/mapSearchParams.ts

Repository: datacite/akita

Length of output: 1279


🏁 Script executed:

fd WorksListing --extension tsx --extension ts | head -5

Repository: datacite/akita

Length of output: 102


🏁 Script executed:

head -100 "src/app/(main)/ror.org/[rorid]/mapSearchParams.ts"

Repository: datacite/akita

Length of output: 1027


🏁 Script executed:

wc -l src/components/WorksListing/WorksListing.tsx

Repository: datacite/akita

Length of output: 106


🏁 Script executed:

head -150 src/components/WorksListing/WorksListing.tsx | cat -n

Repository: datacite/akita

Length of output: 4378


🏁 Script executed:

find . -name "SummarySearchMetrics*" -type f

Repository: datacite/akita

Length of output: 120


🏁 Script executed:

head -80 src/components/SummarySearchMetrics/SummarySearchMetrics.tsx | cat -n

Repository: datacite/akita

Length of output: 1956


🏁 Script executed:

grep -n "if (!data) return" src/app/\(main\)/*/\[*\]/RelatedContent.tsx

Repository: datacite/akita

Length of output: 361


Fix if (!data) return to return null explicitly in RelatedContent components.

Line 44 returns undefined implicitly; React components should explicitly return null. This same pattern exists in the other three RelatedContent files (orcid.org, doi.org, and repositories).

The vars shape is correctly formed—mapSearchParams ensures organizationRelationType is present (defaulting to 'allRelated'), and it's properly spread into SummarySearchMetrics which expects it.

🤖 Prompt for AI Agents
In src/app/(main)/ror.org/[rorid]/RelatedContent.tsx around lines 23-32 (and
similarly update the other three RelatedContent files for orcid.org, doi.org,
and repositories), the component currently does "if (!data) return" which
returns undefined; change this to "if (!data) return null" so the React
component explicitly returns null when no data is available; ensure the same
explicit null return is applied at the early-return site (around line ~44) in
each RelatedContent file.

Comment on lines 17 to 24
import SummarySearchMetrics from '../SummarySearchMetrics/SummarySearchMetrics'
import { SearchParams } from 'next/dist/server/request/search-params'

interface Props {
works: Works
vars: SearchParams
showMetrics?: boolean
showAnalytics: boolean
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's find and read the WorksListing.tsx file
find . -type f -name "WorksListing.tsx" | head -5

Repository: datacite/akita

Length of output: 104


🏁 Script executed:

# Also find SummarySearchMetrics component
find . -type f -name "*SummarySearchMetrics*" | head -10

Repository: datacite/akita

Length of output: 120


🏁 Script executed:

cat -n ./src/components/WorksListing/WorksListing.tsx

Repository: datacite/akita

Length of output: 4378


🏁 Script executed:

cat -n ./src/components/SummarySearchMetrics/SummarySearchMetrics.tsx

Repository: datacite/akita

Length of output: 1956


🏁 Script executed:

# Search for QueryVar type definition
rg -A 10 "type QueryVar" --type ts --type tsx

Repository: datacite/akita

Length of output: 85


🏁 Script executed:

# Also check what SearchParams type actually is
rg -B 5 -A 10 "type SearchParams\|interface SearchParams" --type ts --type tsx

Repository: datacite/akita

Length of output: 85


🏁 Script executed:

# Search for QueryVar without type flag
rg "type QueryVar|export.*QueryVar" src/data/queries/

Repository: datacite/akita

Length of output: 4163


🏁 Script executed:

# Find and read the searchDoiQuery file
find . -name "searchDoiQuery*" -type f

Repository: datacite/akita

Length of output: 94


🏁 Script executed:

# Read the searchDoiQuery file to see QueryVar definition
head -100 ./src/data/queries/searchDoiQuery.ts

Repository: datacite/akita

Length of output: 4344


🏁 Script executed:

# Search for the QueryVar interface definition specifically
rg -A 30 "export interface QueryVar" ./src/data/queries/searchDoiQuery.ts

Repository: datacite/akita

Length of output: 853


🏁 Script executed:

# Search for all usages of SummarySearchMetrics in the codebase
rg "SummarySearchMetrics" --no-heading -B 2 -A 2

Repository: datacite/akita

Length of output: 2975


🏁 Script executed:

# Check what SearchParams type is from Next.js
rg "SearchParams" --no-heading -B 2 -A 5

Repository: datacite/akita

Length of output: 34209


🏁 Script executed:

grep -B 5 -A 5 "SummarySearchMetrics rorId" ./src/app/\(main\)/ror.org/\[rorid\]/Content.tsx

Repository: datacite/akita

Length of output: 472


🏁 Script executed:

# Let me also check the exact imports and how SearchParams is being used
head -30 ./src/app/\(main\)/page.tsx

Repository: datacite/akita

Length of output: 835


🏁 Script executed:

# Find where WorksListing is being called to see what type is passed for vars
rg -B 5 -A 5 "WorksListing" src/app --no-heading | head -80

Repository: datacite/akita

Length of output: 6774


🏁 Script executed:

# Check if there are any TypeScript errors being reported
# Let's look at one of the calling sites more carefully
cat -n ./src/app/\(main\)/repositories/\[...\repoid\]/RelatedContent.tsx | head -60

Repository: datacite/akita

Length of output: 2299


🏁 Script executed:

# Let's see the complete ROR RelatedContent.tsx to see how vars is passed to WorksListing
cat -n ./src/app/\(main\)/ror.org/\[rorid\]/RelatedContent.tsx | head -100

Repository: datacite/akita

Length of output: 2873


🏁 Script executed:

# Also check the mapSearchParams to understand the vars type better
cat -n ./src/app/\(main\)/ror.org/\[rorid\]/mapSearchParams.ts

Repository: datacite/akita

Length of output: 1279


Replace internal Next.js import with local type; pass vars as single prop to SummarySearchMetrics instead of spreading.

import { SearchParams } from 'next/dist/server/request/search-params' imports from Next.js internal API, which is unstable. The actual vars passed at call sites (e.g., line 64 in ror.org/[rorid]/RelatedContent.tsx) is a constructed object like { rorId, ...variables }, not Next.js's SearchParams type.

Additionally, <SummarySearchMetrics {...vars} /> spreads individual props, but SummarySearchMetrics expects a single variables parameter of type QueryVar. The spread pattern works at runtime but is misleading and inconsistent with other call sites (e.g., SummarySearchMetrics rorId={...}).

Replace with:

-import { SearchParams } from 'next/dist/server/request/search-params'
+type SearchParamsLike = Record<string, string | string[] | undefined>

 interface Props {
   works: Works
-  vars: SearchParams
+  vars: SearchParamsLike
   showMetrics?: boolean
   ...
 }

 ...
-          <SummarySearchMetrics {...vars}/>
+          <SummarySearchMetrics variables={vars} />

Also applies to: 39-56, 82-85

🤖 Prompt for AI Agents
In src/components/WorksListing/WorksListing.tsx around lines 17-24 (and also
adjust usages in ranges 39-56 and 82-85), the component imports Next.js internal
SearchParams and spreads vars into SummarySearchMetrics; replace the internal
import with the local QueryVar type (or the correct local type used elsewhere),
change the Props signature to declare vars: QueryVar (or the appropriate local
type), and update the SummarySearchMetrics call to pass the vars object as a
single prop (e.g., variables={vars}) instead of spreading {...vars}; ensure any
other occurrences in the specified ranges follow the same pattern so types and
prop names match SummarySearchMetrics.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
src/components/WorkFacets/WorkFacets.tsx (1)

105-105: Incomplete URL substring sanitization.

The url?.includes('ror.org/') check is vulnerable to URL manipulation. As noted by CodeQL, this substring can appear anywhere in a malicious URL (e.g., https://evil.com/ror.org/ or https://ror.org.evil.com/path).

Consider using a more robust check:

-      {url?.includes('ror.org/') && (
+      {url?.startsWith('ror.org/') && (

Or if the URL may include a protocol prefix:

const isRorOrgUrl = (url: string) => {
  try {
    const parsed = new URL(url.startsWith('http') ? url : `https://${url}`)
    return parsed.hostname === 'ror.org' || parsed.hostname.endsWith('.ror.org')
  } catch {
    return url.startsWith('ror.org/')
  }
}
🧹 Nitpick comments (1)
src/components/WorkFacets/WorkFacets.tsx (1)

72-84: Pre-existing typo in defaultActiveKeys.

The new additions look correct. However, note that line 81 has a pre-existing typo: "conection-type-facets" is missing an 'n' (should match "connection-type-facets" from line 74). Consider fixing this while you're modifying the array.

     "field-of-science-facets",
     "registration-agency-facets",
-    "conection-type-facets",
+    "connection-type-facets",
     "repository-type-facets",
     "organization-relation-type-facets"
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4000c26 and ce03ff0.

📒 Files selected for processing (4)
  • src/components/FacetList/FacetListItem.tsx (3 hunks)
  • src/components/MetricsDisplay/MetricsDisplay.tsx (1 hunks)
  • src/components/WorkFacets/WorkFacets.tsx (4 hunks)
  • src/data/types.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
  • src/components/MetricsDisplay/MetricsDisplay.tsx
  • src/components/FacetList/FacetListItem.tsx
  • src/data/types.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/components/WorkFacets/WorkFacets.tsx (3)
src/data/types.ts (1)
  • Facet (325-330)
src/components/FacetList/FacetList.tsx (1)
  • FacetList (25-52)
src/data/queries/searchOrganizationQuery.ts (2)
  • convertRORTypeFacet (205-211)
  • convertRORCountriesFacet (197-203)
🪛 GitHub Check: CodeQL
src/components/WorkFacets/WorkFacets.tsx

[failure] 105-105: Incomplete URL substring sanitization
'ror.org/' can be anywhere in the URL, and arbitrary hosts may come before or after it.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: test / cypress (3)
  • GitHub Check: test / cypress (4)
  • GitHub Check: test / cypress (5)
  • GitHub Check: test / cypress (2)
  • GitHub Check: test / cypress (1)
🔇 Additional comments (3)
src/components/WorkFacets/WorkFacets.tsx (3)

59-66: LGTM - Static facet options with tooltips.

The static facet list for organization relation types is well-structured. The count: 0 values are appropriate since these are filter options rather than dynamically counted facets. The tooltips provide helpful context for users.


68-69: LGTM - Consistent pattern for param detection.

The new isOrganizationRelationTypeSet follows the same pattern as the existing isConnectionTypeSet, maintaining consistency in how URL params are detected.


94-102: LGTM - Good defensive filtering.

Filtering out facets with zero or undefined counts is a sensible UX improvement, ensuring users only see actionable filter options.

@cypress
Copy link

cypress bot commented Dec 15, 2025

akita    Run #1829

Run Properties:  status check passed Passed #1829  •  git commit 99a1141086 ℹ️: Merge 5d7c10a973c8680c372f41e51eb0f78cfd80c685 into 5250c2ad365622db1b7c1f2c26d0...
Project akita
Branch Review funded-by
Run status status check passed Passed #1829
Run duration 01m 44s
Commit git commit 99a1141086 ℹ️: Merge 5d7c10a973c8680c372f41e51eb0f78cfd80c685 into 5250c2ad365622db1b7c1f2c26d0...
Committer codycooperross
View all properties for this run ↗︎

Test results
Tests that failed  Failures 0
Tests that were flaky  Flaky 0
Tests that did not run due to a developer annotating a test with .skip  Pending 3
Tests that did not run due to a failure in a mocha hook  Skipped 0
Tests that passed  Passing 47
View all changes introduced in this branch ↗︎

dependabot bot and others added 3 commits December 15, 2025 17:04
Bumps [next](https://github.com/vercel/next.js) from 15.4.8 to 15.4.9.
- [Release notes](https://github.com/vercel/next.js/releases)
- [Changelog](https://github.com/vercel/next.js/blob/canary/release.js)
- [Commits](vercel/next.js@v15.4.8...v15.4.9)

---
updated-dependencies:
- dependency-name: next
  dependency-version: 15.4.9
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [next](https://github.com/vercel/next.js) from 15.4.9 to 15.4.10.
- [Release notes](https://github.com/vercel/next.js/releases)
- [Changelog](https://github.com/vercel/next.js/blob/canary/release.js)
- [Commits](vercel/next.js@v15.4.9...v15.4.10)

---
updated-dependencies:
- dependency-name: next
  dependency-version: 15.4.10
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (2)
src/components/WorkFacets/WorkFacets.tsx (2)

106-114: Duplicate title issue remains unresolved from previous review.

Both the organization relation type facet (line 108) and the existing connection type facet (line 96) use the title "Connection Types". As noted in the previous review, this creates user confusion when both facets could appear in the interface.

The previous review suggested changing this to a distinct title like "Organization Relation" or "Work Relationship". Please address this feedback:

         <FacetList
           data={organizationRelationTypeList}
-          title="Connection Types"
+          title="Organization Relation"
           id="organization-relation-type-facets"

105-105: URL substring check is vulnerable to host confusion.

The condition url?.includes('ror.org/') will match any URL containing that substring, including malicious URLs like https://attacker.com/ror.org/ or https://ror.org.evil.com/. This could enable unintended facet display or bypass security checks.

Apply this fix to validate the URL properly:

-      {url?.includes('ror.org/') && (
+      {url?.startsWith('ror.org/') && (
         <FacetList

Or for more robust validation:

+      {(() => {
+        try {
+          const urlObj = new URL(url, 'https://example.com')
+          return urlObj.hostname === 'ror.org' || url?.startsWith('ror.org/')
+        } catch {
+          return url?.startsWith('ror.org/')
+        }
+      })() && (
         <FacetList
🧹 Nitpick comments (1)
src/components/MetricsDisplay/MetricsDisplay.tsx (1)

51-57: Refactor to filter before mapping instead of returning null.

The current implementation filters metrics by count, then returns null inside the map callback when hiding the Works metric. While React handles null gracefully, this pattern leaves null items in the array and is less maintainable than filtering beforehand.

Apply this diff to filter both conditions before mapping:

-  const metricList = metricsData.filter(metric => metric.count && metric.count > 0).map((metric, index) =>
-    metric.label === "Works" && !displayWorksTotal ? null :
+  const metricList = metricsData
+    .filter(metric => metric.count && metric.count > 0)
+    .filter(metric => !(metric.label === "Works" && !displayWorksTotal))
+    .map((metric, index) =>
     <React.Fragment key={"metric-" + index}>
       <dd>{compactNumbers(metric.count || 0)}</dd>
       <dt>{metric.label} <HelpIcon link={metric.link} size={20} position='inline' /></dt>
     </React.Fragment>
   )
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 64e55c8 and 6b003c7.

📒 Files selected for processing (2)
  • src/components/MetricsDisplay/MetricsDisplay.tsx (2 hunks)
  • src/components/WorkFacets/WorkFacets.tsx (3 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
src/components/WorkFacets/WorkFacets.tsx (3)
src/data/types.ts (1)
  • Facet (325-330)
src/components/FacetList/FacetList.tsx (1)
  • FacetList (25-52)
src/components/OrganizationDashboard/OrganizationDashboard.tsx (1)
  • ContentFacet (12-16)
src/components/MetricsDisplay/MetricsDisplay.tsx (2)
src/components/SummarySearchMetrics/SummarySearchMetrics.tsx (1)
  • SummarySearchMetrics (38-46)
src/components/RepositoryDetail/RepositoryDetail.tsx (1)
  • Metrics (23-33)
🪛 GitHub Check: CodeQL
src/components/WorkFacets/WorkFacets.tsx

[failure] 105-105: Incomplete URL substring sanitization
'ror.org/' can be anywhere in the URL, and arbitrary hosts may come before or after it.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: test / cypress (4)
  • GitHub Check: test / cypress (1)
  • GitHub Check: test / cypress (5)
  • GitHub Check: test / cypress (2)
  • GitHub Check: test / cypress (3)
🔇 Additional comments (5)
src/components/WorkFacets/WorkFacets.tsx (3)

69-69: LGTM!

The implementation correctly follows the existing pattern for isConnectionTypeSet on line 68.


82-83: LGTM!

The additions correctly register the facet IDs so they expand by default in the accordion.


59-66: This is not an incomplete implementation—organizationRelationTypeList serves a different purpose than connectionTypeList.

The organizationRelationType parameter is a static filter option (applied to the search query via buildOrgQuery()), not a result facet showing distribution. Unlike connectionTypeList which displays dynamic counts of works in each relationship type, organizationRelationTypeList provides a fixed set of filter choices with hardcoded zero counts by design. No filtering is needed because these are not result facets but UI options for users to narrow their search.

That said, the design pattern is potentially confusing: both are typed as Facet[] with count fields, yet used differently. Consider clarifying the distinction—either through naming (e.g., organizationRelationTypeFilters), documentation, or a separate type to distinguish static filter menus from dynamic result facets.

src/components/MetricsDisplay/MetricsDisplay.tsx (2)

22-24: LGTM!

The new optional prop follows TypeScript best practices and maintains backward compatibility.


26-26: LGTM!

The default value of true ensures backward compatibility for existing usages.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

♻️ Duplicate comments (1)
src/components/WorkFacets/WorkFacets.tsx (1)

108-108: Title change addresses previous review feedback.

The title has been updated from "Connection Types" to "Organization Relation Types", which resolves the duplicate title issue flagged in the previous review.

🧹 Nitpick comments (2)
src/components/FacetList/FacetListItem.tsx (1)

84-84: Consider conditionally rendering the entire span element.

When facet.count is 0, an empty <span> element is rendered. While harmless, it's cleaner to conditionally render the entire element.

Apply this diff:

-      <span>{facet.count > 0 && facet.count.toLocaleString('en-US')}</span>
+      {facet.count > 0 && <span>{facet.count.toLocaleString('en-US')}</span>}
src/components/WorkFacets/WorkFacets.tsx (1)

81-81: Pre-existing typo in defaultActiveKeys.

Line 81 contains a typo: "conection-type-facets" should be "connection-type-facets" (missing an 'n'). While this is not introduced by the current changes, fixing it would ensure the connection type facet expands by default as intended.

-    "conection-type-facets",
+    "connection-type-facets",
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6b003c7 and bfb83a9.

📒 Files selected for processing (4)
  • src/components/FacetList/FacetListItem.tsx (4 hunks)
  • src/components/MetricsDisplay/MetricsDisplay.module.scss (1 hunks)
  • src/components/WorkFacets/WorkFacets.tsx (3 hunks)
  • src/components/WorksListing/WorksListing.tsx (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/components/WorksListing/WorksListing.tsx
  • src/components/MetricsDisplay/MetricsDisplay.module.scss
🧰 Additional context used
🧬 Code graph analysis (2)
src/components/FacetList/FacetListItem.tsx (3)
src/data/types.ts (1)
  • Facet (325-330)
src/components/InfoTooltip/InfoTooltip.tsx (1)
  • InfoTooltip (11-24)
src/components/FacetList/FacetList.tsx (2)
  • FacetList (44-70)
  • FacetListProps (14-27)
src/components/WorkFacets/WorkFacets.tsx (4)
src/data/types.ts (1)
  • Facet (325-330)
src/components/FacetList/FacetList.tsx (1)
  • FacetList (25-52)
src/data/queries/searchOrganizationQuery.ts (2)
  • convertRORTypeFacet (205-211)
  • convertRORCountriesFacet (197-203)
src/data/clients/ror-v2-client.ts (1)
  • RORV2Organization (7-24)
🪛 GitHub Check: CodeQL
src/components/WorkFacets/WorkFacets.tsx

[failure] 105-105: Incomplete URL substring sanitization
'ror.org/' can be anywhere in the URL, and arbitrary hosts may come before or after it.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: test / cypress (3)
  • GitHub Check: test / cypress (5)
  • GitHub Check: test / cypress (2)
  • GitHub Check: test / cypress (4)
  • GitHub Check: test / cypress (1)
🔇 Additional comments (4)
src/components/FacetList/FacetListItem.tsx (4)

4-4: LGTM: Imports correctly support the new navigation and tooltip features.

The addition of useRouter for programmatic navigation and InfoTooltip for conditional tooltip rendering are appropriate for the refactored implementation.

Also applies to: 13-13


38-38: LGTM: Router initialization is correct for Next.js 15.

The useRouter hook from next/navigation is properly initialized and used for programmatic navigation in the handleClick handler.


59-68: LGTM: Event handlers correctly implement accessible navigation.

The handleClick uses router.push with scroll: false, which is appropriate for facet selection (prevents page scroll). The handleKeyDown handler properly supports Enter and Space keys with preventDefault(), following accessibility best practices for button-role elements.


19-19: No action required. The FacetList.tsx component properly passes tooltipText={facet.tooltipText} to FacetListItem, so the tooltip will render when the data is available.

Likely an incorrect or invalid review comment.

Comment on lines +72 to +78
<div
onClick={handleClick}
onKeyDown={handleKeyDown}
className={styles.facetlink}
role="button"
tabIndex={0}
>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major

Link removal resolves previous navigation issue, but add aria-pressed for toggle state.

Replacing the Link with a clickable div addresses the previous review concern about stopPropagation() not preventing Link navigation. The accessibility attributes (role="button", tabIndex={0}) are good, but the element represents a toggle/checkbox-like control. Add aria-pressed or aria-checked to indicate the checked state for screen readers.

Apply this diff to add the aria attribute:

     <div 
       onClick={handleClick}
       onKeyDown={handleKeyDown}
       className={styles.facetlink}
       role="button"
       tabIndex={0}
+      aria-pressed={params.get(param) == value}
     >

Based on past review comments, the Link removal resolves the stopPropagation navigation issue.

📝 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.

Suggested change
<div
onClick={handleClick}
onKeyDown={handleKeyDown}
className={styles.facetlink}
role="button"
tabIndex={0}
>
<div
onClick={handleClick}
onKeyDown={handleKeyDown}
className={styles.facetlink}
role="button"
tabIndex={0}
aria-pressed={params.get(param) == value}
>
🤖 Prompt for AI Agents
In src/components/FacetList/FacetListItem.tsx around lines 72 to 78, the
clickable div has role="button" and tabIndex but lacks an accessible state
indicator; add aria-pressed tied to the item's selected state (e.g.
aria-pressed={isSelected}) so screen readers know it’s a toggle. Ensure the prop
or local variable used (isSelected) is a boolean and add
aria-pressed={isSelected} to the div element.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)
src/app/(main)/orcid.org/[orcid]/mapSearchParams.ts (1)

1-13: Add missing property to SearchParams interface.

The SearchParams interface is missing the "client-id" property that is accessed on line 27. This creates a type safety gap.

Apply this diff to add the missing property:

 export interface SearchParams {
   filterQuery?: string
   cursor?: string
   contributor?: string
   published?: string
   "resource-type"?: string
   language?: string
   license?: string
   "field-of-science"?: string
   "registration-agency"?: string
+  "client-id"?: string
 
   isBot: string
 }
src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (1)

1-14: Add missing properties to SearchParams interface.

The SearchParams interface is missing properties that are accessed on lines 28-30: "client-id", "repository-type", and "organization-relation-type". This creates type safety gaps.

Apply this diff to add the missing properties:

 export interface SearchParams {
   id: string
   filterQuery?: string
   cursor?: string
   contributor?: string
   published?: string
   "resource-type"?: string
   language?: string
   license?: string
   "field-of-science"?: string
   "registration-agency"?: string
+  "client-id"?: string
+  "repository-type"?: string
+  "organization-relation-type"?: string
 
   isBot: string
 }
src/app/(main)/doi.org/[...doi]/mapSearchParams.ts (1)

1-15: Add missing property to SearchParams interface.

The SearchParams interface is missing the "client-id" property that is accessed on line 29. This creates a type safety gap.

Apply this diff to add the missing property:

 export interface SearchParams {
   id: string
   filterQuery?: string
   cursor?: string
   contributor?: string
   published?: string
   "resource-type"?: string
   language?: string
   license?: string
   "field-of-science"?: string
   "registration-agency"?: string
   "connection-type"?: string
+  "client-id"?: string
 
   isBot: string
 }
♻️ Duplicate comments (1)
src/components/WorkFacets/WorkFacets.tsx (1)

83-85: Note: Typo in line 82 affects defaultActiveKeys.

The typo "conection-type-facets" on line 82 (missing an 'n') means this facet key won't match the actual id="connection-type-facets" used on line 99, preventing the connection type facet from being expanded by default.

This was flagged in a previous review but bears repeating since it affects functionality. Apply this fix:

     "registration-agency-facets",
-    "conection-type-facets",
+    "connection-type-facets",
     "repository-type-facets",
🧹 Nitpick comments (1)
src/app/(main)/doi.org/[...doi]/mapSearchParams.ts (1)

29-29: Consider naming consistency: repositoryId vs clientId.

This file uses repositoryId while other mapSearchParams files (ORCID, ROR) use clientId for the same searchParams['client-id'] source. While domain-specific naming can be appropriate, ensure this inconsistency is intentional and doesn't cause confusion in downstream query handling.

Verify the naming convention used in the query layer:

#!/bin/bash
# Description: Check naming conventions for client/repository ID across queries

# Check usage of repositoryId vs clientId in query files
rg -n "\b(repositoryId|clientId)\b" --type=ts -g "src/data/queries/*" -C2
📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 95e408c and 6191795.

📒 Files selected for processing (8)
  • src/app/(main)/doi.org/[...doi]/mapSearchParams.ts (1 hunks)
  • src/app/(main)/doi.org/page.tsx (1 hunks)
  • src/app/(main)/orcid.org/[orcid]/mapSearchParams.ts (1 hunks)
  • src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (1 hunks)
  • src/components/WorkFacets/WorkFacets.tsx (5 hunks)
  • src/data/constants.ts (1 hunks)
  • src/data/queries/searchDoiFacetsQuery.ts (1 hunks)
  • src/data/types.ts (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/data/types.ts
🧰 Additional context used
🧬 Code graph analysis (6)
src/data/constants.ts (4)
src/data/clients/ror-v2-client.ts (1)
  • RORFacet (85-89)
src/components/FacetList/FacetList.tsx (1)
  • FacetListProps (14-27)
src/components/SankeyGraph/SankeyGraph.tsx (1)
  • facet (25-42)
src/data/queries/searchDoiQuery.ts (1)
  • appendFacets (39-46)
src/app/(main)/doi.org/[...doi]/mapSearchParams.ts (1)
src/app/(main)/repositories/[...repoid]/mapSearchParams.ts (2)
  • mapSearchparams (16-33)
  • SearchParams (1-14)
src/app/(main)/orcid.org/[orcid]/mapSearchParams.ts (2)
src/app/(main)/repositories/[...repoid]/mapSearchParams.ts (2)
  • mapSearchparams (16-33)
  • SearchParams (1-14)
src/data/queries/searchDoiQuery.ts (1)
  • appendFacets (39-46)
src/app/(main)/doi.org/page.tsx (1)
src/data/queries/searchDoiQuery.ts (2)
  • QueryVar (208-225)
  • appendFacets (39-46)
src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (2)
src/app/(main)/repositories/[...repoid]/mapSearchParams.ts (2)
  • mapSearchparams (16-33)
  • SearchParams (1-14)
src/app/(main)/ror.org/page.tsx (1)
  • SearchParams (11-13)
src/components/WorkFacets/WorkFacets.tsx (4)
src/data/types.ts (1)
  • Facet (326-331)
src/components/FacetList/FacetList.tsx (1)
  • FacetList (25-52)
src/data/clients/ror-v2-client.ts (1)
  • RORFacet (85-89)
src/data/queries/searchOrganizationQuery.ts (2)
  • convertRORTypeFacet (205-211)
  • convertRORCountriesFacet (197-203)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: test / cypress (3)
  • GitHub Check: test / cypress (5)
  • GitHub Check: test / cypress (2)
  • GitHub Check: test / cypress (4)
  • GitHub Check: test / cypress (1)
🔇 Additional comments (8)
src/app/(main)/doi.org/page.tsx (1)

24-25: LGTM! Client-related parameters correctly mapped.

The addition of clientType and clientId to the variables object is consistent with the QueryVar interface and aligns with the broader PR changes to support client/repository filtering.

src/app/(main)/ror.org/[rorid]/mapSearchParams.ts (1)

28-30: LGTM! Organization relation type parameters correctly mapped.

The addition of clientId, clientType, and organizationRelationType (with sensible default 'allRelated') aligns with the new organization relationship filtering feature. The default ensures the facet shows all related works when no specific filter is selected.

src/data/constants.ts (1)

77-77: LGTM! Clients facet added to default facets.

The addition of the 'clients' facet to the default facets list is consistent with the broader changes to support client/repository filtering. The placement near 'clientTypes' is logical and maintains related facets together.

src/data/queries/searchDoiFacetsQuery.ts (1)

38-38: LGTM! Clients facet data correctly mapped from backend.

The addition of clients: meta.clients?.slice(0, 10) follows the established pattern used for other facets (resourceTypes, languages, etc.). The optional chaining and 10-item limit are consistent with the codebase conventions.

src/components/WorkFacets/WorkFacets.tsx (3)

29-29: LGTM! Clients facet field added to interface.

The addition of clients?: Facet[] to the Facets interface properly supports the new repository facet data flow and aligns with the changes in the data layer.


70-70: LGTM! Organization relation type state check added.

The isOrganizationRelationTypeSet check follows the same pattern as isConnectionTypeSet and enables proper default selection behavior for the new facet.


172-192: Well-structured repository facets rendering.

The conditional rendering of Repository and Repository Type facets when not on /repositories pages is logical and prevents redundant filtering. The addition of tooltipText for both facets ("The DataCite Repository where a DOI is stored" and "The type of DataCite Repository where a DOI is stored") provides helpful user guidance.

The use of data.clients for the repository facet properly connects to the new clients data flow introduced in this PR.

src/app/(main)/orcid.org/[orcid]/mapSearchParams.ts (1)

27-27: clientId parameter is correctly used as optional DataCite API filter, not an ORCID API parameter.

The clientId extracted from searchParams['client-id'] is passed to DataCite API queries (via searchDoiQuery.ts) as an optional repository/client filter for DOI results, not to ORCID API endpoints. This implementation is correct and aligns with DataCite API expectations for filtering works by DataCite client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants