If you add an item to a bundle, it's supposed to show "Not for loan (Added to bundle); In bundle: <bundle title>". This works in OPAC, but not in staff interface. The cause is erroneous check `[% IF bundlesEnabled %]` before the parent bundle information is requested+shown. The `bundlesEnabled` variable checks if the current biblio ITSELF is of collection type, so should only be used for whether to show the button to add new items to the bundle items, NOT for querying whether current item is part of a bundle, as the items that make up the bundle aren't of collection type themselves. To reproduce: 1. Have two biblio records record 1 = normal record, not a collection record 2 = in leader 000, 7- Bibliographic level must be set to c- Collection 2. Add an item with some kind of barcode to each. 3. In record 2 in staff interface, next to the item, click "Manage bundle" and then "Add to bundle", enter the barcode of the item of record 1, and confirm. 4. Open record 1 in OPAC, you will see that the item is not for loan/part of bundle, you will see "In bundle:" followed by a link to record 2. 5. Open record 1 in staff interface, you will see that the "In bundle:" link is missing! (that's the bug)
Created attachment 169081 [details] [review] Bug 37393: fix "In bundle:" link not showing for items in staff interface The cause was erroneous check `[% IF bundlesEnabled %]` before the parent bundle information is requested+shown. The `bundlesEnabled` variable checks if the current biblio ITSELF is of collection type, so should only be used for whether to show the button to add new items to the bundle items, NOT for querying whether current item is part of a bundle, as the items that make up the bundle aren't of collection type themselves. The second fixed problem was that `bundle_host` didn't contain `.biblio` subitem (which'd contain the actual host biblio title) as the JavaScript code assumed, and it wasn't possible to request it with the API either. Test plan: please follow the reproduction instructions from bug and ensure that the described issue is gone. If you run into an error 400 on the detail page, you need to refresh API definitions, in kts shell you'drun: redocly bundle --ext json api/v1/swagger/swagger.yaml --output api/v1/swagger/swagger_bundle.json koha-plack --restart kohadev
Created attachment 169162 [details] [review] Bug 37393: fix "In bundle:" link not showing for items in staff interface The cause was erroneous check `[% IF bundlesEnabled %]` before the parent bundle information is requested+shown. The `bundlesEnabled` variable checks if the current biblio ITSELF is of collection type, so should only be used for whether to show the button to add new items to the bundle items, NOT for querying whether current item is part of a bundle, as the items that make up the bundle aren't of collection type themselves. The second fixed problem was that `bundle_host` didn't contain `.biblio` subitem (which'd contain the actual host biblio title) as the JavaScript code assumed, and it wasn't possible to request it with the API either. Test plan: please follow the reproduction instructions from bug and ensure that the described issue is gone. If you run into an error 400 on the detail page, you need to refresh API definitions, in kts shell you'drun: redocly bundle --ext json api/v1/swagger/swagger.yaml --output api/v1/swagger/swagger_bundle.json koha-plack --restart kohadev Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Please fix email address of commit author
The e-mail is configured as intended, this is GitHub e-mails that assign commit attribution to users (https://github.com/Koha-Community/Koha/commits?author=mkibp) on the site while providing privacy protection at the same time: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address I have previously contributed to Koha several times with this e-mail provided and there's nothing in the contribution guidelines that would hint against that, so I don't see a reason for this to be a hindrance. Otherwise a "real" reachable e-mail may be extracted from commits by bots and then spammed to death, while real people would comment on the offending commit's Bug on the Bugzilla if they wanted to reach out to the author and CC'd people about the changes that were previously introduced, as does happen sometimes. E-mails from Bugzilla can also be nicely filtered by people and sorted into folders on their e-mail client/servers and assigned into "conversation history" view, while random personal e-mails wouldn't.
(In reply to Michał from comment #4) > The e-mail is configured as intended, this is GitHub e-mails that assign > commit attribution to users > (https://github.com/Koha-Community/Koha/commits?author=mkibp) on the site > while providing privacy protection at the same time: > https://docs.github.com/en/account-and-profile/setting-up-and-managing-your- > personal-account-on-github/managing-email-preferences/setting-your-commit- > email-address > > I have previously contributed to Koha several times with this e-mail > provided and there's nothing in the contribution guidelines that would hint > against that, so I don't see a reason for this to be a hindrance. > > Otherwise a "real" reachable e-mail may be extracted from commits by bots > and then spammed to death, while real people would comment on the offending > commit's Bug on the Bugzilla if they wanted to reach out to the author and > CC'd people about the changes that were previously introduced, as does > happen sometimes. E-mails from Bugzilla can also be nicely filtered by > people and sorted into folders on their e-mail client/servers and assigned > into "conversation history" view, while random personal e-mails wouldn't. Thanks for explaining.