You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
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
Direct JS mount in JSF for tree view reuse (#12179).
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)
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.
March to April 2026: complete tree view implementation track and JSF mount/reuse track; keep session hardening as a separate lower-priority track.
By end of April 2026: target all core coding to be implementation-complete (including tree view initial scope and mount path).
May to June 2026: review/merge/release timing and stabilization based on maintainer bandwidth.
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: Tree node listing helpers + server-authoritative S3 tagging dataverse-client-javascript#403dataverse-frontend: Add reusable React components: file uploader and file tree view #898What 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?
Any brand-new behavior do you want to add to Dataverse?
Any open or closed issues related to this feature request?
Additional Dataverse tracking issues
IQSS/dataverse#12178: Session-auth hardening track/api/access/*.IQSS/dataverse#12179: Direct JS mount in JSF for tree view (feature flag + iframe fallback)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)
dataverse-client-javascriptPR #403 (provides publishable client library target).dataverse-frontendPR Add reusable React components: file uploader and file tree view #898 to uses GitHub npm package client library artifacts instead of local linking.dataverse-frontendPR Add reusable React components: file uploader and file tree view #898.Planned order of work
dataverse-client-javascript(PR #403 ).dataverse-frontend(Add reusable React components: file uploader and file tree view #898).#6691track).#12179).#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)
dataverse-client-javascriptanddataverse-frontendusing local build references where needed, and start tree view implementation in SPA.