Currently it takes you to the basket rather than the invoice, making it harder to see those details.
Created attachment 5601 [details] [review] Bug 6916 - item's acq date now takes you to its invoice When viewing an item's details, selecting the accession date for it now takes you to the invoice for that item.
Created attachment 5805 [details] [review] [SIGNED-OFF] Bug 6916 - item's acq date now takes you to its invoice When viewing an item's details, selecting the accession date for it now takes you to the invoice for that item. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> This works as advertised. 1) Order and receive an item in acquisition 2) Search for it in staff and go to the 'items' tab 3) Click on the 'receive date' link
Updating version : This ENH could be in Koha 3.8
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)
Created attachment 6062 [details] [review] Bug 6916 - item's acq date now takes you to its invoice When viewing an item's details, selecting the accession date for it now takes you to the invoice for that item. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> This works as advertised. 1) Order and receive an item in acquisition 2) Search for it in staff and go to the 'items' tab 3) Click on the 'receive date' link Fixed conflict in moredetail.pl.
Retested patch and fixed a conflict. Waiting for QA.
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.
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.
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.
Created attachment 6316 [details] [review] Signed patch QA Signoff
patch pushed, please test
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.
Created attachment 6388 [details] [review] Follow up patch Changed the SQL statement in GetOrderFromItemnumber so that it works also if syspref AcqCreateItem is not equal to placing an order. Returned hash now only includes fields from aqorders. This function is used in moredetail.pl and Items.pm (function MoveItemFromBiblio). Modified moredetail template so that label is shown always. Added nbsp to prevent mixup of columns when date is null. Test this by checking Items tab in normal view staff and by attaching an item in normal view staff (actually moving an item). Check moredetail again while changing syspref AcqCreateItem.
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.
Created attachment 6436 [details] [review] [SIGND-OFF] Bug 6916: follow up Changed the SQL statement in GetOrderFromItemnumber so that it works also if syspref AcqCreateItem is not equal to placing an order. Returned hash now only includes fields from aqorders. This function is used in moredetail.pl and Items.pm (function MoveItemFromBiblio). Modified moredetail template so that label is shown always. Added nbsp to prevent mixup of columns when date is null. Test this by checking Items tab in normal view staff and by attaching an item in normal view staff (actually moving an item). Check moredetail again while changing syspref AcqCreateItem. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Checked that acquisition date is correctly linked for items created with AcqCreateItem set to 'on order' and 'on receive'. As items cataloged with 'in cataloguing' are not linked to acquisitions, there is no link for that settings.
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)
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).
Closing this report for now.
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?