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

[Bug 20670] New: Add markup and standard classes for sidebars and main content areas
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '23

21 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20670 Bug ID: 20670 Summary: Add markup and standard classes for sidebars and main content areas 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 Blocks: 14546 As we move away from YUI grids, it would be helpful if we could consistently add some classes to the primary sections of the page. That would allow us to style elements differently based on their container's class. I've already begun adding a "main" class to the <div> which is the primary "container" for the Bootstrap grid. It typically looks like this: <div class="main container-fluid"> <div class="row"> <div class="col-sm-5 col-md-4"> I would like to add an additional container that wraps the primary content region for the page. This container should have no style attached to it (as it might interfere with grid layout), but can serve as a context for styles within it. ----------------------------------------------- * .main * * ------------------------------------------- * * * * .main-content * * * * * * * * * .sidebar * -------------------------- * * * * * * * * * * * * * .row * * * * * * * .col-* * * * * * * * ...etc. * * * * * * -------------------------- * * * * * * * * ------------------------------------------- * * * ----------------------------------------------- The use I have right away is to style forms differently based on whether they are in the sidebar or the main-content area. Right now we have some CSS which depends on YUI grid classes, and we need to replace that which isn't dependent on the grid system we choose. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14546 [Bug 14546] Make staff client templates responsive -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 15977] New: Optional double screen message in Patron Info/Status
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '23

20 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15977 Bug ID: 15977 Summary: Optional double screen message in Patron Info/Status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com This code in MsgType.pm: $resp .= maybe_add( FID_SCREEN_MSG, $patron->{branchcode}, $server ) if ( $server->{account}->{send_patron_home_library_in_af} ); produces two AFs if you enable that attribute in your config. Not sure if that should be the case and is conform protocol. Also: are we solving a problem here in the wrong place? It looks kind of inappropriate use.. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 22317] New: Performance issues with large number of funds
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '23

17 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22317 Bug ID: 22317 Summary: Performance issues with large number of funds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The acquisitions landing page displays a summary table for the funds. This can sometimes be very large and cause a significant lag in the page load and display. Ultimately, it would be nice to fix this performance issue at the root. (There is initially a fairly prominent server lag, but there is also a clear difference between rendering time in Chrome/Firefox vs in IE). As a 'quick fix' it may be enough to make the display of that summary table syspref controlled so libraries with a large number of funds defined can choose not to display the summary on that page to improve the performance of page load so they can proceed to Vendor searches and other acquisitions actions available from that page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 22221] New: Changing an item to a Lost Status on an item level hold does not change the hold
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '23

17 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22221 Bug ID: 22221 Summary: Changing an item to a Lost Status on an item level hold does not change the hold Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- If a library is using Item Level holds and a patron places a specific item hold. If the library finds that this specific item is missing, they can change the item to missing, however, the hold is still attached to this item. The library then needs to remove the item level hold and re-attach it to another item or make it a bib level hold. It would be nice, if this change of "Lost" status of this item is altered, the hold can be changed to a bib level hold or an easy ability to adjust the hold as necessary. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 19098] New: Additional logic for 260/RDA 264 fields
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '23

17 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19098 Bug ID: 19098 Summary: Additional logic for 260/RDA 264 fields 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If we have implemented 10306 and 19096, we can add some additional logic for multiple RDA 264 fields. Making e.g. the place and year picked more accurate than just glueing together or picking the first one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 23124] New: trailing spaces in DefaultPatronSearchFields can break patron searching
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '23

17 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23124 Bug ID: 23124 Summary: trailing spaces in DefaultPatronSearchFields can break patron searching Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- We should probably just trim this string on save? To recreate: 1 - Add a trailing space to DefaultPatronSearchFields 2 - Attempt to search for patrons 3 - Error! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 21106] New: oai.pl XML output doesn't validate against OAI-PMH XML schema
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21106 Bug ID: 21106 Summary: oai.pl XML output doesn't validate against OAI-PMH XML schema Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 21102 When using some verbs Koha return a well formed but in invalid XML. CLI test: wget -q "https://www.openarchives.org/OAI/2.0/OAI-PMH.xsd" wget -q "https://demo.bibkat.no/cgi-bin/koha/oai.pl?verb=ListSets" -O test.xml xmllint --noout --schema OAI-PMH.xsd test.xml Web test: An online way to test this is with http://validator.oaipmh.com/ 1. verb=ListSets: When no set is defined Koha incorrectly output <ListSets/>. A set (child element of ListSets) should always be there, minOccurs default value is 1. Otherwhise should be: <error code="noSetHierarchy">No sets defined</error>, AFAIK even if tehere is no error. 2. verb=Identify: setDescription is not a string, is descriptionType ##other, "defined by a community" (?) See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17785#c13 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21102 [Bug 21102] OAI-PMH specification conformance [UMBRELLA] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24407] New: AuthDisplayHierarchies ignores new nodes and needs protection against cyclic relations
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '23

16 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24407 Bug ID: 24407 Summary: AuthDisplayHierarchies ignores new nodes and needs protection against cyclic relations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Suppose I have term A with children B and C where the children have a 550 tag with broader indication to A. If I go to record A, the tree is built showing B and C. If I add a child D to A, the tree for A is not rebuilt but still showing the old situation. A related problem: If I change term A setting it to a be child of B with a 550 (which it obviously not is), this cyclic relation will trigger deep recursion. Resulting in a gateway timeout and a process eating up resources.. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 24480] New: Fields added with Marc modifications templates are not added in an ordered way
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '23

14 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24480 Bug ID: 24480 Summary: Fields added with Marc modifications templates are not added in an ordered way 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: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org they are instead appended to the end of the record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 26554] New: allow news tag in all slips
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26554 Bug ID: 26554 Summary: allow news tag in all slips Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)trust-box.at QA Contact: testopia(a)bugs.koha-community.org Hi all & thanks, as far I understand it, the <news> tag works only in ISSUESLIP. Is there a good reason for this? For us it would be usefull if we could include the news section in all communications/slips cheers & thx Mark -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2