Serials users cannot override copy template's location field in batch receive

Bug #1149968 reported by Lebbeous Fogle-Weekley on 2013-03-06
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Confirmed on master and 2.3.3, and probably affecting versions all the way back through currently supported branches.

If you use the batch receive interface to receive items from a distribution that uses a copy template with the [copy] location field set, changes to the copy location on a per-item basis in the interface do not take effect.

I haven't confirmed that this doesn't happen in the Serial control view's Items tab, but I bet that interface does not exhibit the same problem owing to different code path followed in that interface's receiving process.

Ben Shum (bshum) on 2013-03-17
Changed in evergreen:
milestone: none → 2.4.0-rc
status: New → Triaged
importance: Undecided → Medium
Ben Shum (bshum) on 2013-04-27
Changed in evergreen:
milestone: 2.4.0-rc → none
Ben Shum (bshum) on 2013-08-22
no longer affects: evergreen/2.2

Here's a fix:;a=shortlog;h=refs/heads/user/senator/lp1149968

Here's how I tested it:

I created a simple Copy Template (Admin -> Local Administration -> Copy Template Editor) with location = Stacks.

I created an additional copy location (asset.copy_location) with name 'Foo'.

Create a subscription, distribution (using above template as Receive Unit Template), stream, caption and pattern, starter issuance, and predict some more issuances.

Do some receiving in Batch Receive (with "Create Units..." checked) and set the copy location field for some of your items to "Foo".

You'll see that the units that wind up in your catalog have location 'Stacks' instead of the correct 'Foo', until you apply this patch, which should correct that misbehavior.

Based on the place where code needed changed, I bet this problem doesn't really involve copy templates at all, and you would still see the same problem if you left copy templates out of the test altogether.

tags: added: pullrequest
Dan Wells (dbw2) on 2014-01-16
Changed in evergreen:
milestone: none → 2.6.0-alpha1
no longer affects: evergreen/2.3
Remington Steed (rjs7) wrote :

Tested the code, works as expected. I've signed off at the branch below:


Dan Wells (dbw2) wrote :

Pushed to master through rel_2_4. Thanks, guys!

Changed in evergreen:
status: Triaged → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
no longer affects: evergreen/2.4
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers