Phoenix: Workspace Multi-Select

[shaheerk94]

Feature: Multi-File Selection and Operations in Workspace Navigation

Problem Statement Users often need to perform the same operation on multiple files but currently can only act on one file at a time. This slows down workflows and increases the risk of human error.

---

Proposed Solution

Enable multi-file selection and bulk operations within the workspace navigation panel.

Selection Behavior

• Shift + click → select a contiguous range of files.
• Cmd / Ctrl + click → select or deselect individual files.
• Clicking a file opens it as usual. Shift/Cmd/Ctrl clicking only selects—it does not open the file.

---

Supported Operations (via Right-Click Context Menu)

• Move / Copy / Delete

  • Backend should support multi-file requests in one transaction.
  • If partial failures occur (e.g., name conflicts or missing files), process valid items and return structured errors.
  • For name conflicts, offer “Skip”, “Replace”, or “Keep both” (append a number). Include an “Apply to all” checkbox.
  • For non-name conflicts, offer “Skip” or “Retry” options.
  • The UI will send a JSON array of selected files to the corresponding endpoint and display success/failure results clearly.

• Move to Workspace

  • Same semantics as Move/Copy/Delete, but target workspace instead of folder.

• Run Action

  • “Run Action” lists all actions available in the current workspace, filtered by file type and validity in multi-select mode.
  • User selects an action, triggering a modal where parameters are pre-populated with the selected files.
  • One action is created with all selected files as input.
  • For now, support only many-to-one mappings (a single action operating on all selected files). Many-to-many support can come later.
  • The primary flag in action definitions determines which parameter receives the file selection.
  • Only one primary flag is allowed per action.
  • The right-click “Actions” menu shows only actions whose primary parameter type matches the selection (e.g., sequence, file, file list).

• Download

  • Downloads all selected files as a single compressed archive (e.g., .zip).

• Output Menu

  • Lists all supported output formats.
  • On selection, converts and downloads files that can be converted.
  • Files that cannot be converted are either skipped (with a warning) or downloaded in native format—final behavior TBD with Carter/Travis.

---

Out-of-Scope / Hidden in Multi-Select

Actions that do not make sense for multiple files (e.g., Rename, New File, New Folder, Upload File, Copy Link to Download) will be hidden when multiple items are selected.

---

Design Decisions

• Input Handling: Support only many-to-one action inputs initially.
• Action Schema Update: Add new input types (file, file list) alongside existing (sequence, sequence list).
• Error Handling: Always perform valid operations and report detailed errors for failures.
• Post-Action UI: After running an action, show confirmation modal (reuse existing modal used for single-file actions) with link to action-run details.
• State Feedback: Display clear progress and result indicators (“4 of 5 files moved successfully”).
• Future Work: Expand to many-to-many patterns where each selected file triggers its own action instance.

---

Summary

This feature brings parity with standard OS-level file operations, reduces repetitive manual actions, and integrates cleanly with existing workspace actions. The design balances immediate utility (many-to-one actions, bulk Move/Delete) with an upgrade path to more complex patterns later.

[Mythicaeda]

Rename on multiple files doesn't make sense, nor does right-clicking and copying the path/filename of multiple files to the clipboard (if you mean for that right-clicking functionality to be on a single file, please put it in its own ticket).

If you're trying to convert and download a set of files and only some succeed, I'd expect to get either all of the ones that are successful or none of them (preferably the former but I'll defer to our users), and not all the converted files up to the failure (not saying that's what you proposed, just wanted to explicitly call out the third return option).

[shaheerk94]

Removed rename, pulled last bullet into its own ticket: https://github.com/NASA-AMMOS/aerie-ui/issues/1795

I'd expect to get either all of the ones that are successful or none of them (preferably the former but I'll defer to our users), and not all the converted files up to the failure (not saying that's what you proposed, just wanted to explicitly call out the third return option).

Agreed

[shaheerk94]

Multi-Select with Actions: Options

Options considered

1. Many-to-many file inputs
Each selected file maps to a separate action. Each action operates on its single file input.

2. Many-to-one file inputs
All selected files map to a single action. That action can either
• perform separate atomic operations on each input, or
• treat the entire set as one combined input.
Implementation detail: mark one action parameter as primary in the action definition. The UI uses this primary flag to map selected files to that parameter.

3. Supporting both
Ways to expose both patterns:
• Offer both as distinct menu options. Simple to build but potentially confusing for users.
• Offer a single menu option and infer the intended pattern from user inputs and action metadata. Cleaner UI but more hidden complexity.

Team feedback
Carter and Parker said many-to-one covers their needs and are happy with that if it saves development effort.

[shaheerk94]

250929 Shaping

• Backend currently does not support Move/Copy/Delete or Move to workspace as multiple operations within a single request
• Could be done as multiple request from front-end, but prefer to update endpoints to allow multiple
• Need to think through error reporting - what kind of failures might we see on the backend?
• Should only do one operation at a time on the backend ?
• Should provide safety requests against multiple requests (don't break workspace)
• Always through errors on bad inputs (file that doesn't exist). What about a mixture of good and bad inputs? Do we operate on the good inputs? Yes - like OS operations (bulk move) - note that we aren't an operating system but this is probably still fine. "move what you can".
  • Decision: for move/copy/delete actions, perform all actions that can be done (ie: valid inputs) and report errors for failures clearly. What's more confusing - stop at failure on 3/5, or continuing on with 4 and 5 after 3 fails? Two classes of error: name conflict and "anything else"
  • Implement Mac behavior: skip, replace, or keep both? "keep both" option means append a number. Include a checkbox for "apply to all". Note that this is only for name conflict type errors, not anything else
  • Also implement Windows behavior: for non name conflicts, do you want to skip or re-try? Applies for non-name conflict errors
  • Design option: UI produces JSON request, sends JSON array as single input to "move" endpoint in workspaces. Workspaces will respond either with "200" or non-200 status with what failed and why. UI has a list of files from output array: files X Y Z had name conflicts
  • Very important: communicate state very clearly
  • Display file stats after move (after we have metadata steps)
• What do we do with error messages like "x files didn't move"?
• What weird edges are there?
• Behavior vs implementation

Output name options when a user has selected a mixture of inputs and wants to output (eg: selected 5 SEQN files, 2 SEQ JSONs, and 3 binaries and clicks "output seq json"):

• Hide option if any files in the list if either any of the inputs cannot be converted to the output format OR are not already in the output format
• Convert any files that are valid for conversion, download converted files and files that are already in the output format, ignore others
• Convert any files that are valid for conversion, download converted files and files that are already in the output format, download others in their native format

^ No decision yet, will check with Carter and Travis

[shaheerk94]

Multi-Select Feature – Condensed Notes

Shaheer proposed adding multi-select so users can choose multiple files and run bulk actions (move, copy, delete, download). Standard OS-style selection (shift/command click) and right-click menus will apply.

Backend
Theresa will rework endpoints to accept bulk inputs for atomic operations and clearer error handling. Partial failures should return an errors array and proper HTTP codes. Edge cases like file locks must be handled gracefully.

User Experience
Operations continue despite individual errors, with clear reporting of failed files. Name conflicts will offer overwrite or keep-both options, possibly with auto-renaming.

Actions & UI
A single action will operate on all selected files. Action authors must ensure their code handles multiple inputs. Non-applicable menu options will be hidden.

Next Steps
Theresa to plan backend changes and error handling details. Team will keep refining actions and output behavior in future meetings.

[shaheerk94]

250930

Actions

• Decision: Support only many-to-one inputs to actions for now, with option to add many-to-many inputs to actions later
• Does actions API right now support all "files" or only sequences?
• Right now, only sequences. Dan proposed adding two new input types to schema: "file" and "file list" type inputs, and keep sequence/sequence list as they are right
• Still need primary flag. Do we want a rule that says we are allowed only "primary" flag overall, or only one "primary"? Decision: only allow one primary across all action parameters. Use this primary to auto-populate "file", "file list", "sequence", or "sequence list" in UI based on selected files.
• use primary flag as well to control what actions appear in right click -> actions menu. EX: single sequence selected, show actions where "sequence" is primary parameter. Repeat for each other file type inputs
• What happens after a user clicks "run" on an action? Decision: extra screen pops up to indicate action has run, can either use that to navigate to actions run page, or stay on sequence edit page. This modal exists already and appears when running actions from the actions menu in the workspaces context - can reuse.