feat: remove sorting from signing document list

[vxkc]

Sorting is done on the backend in Altinn/app-lib-dotnet#1511

Description

Remove the sorting of the rows in SigningDocumentList. Sorting is done on the backend in Altinn/app-lib-dotnet#1511.

Related Issue(s)

• closes Component: "SigningDocumentList" - customize sequence of documents shown #3367

Verification/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
    feat: change signing data elements ordering altinn-studio-docs#2408
  • 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

• Bug Fixes
  • The Signing Document list now preserves the order provided by the server, rather than reordering items by filename. This ensures the list reflects the intended sequence from the source system, improving consistency across views and workflows. Users may notice a different item order compared to previous versions. No visual or interaction changes beyond the ordering behavior.

[coderabbitai]

📝 Walkthrough

Walkthrough

Removed client-side sorting of parsed dataElements by filename in SigningDocumentList API; now returns elements in the original API-provided order. No changes to exported types or function signatures.

Changes

Cohort / File(s)	Summary
SigningDocumentList API behavior src/layout/SigningDocumentList/api.ts	Eliminated post-parse filename-based sorting; returns dataElements in API order. No public API signature changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

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.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title clearly and concisely describes the primary change, which is removing the client-side sorting of the SigningDocumentList component.
Linked Issues Check	✅ Passed	By removing the client-side sorting and relying on the backend ordering, this change enables the SigningDocumentList to display documents in a customizable sequence as requested in issue #3367; the optional hiding of raw data files remains unaddressed but was not a mandatory requirement.
Out of Scope Changes Check	✅ Passed	All modifications are confined to the sorting logic in SigningDocumentList’s API layer and directly relate to the requested change in document ordering without introducing any unrelated or extraneous code.
Description Check	✅ Passed	The pull request description follows the repository template with a detailed summary, related issue reference, and all required QA and documentation sections filled out according to the template structure.

✨ 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/signing-document-list-ordering

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 048148e and e4683f5.

📒 Files selected for processing (1)

• src/layout/SigningDocumentList/api.ts (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{ts,tsx}: Avoid using any and unnecessary type casts (as Type) in TypeScript; prefer precise typings and refactor existing casts/anys
For TanStack Query, use objects to manage query keys and functions, and centralize shared options via queryOptions

Files:

• src/layout/SigningDocumentList/api.ts

⏰ 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). (1)

• GitHub Check: Install

🔇 Additional comments (1)

src/layout/SigningDocumentList/api.ts (1)

44-44: Remove client-side sorting

• No downstream code or tests rely on client-side ordering.
• Confirm backend (feat: order signing data elements app-lib-dotnet#1511) is deployed and returns the correct document order.
• Add a test to verify the UI displays documents in the API-provided order.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 45%)

See analysis details on SonarQube Cloud

[olemartinorg]

App-frontend has to be backwards-compatible for all versions down to (and including) v8.0.0. Even if sorting now is done backend, I don't think we can remove it from the frontend? In case the sorting is different on backend vs. frontend, we either would have to introduce an opt-out config, or delay this change to the next major version.

If you want to delay this to the next major version only, open a PR in the monorepo instead: https://github.com/Altinn/altinn-studio/tree/main/src/App/frontend

[bjorntore]

App-frontend has to be backwards-compatible for all versions down to (and including) v8.0.0. Even if sorting now is done backend, I don't think we can remove it from the frontend? In case the sorting is different on backend vs. frontend, we either would have to introduce an opt-out config, or delay this change to the next major version.

If you want to delay this to the next major version only, open a PR in the monorepo instead: https://github.com/Altinn/altinn-studio/tree/main/src/App/frontend

Is it easy to check what backend version the frontend is talking to, and sort in frontend if it's before the backend release related to this? Or is that a bad idea?

We're also considering having some flag in the response to tell the frontend to skip sorting, but feels like a hack tbh.

[olemartinorg]

Is it easy to check what backend version the frontend is talking to, and sort in frontend if it's before the backend release related to this?

Yup, that would work. Look in src/utils/versioning/versions.ts for that functionality. Beware that we need both the major.minor.patch version (8.X.X) and the build version. So the functionality needs to arrive in an app-lib-dotnet release before we can know for sure which version sorts this on the backend.

[bjorntore]

Is it easy to check what backend version the frontend is talking to, and sort in frontend if it's before the backend release related to this?

Yup, that would work. Look in src/utils/versioning/versions.ts for that functionality. Beware that we need both the major.minor.patch version (8.X.X) and the build version. So the functionality needs to arrive in an app-lib-dotnet release before we can know for sure which version sorts this on the backend.

Is it a fair solution in your opinion? Or should we rethink even more?

[olemartinorg]

I think that's a good enough solution. In v5/next we'll remove that code anyway, as the dynamics of frontend/backend compatibility there will work differently.