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

[Bug 7607] Advanced search: Index and search term don't match when leaving fields empty
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7607 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #113691|0 |1 is obsolete| | --- Comment #49 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 113872 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113872&action=e… Bug 7607: Remove empty inputs when submitting search form This patch surrounds the operator, index, and query fields on the advanced search page wtih a 'search_set' class. This allows us to process them as a group and confirm the query is populated before submitting the other parts to the form TO test: 1 - Go to advanced search 2 - Use search boxes to search like: Title: (leave blank) Author: clinton keyword: shuffle 3 - Perform search 4 - Note no results as you searched for title:clinton etc. 5 - apply patch 6 - refresh and repeat 7 - search is now correct 8 - Try vaeious searches with 'more options' and selecting different operators Signed-off-by: David Nind <david(a)davidnind.com> Signed-off-by: David Cook <dcook(a)prosentient.com.au> Signed-off-by: Victor Grousset/tuxayo <victor(a)tuxayo.net> Signed-off-by: Josef Moravec <josef.moravec(a)gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize(a)ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26310] New: Allow setting trace_to parameter in Elaasticsearch config
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26310 Bug ID: 26310 Summary: Allow setting trace_to parameter in Elaasticsearch config Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com When debugging it would be nice to see the requests/responses from Elasticsearch We can set a debug variable: https://metacpan.org/pod/Search::Elasticsearch#trace_to -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 21591] New: Data inconsistencies - Item types and biblio level
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21591 Bug ID: 21591 Summary: Data inconsistencies - Item types and biblio level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz bug 21150 added a script to check for missing item level itemtypes - it doesn't like when both the item and the record are missing itemtype -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 26963] New: Koha::Template::Plugin::Branches::pickup_locations is very inefficient, causing timeouts on records with large numbers of holds/items
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26963 Bug ID: 26963 Summary: Koha::Template::Plugin::Branches::pickup_locations is very inefficient, causing timeouts on records with large numbers of holds/items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 If a record has a large number of holds ( > 50 I'd say ), and a large number of items, checking the pickup locations takes so long the script often times out. We need to find a way to cache the results so we don't have to spend so much time on expensive lookups. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 97

[Bug 14697] Extend and enhance "Claims returned" lost status
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |25583 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25583 [Bug 25583] When ClaimReturnedLostValue is not set, the claim returned tab doesn't appear -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5428] Back to results after deleting a record
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5428 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |After deleting a release notes| |bibliographic record in the | |cataloguing module the | |cataloguer will now be | |redirected back to the | |search results list if they | |had any, instead of the | |empty search form. Keywords|release-notes-needed | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 22328] New: Inconsistent behavior throughout acquisitions for determining whether or not an item as been received
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22328 Bug ID: 22328 Summary: Inconsistent behavior throughout acquisitions for determining whether or not an item as been received Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When an aqorders line has quantityreceived>0 but datereceived is NULL, fund totals shows inconsistently across acquisitions. To test: - create an order with quantityreceived=1 and datereceived NULL (this may need to be done from the command line) - find the relevant fund in the All Available Funds table at acqui-home.pl, note that the order is reflected in the Spent total - Click through to spent.pl for the relevant fund, note that the order is not reflected here - Click through to ordered.pl for the relevant fund, note that the order is not reflected here either I'll acknowledge that it shouldn't really be possible for an item to have a quantityreceived without a datereceived -- I haven't yet figured out how the library I found this on did it -- but the inconsistent logic is an issue nonetheless. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 24012] New: Display 'Locked' budget in red
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24012 Bug ID: 24012 Summary: Display 'Locked' budget in red 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 I find it illogical that the 'Locked' in locked budget is displayed in green. Shouldn't it be displayed in red? To reproduce: 1- Go to Administration 2- Click on Budgets 3- Add a new budget and check the 'Lock budget' box 4- Click on the 'Inactive budgets' tab 5- Note that 'Locked' is displayed in green -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 24306] New: Add debug option to koha-indexer
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '20

20 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24306 Bug ID: 24306 Summary: Add debug option to koha-indexer 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Would be nice to be able to raise logging level and see errors from the indexer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 21066] New: Use opac_news.timestamp as a real timestamp or add opac_news.updated_on ?
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '20

19 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21066 Bug ID: 21066 Summary: Use opac_news.timestamp as a real timestamp or add opac_news.updated_on ? 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org I would propose to use the opac_news.timestamp field readonly and fill/update it automatically via SQL. Or do we still need the original publish date and add a modified/updated_on timestamp? What do you think? -- You are receiving this mail because: You are watching all bug changes.

1 56