Feature Request/Idea: reusing file upload page as dvwebloader

Overview of the Feature Request
The goal is to upgrade the classic JSF upload experience by reusing the new SPA upload components. This includes folder upload support and a UI that is visually aligned with modern Dataverse frontend components.

This work started as a feasibility experiment and is now tracked as an implementation plan across three repositories.

Linked implementation PRs (cross-repo)

• dataverse-client-javascript: https://github.com/IQSS/dataverse-client-javascript/pull/403
• dataverse-frontend: https://github.com/IQSS/dataverse-frontend/pull/898

What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)
Depositor (primary), Curator (secondary)

What inspired the request?
The SPA file upload page and its overlap with the current dvwebloader use case.

What existing behavior do you want changed?

• Replace/upgrade the classic upload UI path with the SPA-based upload component integration.
• Keep current permission and dataset workflows intact.
• Reduce reliance on older iframe-based integration patterns where possible.

Any brand-new behavior do you want to add to Dataverse?

• Folder upload in the classic UI path.
• Improved upload UX parity with the SPA.

Any open or closed issues related to this feature request?

• #431
• https://github.com/IQSS/dataverse/issues/6691

Additional Dataverse tracking issues

• IQSS/dataverse #12178: Session-auth hardening track
  • Link: https://github.com/IQSS/dataverse/issues/12178
  • Scope: request auth-mechanism tagging, hardening flag, session-cookie-specific behavior gating for /api/access/*.
  • Priority: important for security/completeness, but not the highest priority for initial feature rollout.
• IQSS/dataverse #12179: Direct JS mount in JSF for tree view (feature flag + iframe fallback)
  • Link: https://github.com/IQSS/dataverse/issues/12179
  • Scope: JSF integration contract and rollout path for reusing SPA tree view implementation.

Strategic context / ultimate goal
This uploader modernization is a foundation step for the tree view and downloads work in Dataverse issue #6691. The broader objective is to implement complex UI behavior once in the new SPA component model and reuse it in JSF and potentially other frontends, instead of maintaining separate feature implementations.

Target outcome: complete this uploader baseline quickly, then carry the same reuse pattern into the tree view feature, with a goal of having an initial tree view slice ready for review before June 2026.

Uploader integration direction for this track: keep the current working flow and prioritize tree-view-related work first.
Direct JavaScript mount in JSF is planned for tree view reuse (separate from tree view SPA implementation itself).

Implementation checklist (status + next steps)

• Cross-repo baseline PRs opened.
• Initial feasibility validated (standalone uploader path works in principle).
• Execute Dataverse session-auth hardening track from PR #12178
• Completed (not yet merged) dataverse-client-javascript PR #403 (provides publishable client library target).
• dataverse-frontend PR #898 to uses GitHub npm package client library artifacts instead of local linking.
• Complete (and merge when ready) dataverse-frontend PR #898.
• End-to-end testing in JSF integration path (upload, folder upload, auth/session behavior, permissions).
• Documentation and rollout notes.
• Start implementation track for tree view/download integration based on #6691 using the same SPA-to-JSF reuse approach.
• Have an initial tree view feature slice ready for review before June 2026.
• Reviews, implementation of in review requested changes, merging.

Planned order of work

1. dataverse-client-javascript (PR #403 ).
2. dataverse-frontend (#898).
3. Tree view implementation in SPA (#6691 track).
4. Direct JS mount in JSF for tree view reuse (#12179).
5. Session-auth hardening track (#12178) in parallel, treated as lower-priority/non-blocking for initial feature rollout.

Dependency model
The order above is primarily a merge-order dependency, not a coding-order dependency. Implementation can proceed in parallel while keeping local build references between repos; those local references are replaced with published/merged artifacts as upstream PRs land. Session-auth hardening is treated as a separate track and should not block initial feature rollout.

Estimated timeline (as of February 24, 2026)

1. Late February to March 2026: continue implementation in dataverse-client-javascript and dataverse-frontend using local build references where needed, and start tree view implementation in SPA.
2. March to April 2026: complete tree view implementation track and JSF mount/reuse track; keep session hardening as a separate lower-priority track.
3. By end of April 2026: target all core coding to be implementation-complete (including tree view initial scope and mount path).
4. May to June 2026: review/merge/release timing and stabilization based on maintainer bandwidth.