https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36182
--- Comment #3 from Katrin Fischer <[email protected]> --- [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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
