Suggested actions on selection of several Blob Containers

[eugen-nw]

Suggested actions on selection of several Blob Containers

[MRayermannMSFT]

@craxal for 1.34.0 please identify and propose existing blob container level actions that could/should support being done in batch. Good candidates are feasible if there is a supporting API or if the client logic needed to do the action in batch is fairly trivial. We can then discuss the proposed actions and how they would work, and come to a consensus if they are feasible.

[craxal]

Here's a breakdown of all available blob container commands and their suitability for operating on multiple containers:

Command	Good Candidate?	Notes
Acquire Lease	✅ Yes	Should generate one activity per container.
Break Lease	✅ Yes	Should generate one activity per container.
Clone	❌ No	Dialog, not suitable for multiple selection.
Copy	⚪️ Maybe	Changes clipboard data format.
Copy Direct Link	❌ No	Odd UX, unlikely to be useful.
Create	❌ No	Dialog not suitable for multiple selection.
Delete	✅ Yes	Should generate one activity per container.
Generate SAS	❌ No	Dialog, not suitable for multiple selections
Manage ACL	❌ No	Dialog, not suitable for multiple selections.
Manage SAP	❌ No	Dialog, not suitable for multiple selections.
Open	✅ Yes	Should open a new tab for each container selected.
Paste	⚪️ Maybe	(see Copy)
Propagate ACL	❌ No	Not easy to backtrack even for single items.
Properties	❌ No	Dialog, not suitable for multiple selections.
Refresh	N/A	Doesn't operate on selections.
Rename	❌ No	Dialog, not suitable for multiple selections.
Set Public Access	✅ Yes	Should generate one activity per container.

• There are no REST APIs available that operate on more than one container.
• Multi-container operation candidates may involve more complex activity management, such as nesting activities in a parent activity, which will be more expensive if the original operations weren't designed to handle more than one activity.

[eugen-nw]

Excelent list, well thought through. In response to properties of multiple blobs, may want to display their total size.

That’s great that there are no REST APIs that operate on multiple blobs. That would just complicate things unnecessarily.

You may want to launch the various API calls that target the selected blobs on independent threads, wait for all to finish and gather their results. If all completed successfully, the app just goes on. Otherwise perhaps report the operations that failed so the user can retry them later.

[craxal]

@eugen-nw

That’s great that there are no REST APIs that operate on multiple blobs. That would just complicate things unnecessarily.

The first note is merely mentioning that orchestrating multiple operations needs to be done client-side. The complexity is there regardless of where it is implemented. The primary concern here is that, without a REST API, it's up to the client to orchestrate everything instead of the server.

You may want to launch the various API calls that target the selected blobs on independent threads, wait for all to finish and gather their results. If all completed successfully, the app just goes on. Otherwise perhaps report the operations that failed so the user can retry them later.

The second note is more a question of presentation than orchestration. Some methods of presentation will take more time than others. It may be something we can refine over time.

[eugen-nw]

For some fun, you may want try to delete one by one 50 containers. Then you’ll see why this feature request came about.

[MRayermannMSFT]

I've made issues for these 4:

• #7945
• #7946
• #7947
• #7948

@craxal, can you please make issues also for "Open" and put it into Future? We can see if people ask for it. And after that you can close this issue as completed.