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

[Bug 15686] New: Rename "item level holds" circ rule column to "OPAC item level holds"
by bugzilla-daemon＠bugs.koha-community.org 01 Feb '20

01 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15686 Bug ID: 15686 Summary: Rename "item level holds" circ rule column to "OPAC item level holds" Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 5786 moved the OPACItemHolds sys pref setting to the Circulation Rules table. However, the naming of the new circ rules column is quite confusing. It is called "Item level holds" which makes it sound like this setting controls the item level holds placing from anywhere in the system (staff and OPAC sides) Instead, the setting only affects item level hold placing from the OPAC side. Should this column then be renamed to "OPAC item level holds"?, so it's not so confusing? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 15704] New: split up 264 index
by bugzilla-daemon＠bugs.koha-community.org 28 Jan '20

28 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15704 Bug ID: 15704 Summary: split up 264 index Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 14198 Right now the 260 index look like this:  <index_subfields tag="260" subfields="a"> <target_index>pl:w</target_index> <target_index>pl:p</target_index> </index_subfields>  <index_subfields tag="260" subfields="b"> <target_index>Publisher:w</target_index> <target_index>Publisher:p</target_index> </index_subfields>  <index_subfields tag="260" subfields="c"> <target_index>copydate:w</target_index> <target_index>copydate:s</target_index> </index_subfields>  <index_data_field tag="260"> <target_index>pl:w</target_index> <target_index>Provider:w</target_index> </index_data_field> The 264 only indexes the entire thing.  <index_data_field tag="264"> <target_index>Provider:w</target_index> </index_data_field> We should break the 264 up for better/more accurate searching. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14198 [Bug 14198] RDA: Indexing 264 field (Zebra) -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 16421] New: Move hold edit actions into dropdown menu
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '20

22 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 Bug ID: 16421 Summary: Move hold edit actions into dropdown menu Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/reserve/request.pl 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 Created attachment 51111 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51111&action=ed… Screenshot showing proposed interface change I propose that we re-work the way existing holds are displayed in the staff client so that many of the actions associated with a hold are moved into a dropdown menu. I would also add some additional information about the status of a hold into the "details" column. This change would accomplish a few things: - Make the display more compact - Make clearer some information which may not be clear. For instance, that a hold is suspended until a particular date, or that a hold is set to lowest priority. - Make clearer the meaning of the hold priority icons. Using text labels with icons, the meaning of each is explicit. Unfortunately Font Awesome doesn't have the equivalent of the "move to top" or "move to bottom" icon, so I've tried to fake it with a border. It's not perfect buy may be passable. See attached screenshot. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 16766] New: Merging two records with title level holds for the same patron creates two holds on one record
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '20

13 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16766 Bug ID: 16766 Summary: Merging two records with title level holds for the same patron creates two holds on one record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 To recreate: 1 - Place a title level hold for a patron on a record 2 - Do it again on another record 3 - Merge these recrods 4 - See they now have two holds on one record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 16413] New: Prototype for GetLatestAutoRenewDate and GetSoonestRenewDate should be changed
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '20

13 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16413 Bug ID: 16413 Summary: Prototype for GetLatestAutoRenewDate and GetSoonestRenewDate should be changed Change sponsored?: --- Product: Koha Version: master 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 Depends on: 16344 Currently the 2 GetLatestAutoRenewDate and GetSoonestRenewDate subroutines takes $borrowernumber and $itemnumber in parameter. They refetch the patron, item and issue information but they already are available from where they are called. It would make sense to change the prototype of these 2 subroutines to accept the patron, item and issue information directly to avoid unnecessary refetches. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16344 [Bug 16344] Add a circ rule to limit the auto renewals given a specific date -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 16140] New: Only clear L1 cache when needed
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '20

13 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16140 Bug ID: 16140 Summary: Only clear L1 cache when needed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P2 Component: Architecture, internals, and plumbing Assignee: jweaver(a)bywatersolutions.com Reporter: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 16044 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16044 [Bug 16044] Define a L1 cache for all objects set in cache -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 16979] New: Search for barcode containing parentheses fails
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16979 Bug ID: 16979 Summary: Search for barcode containing parentheses fails Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Searching for a call number containing parentheses, similar to: 1234567890 (text) or 1234(5678)90 fails to return any results, either in the staff interface or OPAC. For the first barcode, leaving off "(text)" will return the expected result, but removing the parentheses from the latter still does not. The issue (and I suspect the solution) seems similar to 15468 and 12405 in that, if I modify the URL to include %22 around the barcode, I get the expected result. To reproduce : 1) Set up an item with a barcode with the form: 1234567890 (text) 2) In the staff interface, perform a barcode search for the exact barcode 3) No results are returned 4) Modify the search URL to include %22 around barcode e.g.: .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=1234567890+(text)&op=and&idx=kw&op=and&idx=kw&sort_by=relevance becomes: cgi-bin/koha/catalogue/search.pl?idx=bc&q=%221234567890+(text)%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance 5) Press enter 6) The expected result is returned 7) Setup an item with a barcode with the form: 1234(5678)90 8) In the staff interface, perform a barcode search for the exact barcode 9) No results are returned 10) Modify the result URL to include %22 around barcode e.g. .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=1234(5678)90&op=and&idx=kw&op=and&idx=kw&sort_by=relevance becomes: .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=%221234(5678)90%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance 11) Press enter 12) The expected result is returned -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16930] New: Search returns no results if "and" appears before a colon
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16930 Bug ID: 16930 Summary: Search returns no results if "and" appears before a colon Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Search returns no results for an exact title search. Steps to duplicate: 1. Create a record with a title like: This is a test title and for testing only : An Example Value 2. Do a title search for the exact title: This is a test title and for testing only : An Example Value 3. No results will be found 4. Change the title to: This is a test title : An Example Value and for testing only 5. Do a title search for the exact title: This is a test title : An Example Value and for testing only 6. The search returns a result. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16137] New: Simplify patron deletion error handling
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16137 Bug ID: 16137 Summary: Simplify patron deletion error handling Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/members/deletemem.pl OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When deleting a patron, there are some cases handled by deletemem.pl which stop the process and redirect to moremember.pl. Other cases stop the process and display an error in the deletemem.tt template. Is there any reason not to redirect all deletion errors to moremember.pl and eliminate the need for deletemem.tt? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16827] New: Remove "by" before primary access point.
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16827 Bug ID: 16827 Summary: Remove "by" before primary access point. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org Created attachment 52933 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52933&action=ed… Screenshot of OPAC showing a conference record. After showing the title with the statement of responsability the OPAC shows the primary access point preceded by the word "by". In case of defendants, corporate bodies and conferences it is odd to have this word preceding an authorized access point. This word should be deleted in the OPAC and if there are libraries who want to maintain the "by" practice, it should be possible to add a system preference to do so. -- You are receiving this mail because: You are watching all bug changes.

1 1