[XingY]

Rationale

Makes the sample operation confirmation scale to very large selections. Confirming an operation loaded a full sample object for every selected row, so a user who selected tens of thousands of samples waited a long time and the server logged a large-collection warning. The confirmation needs only a few facts about each sample — where it lives, its status and its sample type — so nearly everything it loaded went unused. The companion change in limsModules does the same for the removal that follows.

Related Pull Requests

• Delete large number of job samples takes a long time and triggers large-collection warning #8195
• https://github.com/LabKey/limsModules/pull/2549

Changes

• The operation confirmation reads only the per-sample facts it needs and folds each row as it arrives, instead of materializing every selected sample up front.
• Resolving a sample's type from the type identifier stored on the sample moved behind a shared service method, so the confirmation path and the sample object no longer each carry their own copy of that rule.
• The linked-to-study warning is given the sample type it should describe, rather than deriving it from the first entry of a fully loaded list.
• Splitting a selection into permitted and blocked ids uses a set, so removing the blocked ids no longer degrades as the selection grows.