August 2024 - Koha-bugs - lists.koha-community.org

[Bug 37738] New: Framework update accessibility for existing installations
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37738 Bug ID: 37738 Summary: Framework update accessibility for existing installations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if updated frameworks were available for download in some way. As frameworks are periodically updated in Koha to stay up-to-date with Library of Congress changes. it becomes difficult for existing installations to know about/receive those updates. While it is possible for existing installations to monitor bugs and see what the changes are, they don't receive those updates in the frameworks with an upgrade. This requires a library to seek out the bugs and do manual updates. There may be a number of ways to alert a library that updates are available and/or provide a download of the new framework. Perhaps there could be an alert in Administration that says updates are available, with a link to download the new framework from somewhere. This way a library can choose whether to overlay or manually update a framework as needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 32168] New: Editing date/datetime fields without the dateaccessioned.pl plugin can cause errors
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32168 Bug ID: 32168 Summary: Editing date/datetime fields without the dateaccessioned.pl plugin can cause errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When editing items that are date or datetime formatted without the dateaccessioned cataloging plugin it is quite easy to cause an error. To recreate: 1. Make sure some 952 field with dates (datelastseen, dateaccessioned ) are visible in the editor but make sure the dateaccessiond plugin is turned off. 2. Set the date format system preference to mm/dd/yyyy 3. Edit an item and attempt to edit one of the date fields to something in the correct dateformat, like 11/11/2018. 4. You get an error as Koha is expecting the SQL date type format of YYYY-MM-DD. I'm not sure how to best solve this. My first thought is that we should require the dateaccessioned.pl plugin on date fields. Or we could add a hint about format? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 20954] New: Add ability to set syspref overrides in SIP as we can in apache
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20954 Bug ID: 20954 Summary: Add ability to set syspref overrides in SIP as we can in apache Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com We should be able to set system preference overrides for SIP in a similar manner that we do in Apache. It would be great if we could specify those overrides on both a config level, and login level basis. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 37523] New: CSRF error when modifying an existing patron record
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37523 Bug ID: 37523 Summary: CSRF error when modifying an existing patron record Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When Koha finds a duplicate patron and you are trying to modify it, Koha will throw an error: Programming error - op 'edit_form' must start with 'cud-' for POST http://127.0.0.1:8081/intranet/members/memberentry.pl (referer: http://127.0.0.1:8081/cgi-bin/koha/members/memberentry.pl) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 37551] New: MarcFieldsToOrder price is overriding MarcItemFieldsToOrderPrice
by bugzilla-daemon＠bugs.koha-community.org 30 Dec '24

30 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37551 Bug ID: 37551 Summary: MarcFieldsToOrder price is overriding MarcItemFieldsToOrderPrice Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the code: # Price is handled as "itemprice" in the UI form to distinguish from MarcFieldsToOrder $iteminfos->{itemprice} = delete $iteminfos->{price} if $iteminfos->{price}; and later $iteminfos->{price} ||= $price; # Fallback to order price if no item price was defined Well, this means we will always fallback, because we deleted it. itemprice is the variable name when processing the form, but for populating we use 'price' I touched all of these lines, so I am blamed, but seems a clear mistake -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 37501] New: Titles table in ERM needs selection tools, batch tools
by bugzilla-daemon＠bugs.koha-community.org 30 Dec '24

30 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37501 Bug ID: 37501 Summary: Titles table in ERM needs selection tools, batch tools Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Similar to elsewhere in Koha, the Titles and Packages tables need a select all, clear all, individual selection boxes that can work with batch tools like batch deletion. If a library imports a 1,000 titles, deleting or removing titles in a batch is not possible. It is possible to delete individual titles by using the delete button at the end of the row, but this task becomes tedious with so many titles. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 37721] New: Add Donors to Acquisitions
by bugzilla-daemon＠bugs.koha-community.org 30 Dec '24

30 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37721 Bug ID: 37721 Summary: Add Donors to Acquisitions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be a nice enhancement to be able to separate Donors from Vendors. Right now some libraries are using Vendors to track Donors. Overtime, this creates an unmanageable number of vendors not used for day-to-day ordering or receiving. Libraries like to create baskets and add donor items via Acquisitions because it enables them to track the value of donations. This expands some of the ideas in Bug 37674 and Bug 37677. There may be a number of approaches on how to implement this. If a Vendor had a donor flag, the donor could live on a separate table, but still be available to use when an item is "ordered" through acquisitions. If there was a Donor page with its own result list, it opens up some interesting tracking possibilities and the ability to search Donors separately from Vendors. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32782] New: UNIMARC support
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '24

29 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32782 Bug ID: 32782 Summary: UNIMARC support Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32030 I need UNIMARC equivalence for the following values: my $publication_title = $biblio->title; my $print_identifier = $record->subfield( '020', 'a' ) || $record->subfield( '020', 'z' ) || $record->subfield( '022', 'a' ) || $record->subfield( '022', 'y' ); my $online_identifier = $print_identifier; my ( $date_first_issue_online, $date_last_issue_online ) = $fix_coverage->( $record->subfield( '866', 'a' ) ); my ( $num_first_vol_online, $num_last_vol_online ) = $fix_coverage->( $record->subfield( '863', 'a' ) ); my ( $num_first_issue_online, $num_last_issue_online ) = ( '', '' ); # FIXME ? my $title_url = $record->subfield( '856', 'u' ); my $first_author = $biblio->author; my $embargo_info = ''; # FIXME ? my $coverage_depth = $title_url ? 'fulltext' : 'print'; my $notes = $record->subfield( '852', 'z' ); my $publisher_name = $record->subfield( '260', 'b' ); my $publication_type = ''; # FIXME ? my $date_monograph_published_print = ''; # FIXME ? my $date_monograph_published_online = ''; # FIXME ? my $monograph_volume = ''; # FIXME ? my $monograph_edition = ''; # FIXME ? my $first_editor = ''; # FIXME ? my $parent_publication_title_id = ''; # FIXME ? my $preceeding_publication_title_id = ''; # FIXME ? my $access_type = ''; # FIXME ? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 37393] New: Bundle items don't show their host in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '24

29 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37393 Bug ID: 37393 Summary: Bundle items don't show their host in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Staff interface Assignee: schodkowy.omegi-0r(a)icloud.com Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com 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) -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 37292] New: Add an index on expires column for oauth_access_tokens
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '24

29 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37292 Bug ID: 37292 Summary: Add an index on expires column for oauth_access_tokens Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It was suggested by our DB admin to add this to make purging old records easier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17