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

[Bug 28996] New: SendQueuedMessages exit on a bad email 'To' and following messages are never processed.
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '24

07 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28996 Bug ID: 28996 Summary: SendQueuedMessages exit on a bad email 'To' and following messages are never processed. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 22343 If there's a bad 'To' field email create die but it isn't caught by SendQueuedMessages. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22343 [Bug 22343] Add configuration options for SMTP servers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 23033] New: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '24

05 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23033 Bug ID: 23033 Summary: C4::Items::AddItemBatchFromMarc does not queue bib record for indexing Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Callers of C4::Items::AddItemBatchFromMarc must call ModZebra (directly or indirectly) afterwards, which strikes me as wrong. AddItemBatchFromMarc used to call C4::Biblio::ModBiblioMarc, which calls C4::Items::ModZebra[*] but the call to ModBiblioMarc was commented out in commit 3584c442 (2010-09-03 12:16:52 +0200, see bug #5579) and the comment was never removed. The only code in Koha 18.11 that calls AddItemBatchFromMarc is in migration_tools/bulkmarcimport.pl, which dutifully calls MobBiblioMarc once after each call to AddItemBatchFromMarc -- even(!) if AddItemBatchFromMarc fails, which seems weird but I don't fully understand the code. We could add a call to ModZebra in AddItemBatchFromMarc but I assume it would be better to reinstate the call to ModBiblioMarc. I'll attach a patch shortly. [*] C4::Items gets ModZebra from C4::Biblio, which implements and exports it, so my will also change this to a call to C4::Biblio::ModZebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24710] New: patron-title.inc should have seperate span classes for firstname, othername, surname
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '24

04 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24710 Bug ID: 24710 Summary: patron-title.inc should have seperate span classes for firstname, othername, surname Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would prefer to be able to customize how the name is displayed in the patron details. If these included <span> classes we could easily move/hide/reorder bits we don;t want. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 25691] New: Debian packages point to /usr/share/doc/koha/README.Debian which does not exist
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '24

02 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25691 Bug ID: 25691 Summary: Debian packages point to /usr/share/doc/koha/README.Debian which does not exist Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net debian/changelog: * Add notes about README.Debian to package description and postinst output. debian/control: Please see /usr/share/doc/koha/README.Debian for instructions on how to debian/control.in: Please see /usr/share/doc/koha/README.Debian for instructions on how to debian/koha.postinst:Please see /usr/share/doc/koha/README.Debian for instructions on how to -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 27298] New: Adjusting a Numbering Pattern will not show in receiving next issue
by bugzilla-daemon＠bugs.koha-community.org 01 Feb '24

01 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27298 Bug ID: 27298 Summary: Adjusting a Numbering Pattern will not show in receiving next issue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Publishers will sometimes change how their serials are numbered mid-year or a library may have their prediction pattern originally set up correctly, for whatever the reason, if a library edits an existing serial's prediction numbering pattern-the first expected issue after this change does not show the revised prediction. Steps: 1. Have a serial in which there is a numbering pattern and an issue has been received. For example, monthly magazine Vol. 25, No 3 2. Edit this existing subscription and alter the numbering pattern- to Vol 31 No.1. 3. Test this subscription and see Koha is accurately predicting the new numbering pattern of Vol 31 No. 1, Vol 31 No 2 etc. 4. Save subscription. 5. Attempt to receive that new issue, Vol 31, No.1 - see that Koha believes it is still receiving Vol 25, No 3. 6. Receive this issue, alter the enumeration for this issue. 7. Receive the next issue, and see Koha is successfully predicting the next issue Vol 31 No 2. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 25047] New: Tutorial for OPAC
by bugzilla-daemon＠bugs.koha-community.org 01 Feb '24

01 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25047 Bug ID: 25047 Summary: Tutorial for OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Has anyone considered working on a guided tutorial through the OPAC for new users? I'm talking about the OPAC guiding a new user through the different things they can do, with balloons that point out different things. At any point it could be skipped, or restarted. It would be great if there were an admin option panel for what pieces of the tutorial, and in what order, they would like patrons guided through (in case there are some elements that the library don't use). And it would be great if each section of the tutorial could be linked, so if someone asked about how to do something, we could like them to the specific tutorial for what they are asking about. I also see the possibility of being able to customize the tutorials (the balloons), or adding others. IF libraries could create a new tutorial, and tell each balloon what to point at and what to say, that would be great. It probably means that it should give a list of available element IDs for each page that the balloon could point to. Something like that. The tutorials could also track if they have ever been played on that browser (probably through a cookie) and if a new tutorial is added that a user hasn't seen, they can be given the option to go through it or skip it. This system could also be used for for information, similar to news, but for a specific section. For example, during the COVID-19 library closures, we could have used one of these balloons on the hold page to indicate that we are accepting hold requests, but holds are not being filled at this time. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 17755] New: Move C4::Members::AttributeTypes to Koha::* namespace
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '24

31 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17755 Bug ID: 17755 Summary: Move C4::Members::AttributeTypes to Koha::* namespace Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 23272] New: Koha::AuthorisedValue should use Koha::Object::Limit::Library
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '24

31 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23272 Bug ID: 23272 Summary: Koha::AuthorisedValue should use Koha::Object::Limit::Library Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::Patron::Attribute::Type should be used as example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 28366] New: Add batch patron modification to patron search results
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '24

31 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28366 Bug ID: 28366 Summary: Add batch patron modification to patron search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think it would be useful to be able to pass checked patron search results to batch patron modification without going through the step of adding them to a list. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 23487] New: Utf8mb4 collation causes problems with missing tables when upgrading the database
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '24

30 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23487 Bug ID: 23487 Summary: Utf8mb4 collation causes problems with missing tables when upgrading the database Change sponsored?: --- Product: Koha Version: unspecified 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: andreas.hedstrom.mace(a)sub.su.se QA Contact: testopia(a)bugs.koha-community.org Changing the default encoding to utf8mb4 and collation to utf8mb4_unicode_ci, can create duplicate unique keys as it ignores differences in accented characters vs non-accented characters. An example would be the Swedish letter ö, which is treated like the letter o. More is discussed here: https://stackoverflow.com/questions/47119794/mysql-mariadb-unable-to-handle… When upgrading a large database to any version with the new encoding and collation, there is a chance of duplicate unique keys crashing the collation change of the table (or tables) and as a result corrupting InnoDB tablespace. The final result is one or more tables that both exist and don't exist, and thus can't be deleted or created again. We, not so fondly, called them Schrödinger's tables. For Stockholm University Library, we had about 30 duplicate unique keys in the borrowers table (out of ~220K patrons), mostly in userid. Which crashed the database every time we tried to upgrade until we found the cause. The workaround solution was to change/remove these duplicates, but perhaps a better solution for the community would be to change the default encoding/collation for columns with unique keys? Perhaps utf8mb4_bin? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7