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

[Bug 1889] Virtual shelves leave blank field in staff intranet when BIB is deleted
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1889 Mathieu Saby <mathsabypro(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro(a)gmail.com --- Comment #1 from Mathieu Saby <mathsabypro(a)gmail.com> --- This bug has been fixed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41110] New: Add a "Work List" Option
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41110 Bug ID: 41110 Summary: Add a "Work List" Option Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: cgentry1(a)ju.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I am hoping that Koha will eventually have a third type of List - a "Work List". We have student workers processing some Special Collections items and other things in Koha but there is not a way currently WITHIN Koha to gather up a set of records and display them together for the group of student workers and their supervisor to see. that is the pool of viewers - a specific few users and a staff account. So instead, these lists are being made as public lists for the student workers to also be able to view and edit but they are also displaying in the OPAC. I also run into this issue on the collection development side - I would like to be able to create a work list for me and my tech services person to see to change spine labels, put into a different location, or to find for a specific project and there is not a really easy, intuitive way to do that. We currently use the cataloging concern tickets (which are great for one-offs) but it would definitely be preferable if there was a Work List or Internal List function - something between a publicly viewable list and a private list. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41400] New: Support the use of distinct values for record-level types and item-level types
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41400 Bug ID: 41400 Summary: Support the use of distinct values for record-level types and item-level types Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Following the discussions under Bug 38042, I propose this enhancement : support the use of distinct values for record-level types (biblioitems.itemtype) and item-level types (items.itype). The way Koha manages item and record type is different from most ILS, and does not allow the flexibility required to manage a library network if it is not made possible to use different values in biblioitems.itemtype and item-level types. Many libraries, particularly in France, have been using different values for several decades, probably since the introduction of Koha in France. But currently this configuration can cause issues (cf Bug 38042). Use case : - Book1 and Book2 are owned by Library1 and Library2. - circulation rules are based on item-level itemtype - at the record level, the type for the 2 records is "book" - Library1 wants to apply the standard circulation rule to Book1 and Book2 (thus using the same value in item-level itemtype, eg. "NORMALLOAN") - Library2 wants to restrict the use of book1 by applying a specific circulation rule, but agree to apply the standard rule to Book2 (thus using distinct values in item-level itemtype, eg. "NORMALLOAN" and "SHORTLOAN") -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 14587] Acq: Make it possible to edit asort1 and asort2 values on receive
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14587 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14587] Acq: Make it possible to edit asort1 and asort2 values on receive
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14587 --- Comment #2 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Actually, I believe this is fixed :) If you are on the invoice summary, there is a link "Edit fund". This modal also has the sort values for editing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14587] Acq: Make it possible to edit asort1 and asort2 values on receive
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14587 --- Comment #1 from Mathieu Saby <mathsabypro(a)gmail.com> --- Still valid. Sometimes we need to change those fields after the reception is done. It is a nightmare to do. We should be able to easily change these values, with the proper permissions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41507] New: bulkmarcimport.pl: When deleting autorities prior to import, reset auto_increment
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41507 Bug ID: 41507 Summary: bulkmarcimport.pl: When deleting autorities prior to import, reset auto_increment Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz bulkmarcimport.pl allows you to delete all existing authorities in the database using the -d -a parameters on import. We should also set auto_increment in auth_header to 1 when this is done. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28231] New: MARC modification template "1st" vs "Every" bug?
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28231 Bug ID: 28231 Summary: MARC modification template "1st" vs "Every" bug? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 120184 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120184&action=e… MARC authority record with two 151$x Hi all, I think this is a bug, if someone could confirm, I would appreciate it! In MARC modification templates, we have the option of choosing to modify the first or every field specified. But when trying to delete only the first occurrence of a subfield, it deletes every subfield anyway. To test: 1) Create an authority record with two 151$x, one containing [BLANK] and the other containing real information (I've attached my authority record if you want to simply import it) 2) Go to Tools > MARC modification templates 3) Create a new template 4) Add the following action Delete 1st field(s) 151 x if field 151 x matches [BLANK] 5) Go to Tools > Batch record modification 6) Fill in the form Record type: Authorities Enter a list of record numbers: enter the authid of your authority record Modify record using the following template: Template created previously 7) Click Continue 8) Click "Show MARC" Both 151$x are deleted, rather than just the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29331] New: Batch edit items.itemlost
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29331 Bug ID: 29331 Summary: Batch edit items.itemlost Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: katrin.fischer(a)bsz-bw.de, nick(a)bywatersolutions.com, oleonard(a)myacpl.org >From IRC "I think Bug 28445 broke the ability to batch update lost status" So I fixed it, but actually it was not possible before 28445. Do we want it? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 34274] New: In batch patron modification adding a new attribute clears all existing values and applies authorised values to all attributes
by bugzilla-daemon＠bugs.koha-community.org 31 Dec '25

31 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34274 Bug ID: 34274 Summary: In batch patron modification adding a new attribute clears all existing values and applies authorised values to all attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: 1 - Define 2 new patron attributes types, both marked repeatable: Repeatable Duplicatable - linked to authorised value 'YES_NO' 2 - Perform a batch patron modification 3 - Select attribute type 'Repeatable' and enter 'Repetition' 4 - Click - +New to add a second attribute 5 - Set the type to 'Duplicatable' 6 - WRONG - values are cleared and Repeatable is now a YES_NO dropdown -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3