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

[Bug 24233] New: Library branches editor doesn't allow email addresses with a name
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '21

13 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24233 Bug ID: 24233 Summary: Library branches editor doesn't allow email addresses with a name Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org So, when we send email via koha, we set the from field to just the branch email address ( e.g. "us(a)library.org" ). Some libraries would like to be able to have the library name as part of the email address ( e.g. "Your Library <us(a)library.org>" ). The problem is that this does not pass validation in the branches editor. We know this format works because some libraries set this email format before the syntax validation was implemented. We should update the validation algorithm to allow for the latter format in addition to the former. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 24766] New: Provide an option to show news blocks for all available languages
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '21

12 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24766 Bug ID: 24766 Summary: Provide an option to show news blocks for all available languages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Blocks: 22318 With the move of the HTML system preferences to the news tool, adding a logo to the OPAC will require that you add a news block for it to each installed language. If you add languages later on, you will always need to test and remember. This adds quite a bit of extra maintenance as there appears to be no fallback option. It would be nice if we could define that something should show for 'all languages' or as a 'fallback' if there is no other content for the language defined. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22318 [Bug 22318] Extend Koha news feature to include other content areas -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 22663] New: Improve usability of 'display location' pull down in news editor
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '21

12 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22663 Bug ID: 22663 Summary: Improve usability of 'display location' pull down in news editor 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- At the moment with every language installed, there are new entries added to the display location pull down in the news editor: OPAC (en), OPAC (de-DE). With the possible addition of bug 22318 this list will grow quite long and might get harder to work with. I think this could be improved in different ways: 1) Only have the location in the pull down and then tabs for the different languages like we have for notices. That would also allow a quickly copy and paste between different versions to help with translating. 2) Break up the pull down into 2 pull downs: display location and language. 3) Group by content area first and then language below, so all entries of the same type are listed together. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 24346] New: News needs to be able to display on the self checkout / checkin modules
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '21

12 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24346 Bug ID: 24346 Summary: News needs to be able to display on the self checkout / checkin modules 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if there were a side panel on the login screen for news. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21286] New: Advanced search for Corporate-name creates Zebra errors
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '21

11 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21286 Bug ID: 21286 Summary: Advanced search for Corporate-name creates Zebra errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au If you're in the advanced search in the staff client, and if you're using the QueryWeightFields system preference, and if you're searching with "Corporate-name", you'll generate Zebra errors. There are a few things contributing to this problem. One is that Corporate-name is only indexed into the "word" register and not the "phrase" register. This becomes a problem with QueryWeightFields, because of the last conditional block in C4::Search::_build_weighted_query() which rewrites the search query to include $index,ext,r1, which forces a search of the "phrase" register, which causes Zebra to explode (when it doesn't use the 14=1 special attribute). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 18112] New: opac-memberentry.pl doesn't contain streettype field
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '21

10 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18112 Bug ID: 18112 Summary: opac-memberentry.pl doesn't contain streettype field Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: corinne.hayet(a)progilone.fr QA Contact: testopia(a)bugs.koha-community.org streettype is missing in opac-memberentry.pl, we cannot have a complete address -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 26838] New: Improve styling of checkin message
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26838 Bug ID: 26838 Summary: Improve styling of checkin message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 112596 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=112596&action=e… Checkin message box When an item type has a checkin message of the type "message" (rather than "alert"), the styling of the box is weird. The box is blue, but the background of the text is yellow. To replicate: 1) Go to Administration > Item types 2) Edit an item type and include a checkin message, the checkin message type should be "message" 3) Check in an item of that type I attached a screen capture of the blue/yellow message. In the manual, we can see what it used to look like : https://koha-community.org/manual/20.11/en/html/_images/itemtype-msg.png -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15969] New: Allow use of Template Toolkit syntax for Phone Notices
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15969 Bug ID: 15969 Summary: Allow use of Template Toolkit syntax for Phone Notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org By allowing the use of Template Toolkit for generating the outgoing Talking Tech CSV files, we can give libaries more control over the data they send to Itiva. This enhancement would also make it possible to use the script for other services since the output is no longer fixed to a single format. -- You are receiving this mail because: You are watching all bug changes.

1 75

[Bug 21091] New: Move add item template JavaScript to a separate file
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '21

08 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21091 Bug ID: 21091 Summary: Move add item template JavaScript to a separate file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I would like to modify the add item template (additem.tt) to move JavaScript from the <head> to separate files: cataloging_additem.js and cataloging_additem.inc (for defining translatable strings used in the js). -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 25189] New: Make AutoCreateAuthorities less of a footgun with LinkerModule: Default
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '21

07 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25189 Bug ID: 25189 Summary: Make AutoCreateAuthorities less of a footgun with LinkerModule: Default Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you read every word of the description of AutoCreateAuthorities in the system prefs page, and then read every word about it in the manual, even if you also read every word in the description and in the manual about LinkerModule, you'll have no idea that by turning on AutoCreateAuthorities without changing LinkerModule from its default value of Default, you've just given yourself infinite authority duplicates. The behavior of LinkerModule: Default is to link a field in a bib to an authority when there is one and only one matching authority record. Without AutoCreateAuthorities, that means if you have zero matches or two or more matches, the field is unlinked. Fine, no problem. With AutoCreateAuthorities on, the behavior is that if there are zero matches, an authority record is created, if there is one match, the field is linked to that existing authority record, if there are two matches a third duplicate authority is created, and if there are three matches, a fourth duplicate match is created, and if there are 2661 matches, a 2662nd duplicate match is created (that being how many authority records my system had for the genre Thrillers (Fiction) when I noticed this behavior). Two ways to not create infinite duplicates occur to me: Change what a LinkerModule returns, so it returns the match, whether it was a fuzzy match, and also whether more than one match was found, so that in the AutoCreateAuthorities case when more than one was found it can be left unlinked rather than creating another duplicate, or, Have C4/Linker/Default.pm check whether AutoCreateAuthorities is on, and if it is and $behavior isn't either first or last, just force it to first rather than creating infinite duplicates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29