We've run into an interesting bug with Bill's fix.
In our environment, with the fix applied, if you are adding a new item at a multi-branch library and use the Edit icon to change the owning library to a different branch, it fails. The reason is that Bill's fix attempts to propagate the owning library change to all copies belonging to the call number -- but when you're adding a new item and call number together, the call number has a dummy ID of -1, which is actually the UNCATALOGED call number. In our environment, call number -1 has 37,000 copies attached, and EG basically times out when it tries to look them up. But even if there were 0 attached items, it would be incorrect to propagate the change in this case.
I haven't tested this yet, but I believe the solution is to only propagate the owning lib change if the call number ID >= 0.
We've run into an interesting bug with Bill's fix.
In our environment, with the fix applied, if you are adding a new item at a multi-branch library and use the Edit icon to change the owning library to a different branch, it fails. The reason is that Bill's fix attempts to propagate the owning library change to all copies belonging to the call number -- but when you're adding a new item and call number together, the call number has a dummy ID of -1, which is actually the UNCATALOGED call number. In our environment, call number -1 has 37,000 copies attached, and EG basically times out when it tries to look them up. But even if there were 0 attached items, it would be incorrect to propagate the change in this case.
I haven't tested this yet, but I believe the solution is to only propagate the owning lib change if the call number ID >= 0.