https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernard.scaife@ptfs-europe. | |com, | |martin.renvoize@ptfs-europe | |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- [comment not intended as a blocker] Hi Pedro, I wonder if it would make sense to resolve the ID to the vendor's name. Could be a separate bug. To explain: Libraries not using the acq module like to write a vendor name in the field in the cataloguing editor as there is no plugin or similar to search for a vendor to create a proper link (there is a bug for that somewhere...) For libraries using the acq module, Koha adds the booksellerid of the vendor automatically in the acquisition process. Some libraries will have a mix of both (retro-cataloguing, migrated data, donations, etc.) If we have the ID, we won't resolve to the vendor name with this patch and there is no easy way for the library to figure out the actual vendor. We neither allow searching by booksellerid, nor do we display the ID on the vendor's detail page. You can only see it in the URL. I see that the items tab in the staff interface (moredetails.pl) uses this code: if ($item_info->{'basketno'}){ my $basket = GetBasket($item_info->{'basketno'}); my $bookseller = Koha::Acquisition::Booksellers->find( $basket->{booksellerid} ); $item_info->{'vendor'} = $bookseller->name; } So if an order for the item exists, it gets resolved to the name, otherwise it remains as is. Also something that could probably be improved on. But re-using the logic would give us a consistent display/behavior between items tab and holdings table. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #5 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to Katrin Fischer from comment #3)

For libraries using the acq module, Koha adds the booksellerid of the vendor automatically in the acquisition process.

I'm trying to go through with this use case but failing. Are you able to provide simple instructions on how to do it? I'm currently creating an order from a suggestion, it creates a biblio record but no item(s), and not with the vendor id in booksellerid. Thanks! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com --- Comment #7 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- On top of bug 33568 please. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #162519|Bug 36182: Add booksellerid |[23.11] Bug 36182: Add description|column to holdings table |booksellerid column to | |holdings table -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|Sandbox | --- Comment #10 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi guys I've left the original patch as 23.11 for backport, re-tested, works as intended. Although this is a small enhancement and not a bugfix, would be great to have this backported if possible as it'd be one less bug that we'd have to backport manually to our customers. Submitted new patch based on master on top of bug 33568. (In reply to Katrin Fischer from comment #3)

[comment not intended as a blocker]

Hi Pedro,

I wonder if it would make sense to resolve the ID to the vendor's name. Could be a separate bug.

To explain: Libraries not using the acq module like to write a vendor name in the field in the cataloguing editor as there is no plugin or similar to search for a vendor to create a proper link (there is a bug for that somewhere...) For libraries using the acq module, Koha adds the booksellerid of the vendor automatically in the acquisition process. Some libraries will have a mix of both (retro-cataloguing, migrated data, donations, etc.)

If we have the ID, we won't resolve to the vendor name with this patch and there is no easy way for the library to figure out the actual vendor. We neither allow searching by booksellerid, nor do we display the ID on the vendor's detail page. You can only see it in the URL.

I see that the items tab in the staff interface (moredetails.pl) uses this code:

if ($item_info->{'basketno'}){ my $basket = GetBasket($item_info->{'basketno'}); my $bookseller = Koha::Acquisition::Booksellers->find( $basket->{booksellerid} ); $item_info->{'vendor'} = $bookseller->name; }

So if an order for the item exists, it gets resolved to the name, otherwise it remains as is.

Also something that could probably be improved on. But re-using the logic would give us a consistent display/behavior between items tab and holdings table.

Would it be okay if this is handled in a different bug as further enhancement with a detailed test plan? I'm still having a hard time reproducing this as I don't think I'm experienced enough in acquisitions to get this use-case going. Thanks. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply CC| |lucas@bywatersolutions.com --- Comment #11 from Lucas Gass <lucas@bywatersolutions.com> --- Needs rebased now that we have Bug 36182. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #13 from Lucas Gass <lucas@bywatersolutions.com> --- (In reply to Pedro Amorim from comment #12)

(In reply to Lucas Gass from comment #11)

...

Needs rebased now that we have Bug 36182.

Patch applies for me, double-checking: have you applied interactively and commented the [23.11] one?

My mistake, I only noticed the 23.11 patch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #165265|0 |1 is obsolete| | --- Comment #14 from Lucas Gass <lucas@bywatersolutions.com> --- Created attachment 165485 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=165485&action=edit Bug 36182: Add booksellerid columns to holdings table 1) Apply patch, reset_all 2) Configure holdings_table, visit: <staff_url>/cgi-bin/koha/admin/columns_settings.pl?module=catalogue&page=detail&table=holdings_table 3) Confirm holdings_booksellerid is there and is hidden by default 4) Visit a record: <staff_url>/cgi-bin/koha/catalogue/detail.pl?biblionumber=76 5) Edit one of the items and add a value to field 'e' Source of acquisition 5.5) You may need to click the 'show filters' link in order to have the 'Columns' table button show up 6) Go back to the record and click on the 'Columns' above the table 7) Click 'Source of acquisition'. Confirm it shows as expected Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #16 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- This will still only display the vendor ID for all libraries using the acquisition module with item creation. I think as such it's not really useful right now and the change requested would not add much extra work. See: bug 36750 (In reply to Keith Dembek from comment #17)

+1 for me, in our system I'm probably the only current staff member who would know a vendor #, so having the name would be very helpful for other staff!

-- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #18 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I checked in our production systems with acq and the booksellerid is always set to the vendor id. So this should work: 1) Create a new basket, make sure you set item creation to "on order" 2) Create an order line with one or more items 3) Close the basket 4) Receive shipment for that vendor 5) Receive your order line with the item 6) Check the item - some fields should have been set by the acq module, like price and booksellerid. I feel the feature as suggested is not useful and might be confusing to a lot of libraries even. I made a suggestion on how to resolve to vendor name in comment#3, it's the same code used on the items tab (moredetails.pl), so it would give us consistency to use the same logic. I was hoping to spot the logic in a proper module, but... *sigh* https://git.bsz-bw.de/koha/koha/-/blob/master/acqui/finishreceive.pl#L181 my $new_order_object = Koha::Acquisition::Orders->find( $new_ordernumber ); # FIXME we should not need to refetch it my $items = $new_order_object->items; while ( my $item = $items->next ) { $item->update({ booksellerid => $booksellerid, dateaccessioned => $datereceived, datelastseen => $datereceived, price => $unitprice, replacementprice => $replacementprice, replacementpricedate => $datereceived, }); } -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #19 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 166276 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=166276&action=edit Bug 36182: Show vendor name if acquisition_source is a vendor_id This will make it so if acquisition_source is of an existing vendor_id, it'll show the vendor name instead of the id. If it's not of an existing vendor_id, show the raw value instead. I'm not 100% happy with this patch as it adds an edge case to Item::strings_map but I believe the only alternative is to make 952$e Source of acquisition an AV field in the default framework. Not only that, but this would have to be an AV field of type 'vendors' that'd have to allow to pick from existing vendors (similar to current 'branches'). The above is a ton more work than initial suggestions would imply. Happy to be proven wrong (in fact, hoping I am). This is compatible with main Koha only, not backportable to 23.11 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #21 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Comment on attachment 166277 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=166277 Receive orderline with item That doesn't look right. I hope we didn't break something :( You should see your items on the left side if you have created them "on order" within the table. To unlock the button you'd then need to checkbox an item in the table OR to add something in "quantity received". -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Signed Off --- Comment #22 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- This still applies. Note that when applying on main, skip the [23.11] patch. Likewise, when applying on 23.11.x, apply only the [23.11] patch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Signed Off --- Comment #24 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to Katrin Fischer from comment #23)

I don't want to make a mess here, could you please rebase? Happy to have another look then!

This still applies. Note that when applying on main, skip the [23.11] patch. Likewise, when applying on 23.11.x, apply only the [23.11] patch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #26 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Katrin Fischer from comment #25)

That's probably what I missed. Will have another go once we got Jenkins happy again.

Sorry, I had missed that one. Having a look now. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #166276|0 |1 is obsolete| | --- Comment #29 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 174400 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174400&action=edit Bug 36182: Show vendor name if acquisition_source is a vendor_id This will make it so if acquisition_source is of an existing vendor_id, it'll show the vendor name instead of the id. If it's not of an existing vendor_id, show the raw value instead. I'm not 100% happy with this patch as it adds an edge case to Item::strings_map but I believe the only alternative is to make 952$e Source of acquisition an AV field in the default framework. Not only that, but this would have to be an AV field of type 'vendors' that'd have to allow to pick from existing vendors (similar to current 'branches'). The above is a ton more work than initial suggestions would imply. Happy to be proven wrong (in fact, hoping I am). This is compatible with main Koha only, not backportable to 23.11 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #31 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Pedro Amorim from comment #30)

Updated from "Doesnt apply" to PQA but it was never PQA, it was SO. Changing it back.

I had looked at this one last when taking things out of the QA queue as mine was empty... similar situation now. I will come back for this later :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_24_11_candidate |release-notes-needed Status|Signed Off |Passed QA --- Comment #32 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Tested and works, will push to main. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #33 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 24.11! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 --- Comment #35 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #34)

Is this really working? It's hidden if there is no data, but it's displayed if there is at least one item with a source of acq.

Looks broken for the other columns as well but I am wondering why this has not been caught here.

Hm I thought that it was hidden by default was expected. I made it visible for testing and then tested with values linked to acq (booksellerid) and plain text entries. I'll need to take another look at what I missed there. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de --- Comment #36 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Can we obsolete comment #27, it always pops up in my candidate list, though it already was part of 24.11? This assumes that obsoleted comments are not searched. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182 Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting CC| |wainuiwitikapark@catalyst.n | |et.nz --- Comment #38 from Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> --- Hoping this is okay to close, changed to "Needs documenting" to get it off my list but feel free to change status if work/discussion is still needed -- You are receiving this mail because: You are watching all bug changes.