Feature Request/Idea: reusing file upload page as dvwebloader

[ErykKul]

Overview of the Feature Request
The goal is to upgrade the classic JSF upload experience by reusing the new SPA upload components (currently developed as standalone pieces in dvwebloader and dataverse-frontend). 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: feat: add configurable file upload options and related tests dataverse-client-javascript#403
• dataverse-frontend: Feature/standalone file uploader #898
• dvwebloader: DVWebloader V2: Modern File Uploader Using Dataverse Frontend Components gdcc/dvwebloader#44

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?

• Feature Request/431 file upload page missing features #431
• Allow selecting of files in Tree View to Edit or Download dataverse#6691

Additional Dataverse tracking issues

• IQSS/dataverse #12178: Session-auth hardening track
  • Link: Feature Request: Session-Cookie API Hardening with CSRF Protections and Mutating-GET Guardrails dataverse#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: Feature Request: Feature-Flagged Direct JSF Mount for SPA Tree View (with iframe Fallback) dataverse#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).
dvwebloader is treated as a special deployment case and is planned as the last step.

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 #12178.
• Complete and merge dataverse-client-javascript PR JSDatasetMapper: toHierarchy() sets persistentId to undefined #403 (provides publishable client library target).
• Rebase/adjust dataverse-frontend PR Feature/standalone file uploader #898 to use merged client library artifacts instead of local linking.
• Complete and merge dataverse-frontend PR Feature/standalone file uploader #898.
• Rebase/adjust dvwebloader PR 32 bootstrap not customized #44 on top of merged frontend/client changes.
• Complete and merge dvwebloader PR 32 bootstrap not customized #44.
• 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.

Planned order of work

1. dataverse-client-javascript (JSDatasetMapper: toHierarchy() sets persistentId to undefined #403).
2. dataverse-frontend (Feature/standalone file uploader #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.
6. dvwebloader (32 bootstrap not customized #44) finalization/deployment alignment as the last step.

Baseline PR merge dependency remains #403 -> #898 -> #44, while overall implementation priority targets tree-view delivery before final dvwebloader deployment alignment.

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.

dvwebloader is a deployment-sensitive special case: cross-origin hosting (for example static GitHub hosting) runs into session/CSRF constraints, while same-origin deployment (for example local Docker image under Dataverse origin) can use JSESSION-based flow. Because upload already works today, this track is intentionally scheduled last.

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. After core feature rollout: finalize dvwebloader deployment alignment as the last step.
5. May to June 2026: review/merge/release timing and stabilization based on maintainer bandwidth.

[cmbz]

2026-02-23: Assigned as won't have for FY26. However, if @ErykKul you plan to implement the feature before June 2026, we could consider getting it into a release.

[ErykKul]

Thanks for the note, @cmbz. Yes, I’m planning to implement this before June 2026.

I updated the issue body with more context, links to the related issues/PRs, and the current planning/timeline. I’ll keep sharing progress there as milestones are completed.