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

[Bug 20595] New: EDI: Add support for LRP (Library Rotation Plan) for Koha with Stock Rotation enabled
by bugzilla-daemon＠bugs.koha-community.org 24 Nov '23

24 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20595 Bug ID: 20595 Summary: EDI: Add support for LRP (Library Rotation Plan) for Koha with Stock Rotation enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature 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 CC: alex.sassmannshausen(a)gmail.com, andrew.isherwood(a)ptfs-europe.com, fiona.borthwick(a)ptfs-europe.com, gmcharlt(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, jonathan.field(a)ptfs-europe.com, josef.moravec(a)gmail.com, katrin.fischer(a)bsz-bw.de, kyle.m.hall(a)gmail.com, kyle(a)bywatersolutions.com, lisetteslatah(a)gmail.com, liz(a)catalyst.net.nz, sally.healey(a)cheshiresharedservices.gov.uk, tomascohen(a)gmail.com Depends on: 11897, 14187, 18137 This submission will add the support for the Edifact LRP field in Koha, using the field to automatically add ordered items to stock rotation plans. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11897 [Bug 11897] Stock Rotation for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14187 [Bug 14187] branchtransfer needs a primary key (id) for DBIx and common sense. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18137 [Bug 18137] Migrate from Mojolicious::Plugin::Swagger2 to Mojolicious::Plugin::OpenAPI -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[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 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 18827] New: Elasticsearch mappings - not displayed or retrieved in saved order
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '23

07 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18827 Bug ID: 18827 Summary: Elasticsearch mappings - not displayed or retrieved in saved order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The mappings listed under 'Biblios' and 'Authorities' are draggable - this allows ordering of fields. The ordering affects the id field in the search_marc_map table When retrieving for display or mapping we are not ordering by the this field. In general I am not sure if we are gaining anything with this ordering: https://www.elastic.co/guide/en/elasticsearch/guide/current/_sorting.html " When sorting on fields with more than one value, remember that the values do not have any intrinsic order; a multivalue field is just a bag of values. Which one do you choose to sort on?" I think we can switch to the idea that a single field per index should be chosen for ordering: author = 100 (only make this one sortable) author = 700 author = 245c or, in the case of authorities, we should expect a single field to populate the field for sorting (100, 110, 150 ... are alldefined as 'main-heading' - but each record should only have a single one of these field) -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 19885] New: Allow MaxOpenSuggestions to be set by patron type
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19885 Bug ID: 19885 Summary: Allow MaxOpenSuggestions to be set by patron type 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if we could set MaxOpenSuggestions by patron type/library. This would allow each library in a consortium to use the suggestions in the way that was most efficient for each library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 19062] New: Don't queue check-in/ checkout messages if patron has no e-mail
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '23

29 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19062 Bug ID: 19062 Summary: Don't queue check-in/checkout messages if patron has no e-mail Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org If the patron has no e-mail address we should not queue a check-in or checkout message. If later on an e-mail address is added to the patron account all the old messages could be sent out by accident. Check out and check in messages are only interesting close to the checkout/checkin process, later on, they are just confusing to patrons. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 20676] New: svc/barcode should allow barcode to be printed without text
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '23

28 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20676 Bug ID: 20676 Summary: svc/barcode should allow barcode to be printed without text Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org svc/barcode currently generates the barcode using $image = GD::Barcode->new( $type, $barcode )->plot()->png(); >From perldoc GD::Barcode plot() $oGd = $oGdBar->plot([Height => $iHeight, NoText => 0 | 1]); creates GD object with barcode image for the $sTxt specified at new method. $iHeight is height of the image. If NoText is 1, the image has no text image of $sTxt. ex. my $oGdB = GD::Barcode->new('EAN13', '123456789012'); my $oGD = $oGdB->plot(NoText=>1, Height => 20); # $sGD is a GD image with Height=>20 pixels, with no text. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 17228] New: Make two versions of SIPconfig.xml identical
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '23

23 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17228 Bug ID: 17228 Summary: Make two versions of SIPconfig.xml identical Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net We have two versions of SIPconfig.xml: etc/SIPconfig.xml debian/templates/SIPconfig.xml The former has been updated with some changes to the possible configuration of SIP2 servers, e.g. by bug 15006. The latter has not been updated with the same information. Since debian/templates/SIPconfig.xml contains no special placeholders or variables, this bug proposes to simply copy etc/SIPconfig.xml to debian/templates/SIPconfig.xml, so that admins using the packages will see an up-to-date SIP2 config example when they have enabled SIP2 for a site. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 18094] New: Patron search filters are broken by searchable attributes
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '23

20 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18094 Bug ID: 18094 Summary: Patron search filters are broken by searchable attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com When using searchable patron attributes they seem to be added to all searches as a contain To recreate: Add a new patron attrbute and mark it searchable Populate a new patron with 'potato' in that field Add/edit another patron to have email potato(a)invalidemail.com' Perform a patron search with filters 'Email' and 'Starts with' and query 'potato' You will see both patrons in your results Remove the potato email Perform search again You will be directed to the patron containing the potato attribute -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27