Bug 6916 - Selecting the acq date of an item should take you to the invoice page for it
Summary: Selecting the acq date of an item should take you to the invoice page for it
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: 3.8
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Marcel de Rooy
QA Contact: Ian Walls
Depends on:
Reported: 2011-09-26 05:33 UTC by Robin Sheat
Modified: 2013-12-05 19:53 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:

Bug 6916 - item's acq date now takes you to its invoice (2.40 KB, patch)
2011-09-26 23:43 UTC, Robin Sheat
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 6916 - item's acq date now takes you to its invoice (2.62 KB, patch)
2011-10-08 20:00 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 6916 - item's acq date now takes you to its invoice (2.92 KB, patch)
2011-10-26 11:28 UTC, Katrin Fischer
Details | Diff | Splinter Review
Signed patch (3.15 KB, patch)
2011-11-16 13:15 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Follow up patch (3.94 KB, patch)
2011-11-24 10:56 UTC, Marcel de Rooy
Details | Diff | Splinter Review
[SIGND-OFF] Bug 6916: follow up (4.20 KB, patch)
2011-11-27 16:30 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Sheat 2011-09-26 05:33:14 UTC
Currently it takes you to the basket rather than the invoice, making it harder to see those details.
Comment 1 Robin Sheat 2011-09-26 23:43:04 UTC Comment hidden (obsolete)
Comment 2 Katrin Fischer 2011-10-08 20:00:29 UTC Comment hidden (obsolete)
Comment 3 Paul Poulain 2011-10-24 11:40:12 UTC
Updating version : This ENH could be in Koha 3.8
Comment 4 Paul Poulain 2011-10-25 15:05:54 UTC
Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)
Comment 5 Katrin Fischer 2011-10-26 11:28:43 UTC Comment hidden (obsolete)
Comment 6 Katrin Fischer 2011-10-26 11:29:47 UTC
Retested patch and fixed a conflict. Waiting for QA.
Comment 7 Marcel de Rooy 2011-11-14 14:33:33 UTC
What could I be doing wrong if I see the accession date but it it not linked at all? I already changed AcqCreateItem to receiving an order.
Comment 8 Katrin Fischer 2011-11-14 14:48:17 UTC
Hi Marcel, 
I am not sure how this can happen and how much influence AcqCreateItem has here. It should link correctly, whether you create the item on order or on receive. Perhaps Robin has an idea.
Comment 9 Marcel de Rooy 2011-11-16 13:13:31 UTC
Found it! Actually, this patch hits an existing bug in moredetail.pl, depending on the value of pref AcqCreateItem.
If this pref is set to placing an order, it works because there are records in aqorders_items. If it is set to receiving an order or cataloging the record, it does not work since there are no records in aqorders_items.

Problem is in:
    my $order  = GetOrderFromItemnumber( $item->{'itemnumber'} );
    my $basket = GetBasket( $order->{'basketno'} );
    $item->{'booksellerid'}            = $basket->{'booksellerid'};
    $item->{'ordernumber'}             = $order->{'ordernumber'};
    $item->{'basketno'}                = $order->{'basketno'};
    $item->{'booksellerinvoicenumber'} = $order->{'booksellerinvoicenumber'};
    $item->{'datereceived'}            = $order->{'datereceived'};

Depending on AcqCreateItem $order is filled or not. If not, $basket is empty too, the remaining lines are useless.
Although this report was not opened to resolve this bug initially, I hope Robin can send a follow up to fix this issue too. Note that the order number could be found too via biblionumber. So, it could be fixed in GetOrderFromItemnumber.
Hoping that and realizing that this patch did not introduce the bug, I am setting status to Passed QA.
Comment 10 Marcel de Rooy 2011-11-16 13:15:04 UTC Comment hidden (obsolete)
Comment 11 Paul Poulain 2011-11-17 16:06:19 UTC
patch pushed, please test
Comment 12 Marcel de Rooy 2011-11-24 10:55:19 UTC
Robin, I was hoping that you would send the follow up, but you closed the bug now. So I am really hoping now that you will sign off my follow up ;)

If the accession date is null or the pref is not placing an order, the situation is not solved yet. So therefore this follow up.
Comment 13 Marcel de Rooy 2011-11-24 10:56:35 UTC Comment hidden (obsolete)
Comment 14 Robin Sheat 2011-11-24 12:02:03 UTC
Whoops, sorry. After KohaCon I made a list of things to catch up on, and I'd noted beside this "look at it." I then skim read it, saw it had been pushed, and thought my note was just to test and close. You are right though, the followup should go in. I'll have a look at it soon, unless someone beats me to the punch.
Comment 15 Katrin Fischer 2011-11-27 16:30:09 UTC Comment hidden (obsolete)
Comment 16 Paul Poulain 2011-12-12 17:25:12 UTC
I suspect there's something wrong with this follow-up: if you have a record with 2 items, bought from 2 different orders, this patch will make moredetail fail:

tested case:
* create basket A, add an order from empty biblio, recieve it in "PARCEL A"
* create basket B, add an order from existing biblio, choose the previously added biblio, recieve it in "PARCEL B"
* go to moredetail page => both items are linked to "PARCEL A", which is wrong

(in my tests, AcqCreateItem is set to ordering)
Comment 17 Marcel de Rooy 2011-12-14 13:53:14 UTC
Paul, Good catch. This situation with two items from different baskets will not work now.
Currently, the functionality only works for AcqCreateItem==ordering. In that case you have item numbers in aqorders_items. You do not have any items in that table if AcqCreateItem!=ordering. So, in that case there will never be a working URL. The followup resolves this in most cases (but not for your case).

The problem is that when you create the item later, you actually cannot say where it came from. You could [pragmatically] say if it is the second item, take the second order (could be wrong).
The routine GetOrderFromItemNumber should therefore use aqorder_items for pref==ordering and do another trick otherwise.

Will leave this report open for fixing it later (no priority).
Comment 18 Marcel de Rooy 2012-02-22 12:38:31 UTC
Closing this report for now.
Comment 19 Katrin Fischer 2012-02-22 12:52:30 UTC
Hi Marcel,
there is a patch from Srdjan to add more information about the acquisition process to the moredetail page (bug 7235). I wrote a follow up adding checks on permissions and existence of data in a follow up that I hope will make things more consistent. I am adding the bug as see also, perhaps you want to take a look?