Comment 16 for bug 1754387

I retract what I said in comment 15, the file load feature is quite efficient, it sends all the barcodes in one query. That is why the order of the barcodes in the loaded file gets lost, or at least part of the reason. Postgres returns the results in no particular order. Then the grid sorts them by user id.

Loading them with one query does mean that getting feedback about not found, or invalid user barcodes is harder to get.

I'm not sure if it is the grid fleshing out entries, or moving pending to a bucket that causes a high number of drones to be used on the server.

And since it directly queries actor.card, inactive and non-primary barcodes will load patron records, which is fine with me.

Another issue I noticed, The pending user screen will allow you to move users to the bucket that are already in the bucket, which results in duplicates in the bucket. But the duplicates get deduped when displaying the bucket. If you remove the visible user that has duplicates, then the non-visible entry becomes visible. So if you add one user 4 times to a bucket, you have to remove that user 4 times from the bucket to fully get rid of them.

I have some changes that address the original 2 issues, only being able to view 100 pending records at a time, and only being able to move 100 at a time into a bucket.

Branch coming soon.
Josh