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

[Bug 22206] New: Add route to handle holds suspensions
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '21

03 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22206 Bug ID: 22206 Summary: Add route to handle holds suspensions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 20168] New: update to bootstrap v4
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '21

02 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20168 Bug ID: 20168 Summary: update to bootstrap v4 Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: elias.dehler(a)thulb.uni-jena.de QA Contact: testopia(a)bugs.koha-community.org I'm currently working on updating the bootstrap template to bootstrap v4. This requires to update jQuery as well. My work is based on the current 17.11.02 koha release. I'm trying to keep the design as close to the current design as possible. At the moment i have nothing to show of my current process but as soon as everything plays nice i will post a link to my repository. The goal is to get a template based on the current version of bootstrap. -- You are receiving this mail because: You are watching all bug changes.

1 78

[Bug 19206] New: How should we sort 19xx when order is pubdate?
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '21

02 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19206 Bug ID: 19206 Summary: How should we sort 19xx when order is pubdate? 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org On bug 11046 I proposed to sort e.g. 19xx with 1900. This relates to the kohafield copyrightdate used to sort lists and in reports. For search results, the sort on publication date depends on pubdate as indexed by Zebra. If we add uncertain years like 19xx or better 19uu in the MARC21 008, they will be sorted after 1999 (current situation). We could add a "fix_008" in rebuild_zebra (just as a few other fixes already there) and replace 19uu by 1900 when indexing in order to get 19xx sorted with 1900. What do you think ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 19297] New: Standardize "can place hold" calculations
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '21

29 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19297 Bug ID: 19297 Summary: Standardize "can place hold" calculations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org There are several places where we need to know if a hold can be placed on a bibliographic record, or an item. And we also have several way of calculate it... Sometimes it is buggy, sometimes we calculate the information for nothing, sometimes it is done correctly. We need to make this calculation uniform in order to be consistent and always display the same and correct information everywhere. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 21484] New: Show the parent record's component parts in the detailed views - Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '21

29 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21484 Bug ID: 21484 Summary: Show the parent record's component parts in the detailed views - Elasticsearch 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is follow-up for bug 11175 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 19821] New: Run tests on a separate database
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '21

29 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19821 Bug ID: 19821 Summary: Run tests on a separate database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Running the tests on the same database as the one used for dev has some drawbacks: - Everybody has different data, so we cannot make any assumptions about data in tests and it can make tests fail for non-obvious reasons. - Tests have to clean up every change to the database using SQL transactions, so we cannot write testable code that use transactions (AFAIK) - Transactions in tests happen to be committed sometimes, resulting in garbage data added to the dev database I'll send a patch that allows to run tests in a separate database in order to address these issues. -- You are receiving this mail because: You are watching all bug changes.

1 106

[Bug 22466] New: TT methods must not be escaped
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '21

28 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22466 Bug ID: 22466 Summary: TT methods must not be escaped Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Templates Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21576 Target Milestone: --- They could (it will not break anything) but it does not make sense. So far the QA script is failing if they are not. For instance: [% my_array.push(a_var) %] Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21576 [Bug 21576] Add a developer script to automatically fix missing filters -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 20277] New: Link to host item doesn't work in analytical records if 773$a is present
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '21

26 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20277 Bug ID: 20277 Summary: Link to host item doesn't work in analytical records if 773$a is present Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org A lot of analytical records are made for serials. And for most of them the title is their primary access point. The OPAC and intranet link in the analytical record to the host item works well in these cases. But if you have a 1XX field in your host item, this information goes in your 773$a subfield but the OPAC and intranet link in the analytical record to the host item includes 773$a and 773$t data but searches only in the title index. In this situation you can't retrieve the host item record. Test: - Create an analytical record for a (host)record with a 1XX field. - Use the link in the analytical ("In" note) to retrieve the host record in the intranet client and the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 16446] New: Allow librarians to add borrowers to lists by borrowernumber or cardnumber
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '21

22 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16446 Bug ID: 16446 Summary: Allow librarians to add borrowers to lists by borrowernumber or cardnumber Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice to be able to add borrowers to lists based on a supplied list of cardnumbers or borrowernumbers (that they could get from a report, for example). -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 22614] New: Request migration from one backend to another should not create new request
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '21

21 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22614 Bug ID: 22614 Summary: Request migration from one backend to another should not create new request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Target Milestone: --- Currently, when requests are migrated from one backend to another, a new request is created containing the attributes of the existing one but with the backend set to the migration destination backend and the metadata is derived from the migration destination backend. The existing request is then marked as reverted and a record is made of where the request was migrated to. The downside of this approach is that two requests now exist in the system, whereas in actual fact, it's still the same request. This can be problematic for statistics etc. This bug proposes that request migration should preserve the original request and, instead, change its backend and replace the metadata from the original backend to that of the migration destination backend. Also, we should log where the request has been migrated from and to. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18