UX-CAT-004 — Provide one consistent Upload data action
| Field | Value |
|---|---|
| Status | Open finding; source-verified and live-observed |
| Severity | Medium |
| Affected surface | Catalog sidebar and landing-page upload actions |
| Implementation issue | oqullus #543 |
| Code-change repository | sparqd/oqullus |
Where the problem appears
Open the sidebar plus menu and landing-page Add Data menu, compare wording and forms, then complete an approved disposable upload.
Concrete observed case
Two entry points independently fetch the same destinations and open the same form, but use Upload CSV, Upload CSV to Lakehouse, and Upload CSV Data wording. The compact plus control has no visible purpose, and success does not refresh both Catalog views.
Expected condition
Use one shared Upload data action and drawer. Identify CSV file and Excel file, explicitly select catalog and schema, preserve authorization and errors, and refresh affected discovery after success.
Cause and evidence
- Both controls duplicate destination loading and modal state.
- Copy changes across the path and introduces connector-specific Lakehouse wording.
- Neither success path reliably invalidates every Catalog view.
Why it matters
Users face ambiguous actions and stale post-upload results, while duplicated implementation drifts.
Existing controls and workarounds
After upload, manually refresh Catalog and verify the destination with a qualified query.
Alternatives considered
- Recommended: one shared action available from intentional placements.
- Keep two launchers backed by one shared capability and drawer — acceptable if both placements are justified.
- Retain independent implementations — rejected due to drift and duplicate requests.
Component involvement
- Oqullus owns shared interaction, accessibility, and refresh.
- BFF/Superset integration owns destination capability and upload execution.
- Product defines supported formats and limits.
Reproduction and verification
Follow CAT-S014. Record the visible state, request outcome, effective identity, and recovery behavior relevant to this finding.
Resolution conditions
Close when both any retained launch points share one implementation, wording and accessibility are consistent, and successful upload refreshes canonical discovery state.
Validation and blockers
Oqullus and product are primary; BFF validates authorization and failure behavior.