Skip to content

Conversation

@bjorntore
Copy link
Contributor

@bjorntore bjorntore commented Nov 27, 2025

Description

In this app lib PR I'm adding support for a taskId query param to the SingingController endpoints, so that we can use it to create a summary2 of the SigneeList component in another task than the original signing task.

This PR starts passing the taskOverrides taskId to the backend.

If tests are needed, I'd love some help.

Test/QA

  • Manual functionality testing
    • I have tested these changes manually
    • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
    • No testing done/necessary
  • Automated tests
    • Unit test(s) have been added/updated
    • Cypress E2E test(s) have been added/updated
    • No automatic tests are needed here (no functional changes/additions)
    • I want someone to help me make some tests
  • UU/WCAG (follow these guidelines until we have our own)
    • I have tested with a screen reader/keyboard navigation/automated wcag validator
    • No testing done/necessary (no DOM/visual changes)
    • I want someone to help me perform accessibility testing
  • User documentation @ altinn-studio-docs
    • Has been added/updated
    • No functionality has been changed/added, so no documentation is needed
    • I will do that later/have created an issue
  • Support in Altinn Studio
    • Issue(s) created for support in Studio
    • This change/feature does not require any changes to Altinn Studio
  • Sprint board
    • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
    • I don't have permissions to do that, please help me out
  • Labels
    • I have added a kind/* and backport* label to this PR for proper release notes grouping
    • I don't have permissions to add labels, please help me out

Summary by CodeRabbit

  • New Features

    • Signee list now displays in alphabetical order by name for improved readability.
  • Refactor

    • Enhanced task ID resolution logic to support flexible configuration options.

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

@bjorntore bjorntore added kind/bug Something isn't working backport-ignore This PR is a new feature and should not be cherry-picked onto release branches labels Nov 27, 2025
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 27, 2025

📝 Walkthrough

Walkthrough

The changes introduce taskId resolution logic allowing override-driven behavior via context. TaskId is now retrieved from TaskOverrides context with a fallback to query parameters, then passed to the fetchSigneeList function. The API function signature is expanded to accept an optional taskId parameter, conditionally appending it to the URL, and results are sorted alphabetically by signee name.

Changes

Cohort / File(s) Summary
TaskId resolution with context override
src/layout/SigneeList/SigneeListSummary.tsx
Imports useTaskOverrides hook, retrieves taskId from TaskOverrides context, and passes a resolved taskId (with fallback to query parameter) as third argument to useSigneeList
API function signature expansion and sorting
src/layout/SigneeList/api.ts
Expands fetchSigneeList function signature to accept optional taskId parameter; conditionally appends taskId query parameter to API URL; adds sorting of returned signee states by name using toSorted() with null-safe localeCompare; updates query function to pass taskId when all parameters are present, otherwise uses skipToken

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Requires verification that the TaskOverrides context integration and fallback chain logic are correctly implemented
  • Confirm that all callers of fetchSigneeList have been updated to pass taskId where applicable
  • Validate that the sorting behavior (null-safe name comparison) produces expected results across all test cases

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.
Description check ❓ Inconclusive The PR description covers the main context and objective but is incomplete. The author provides a clear explanation of the purpose and references the related backend PR, but does not select any checkboxes for testing, documentation, or labels—all sections that are marked as required or informative in the template. Select appropriate checkboxes in the Verification/QA, User documentation, Support in Altinn Studio, Sprint board, and Labels sections to complete the PR submission and clarify testing status and release notes categorization.
✅ Passed checks (1 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the main change: enabling the signee list form to work in Summary2 when in a different task, which aligns with the PR's objective of supporting taskId override for cross-task signee list display.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/make-signee-list-work-in-pdf-service-task

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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.

@bjorntore bjorntore added kind/product-feature Pull requests containing new features and removed kind/bug Something isn't working labels Nov 27, 2025
@bjorntore
Copy link
Contributor Author

Feel free to adjust the code yourselves if you want. I'm way out of my comfort zone.

@bjorntore
Copy link
Contributor Author

/publish

@github-actions
Copy link
Contributor

github-actions bot commented Nov 27, 2025

PR release:

  • <link rel="stylesheet" type="text/css" href="https://altinncdn.no/toolkits/altinn-app-frontend/4.23.1-pr.3166.make-signee-list-work-in-pdf-service-task.c4842d1d/altinn-app-frontend.css">
  • <script src="https://altinncdn.no/toolkits/altinn-app-frontend/4.23.1-pr.3166.make-signee-list-work-in-pdf-service-task.c4842d1d/altinn-app-frontend.js"></script>

⚙️ Building...
✅ Done!

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 (1)
src/layout/SigneeList/api.ts (1)

34-43: Based on my verification, I can now provide the rewritten review comment:

taskId requirement in query gate is unnecessarily strict and breaks existing tests.

The signingQueries.signeeList requires all three values to be truthy before executing:

queryFn: partyId && instanceGuid && taskId ? () => fetchSigneeList(...) : skipToken,

However, fetchSigneeList accepts taskId as optional (line 45), and the backend endpoint supports calls without it (using a default task). The test suite calls fetchSigneeList(partyId, instanceGuid) without taskId and expects success (lines 40, 75, 94, 101, 130 in api.test.ts).

This creates a regression: when rendering SigneeListSummary without a task override, the query won't execute even though the backend can handle it.

Relax the query gate to match the function signature:

-      queryFn: partyId && instanceGuid && taskId ? () => fetchSigneeList(partyId, instanceGuid, taskId) : skipToken,
+      queryFn:
+        partyId && instanceGuid
+          ? () => fetchSigneeList(partyId, instanceGuid, taskId)
+          : skipToken,
🧹 Nitpick comments (3)
src/layout/SigneeList/SigneeListSummary.tsx (1)

12-32: Safer task override handling and interaction with taskId‑gated query

The override/fallback chain taskIdFromTaskOverrides ?? taskIdFromQuery is clear and matches the PR goal, but there are two things to double‑check:

  1. Context safety
    If useTaskOverrides() can ever return null/undefined (e.g., component rendered outside the provider or a nullable default in createContext), the destructuring on Line 27 will throw. A more defensive pattern avoids that:
-  const { taskId: taskIdFromTaskOverrides } = useTaskOverrides();
+  const taskOverrides = useTaskOverrides();
+  const taskIdFromTaskOverrides = taskOverrides?.taskId;
  1. Behavior when no taskId exists
    With the updated query logic in signingQueries.signeeList, the query will only run when taskId is truthy. If there are any flows where SigneeListSummary previously worked without a taskId (backend using a default task), those will now silently stop fetching data. Please confirm that SigneeListSummary is only used in contexts where either the route param or taskOverrides.taskId is always defined; otherwise you may want to let the query run without a taskId and let the backend pick the default.
src/layout/SigneeList/api.ts (2)

45-50: URL‑encode taskId when constructing the signing endpoint URL

When appending the taskId as a query parameter, it’s safer to URL‑encode it in case the ID ever contains characters that need escaping:

-export async function fetchSigneeList(partyId: string, instanceGuid: string, taskId?: string): Promise<SigneeState[]> {
-  let url = `${appPath}/instances/${partyId}/${instanceGuid}/signing`;
-
-  if (taskId) {
-    url = url.concat(`?taskId=${taskId}`);
-  }
+export async function fetchSigneeList(partyId: string, instanceGuid: string, taskId?: string): Promise<SigneeState[]> {
+  let url = `${appPath}/instances/${partyId}/${instanceGuid}/signing`;
+
+  if (taskId) {
+    url = `${url}?taskId=${encodeURIComponent(taskId)}`;
+  }

This keeps behavior identical for simple IDs while avoiding subtle bugs if the task naming scheme ever changes.


55-55: Consider avoiding toSorted for broader runtime compatibility

Sorting the signee list is a good addition, but Array.prototype.toSorted is a relatively new JS feature and may not be available in all supported runtimes without proper target/lib or polyfills:

return parsed.signeeStates.toSorted((a, b) => (a.name ?? '').localeCompare(b.name ?? ''));

To be safe across older browsers/test environments, you can achieve the same effect with widely‑supported APIs:

-  return parsed.signeeStates.toSorted((a, b) => (a.name ?? '').localeCompare(b.name ?? ''));
+  return parsed.signeeStates
+    .slice()
+    .sort((a, b) => (a.name ?? '').localeCompare(b.name ?? ''));
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 74f90aa and c4842d1.

📒 Files selected for processing (2)
  • src/layout/SigneeList/SigneeListSummary.tsx (2 hunks)
  • src/layout/SigneeList/api.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx}: Avoid using any type or type casting (as type) in TypeScript code; improve typing by avoiding casts and anys when refactoring
Use objects for managing query keys and functions, and queryOptions for sharing TanStack Query patterns across the system for central management

Files:

  • src/layout/SigneeList/SigneeListSummary.tsx
  • src/layout/SigneeList/api.ts
{**/*.module.css,**/*.{ts,tsx}}

📄 CodeRabbit inference engine (CLAUDE.md)

Use CSS Modules for component styling and leverage Digdir Design System components when possible

Files:

  • src/layout/SigneeList/SigneeListSummary.tsx
  • src/layout/SigneeList/api.ts
🧠 Learnings (1)
📚 Learning: 2025-11-25T12:53:54.399Z
Learnt from: CR
Repo: Altinn/app-frontend-react PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T12:53:54.399Z
Learning: Applies to **/*.test.{ts,tsx} : Use `renderWithProviders` from `src/test/renderWithProviders.tsx` when testing components that require form layout context

Applied to files:

  • src/layout/SigneeList/SigneeListSummary.tsx
🧬 Code graph analysis (2)
src/layout/SigneeList/SigneeListSummary.tsx (2)
src/core/contexts/TaskOverrides.tsx (1)
  • useTaskOverrides (32-32)
src/layout/SigneeList/api.ts (1)
  • useSigneeList (58-64)
src/layout/SigneeList/api.ts (1)
src/utils/urls/appUrlHelper.ts (1)
  • appPath (7-7)
⏰ 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). (3)
  • GitHub Check: Analyze (javascript)
  • GitHub Check: Install
  • GitHub Check: Type-checks, eslint, unit tests and SonarCloud

Copy link
Contributor

@olemartinorg olemartinorg left a comment

Choose a reason for hiding this comment

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

Looks good! 🥳
Approving, assuming that:

  • It's backwards compatible (backend won't complain if the taskId is passed to older versions not supporting it)
  • You test it manually

Of course, automated tests are preferable, but at the same time this change is pretty low-risk of getting reverted

@sonarqubecloud
Copy link

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

Labels

backport-ignore This PR is a new feature and should not be cherry-picked onto release branches kind/product-feature Pull requests containing new features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants