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

[Bug 36956] New: ERM eUsage reports : only the first 20 data providers are listed when creating a new report
by bugzilla-daemon＠bugs.koha-community.org 30 Jul '24

30 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36956 Bug ID: 36956 Summary: ERM eUsage reports : only the first 20 data providers are listed when creating a new report Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com to reproduce: 1.) Go to ERM module and make sure you have more than 21 data providers stored in your database. 2.) Go to eUsage / reports and create new report (cgi-bin/koha/erm/eusage/reports) 3.) Check that only the first 20 data providers are displayed in the drop down -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 35942] OPAC user can enroll several times to the same club
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35942 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes patron club release notes| |enrollment to prevent | |patrons from enrolling | |multiple times in the same | |club. There was no visible | |option in a patron's OPAC | |account to do this (Summary | |> Clubs), but it could be | |achieved by directly | |accessing the URL | |(/cgi-bin/koha/svc/club/enr | |oll?id={clubid}). CC| |david(a)davidnind.com --- Comment #23 from David Nind <david(a)davidnind.com> --- This fixes patron club enrolment from their account in the OPAC. They can now only enroll in a club once. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25884] New: Automatic item modifications by age needs title and description fields
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25884 Bug ID: 25884 Summary: Automatic item modifications by age needs title and description fields Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org We need to be able to label and describe these rules outside of the settings we set. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 35726] New: Add ability to edit automatic item modification by age rules individually
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35726 Bug ID: 35726 Summary: Add ability to edit automatic item modification by age rules individually Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When there are several rules, it would be nice if it were possible to edit individual rules. Right now, in order to edit one rule, all rules are opened for editing. This could be done by adding an edit button at the end of the row in the table that lists the rules. As an extension, the rules table should be sortable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37517] New: Allow for staff to easily place a hold on a previously cancelled hold for a patron
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37517 Bug ID: 37517 Summary: Allow for staff to easily place a hold on a previously cancelled hold for a patron Change sponsored?: --- Product: Koha Version: unspecified 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 In the staff interface, staff can see the patron's hold history. It would be nice if there was a hold button on the patron's past holds to allow staff to easily put the patron back on the list of holds for the title. Sort of like, the search to hold button does from the patron's account. Place hold for patron, so Koha remembers the name of the patron and you can easily place it back on hold without having to type the name in. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 --- Comment #119 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I agree with Nick about it being a separate thing would be better and apply to more use cases. I think the "all libraries" is a bit confusing as it seems to move into a mix of "fallback when nothing is set" and "global total over all libraries". Making sure we know which is what is important here. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37503] New: ERM generated Bibliographic records through imports needs mapping
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37503 Bug ID: 37503 Summary: ERM generated Bibliographic records through imports needs mapping Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Created attachment 169789 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169789&action=e… CSV with 9 titles for ERM import In reference to bug 34788 Bibliographic records generated from KBART file imports appear to work similar to the CSV2MARC plugin. It seems to be able to do this without mapping column headers to a specific tag. However, the resultant record only contains a title, which is not a useful bibliographic record. It would be helpful to possibly incorporate the ability to match column headers to MARC tags like the plugin tool. The example file from bug 34788 contained additional record content like an ISSN, 856 URL, and potentially other content, but only the title was used for the record. Even if the vendor does not supply a complete record, this partial record is still more useful if it makes it into the generated bibliographic record. This may be possible if there was a way to map the column headers. Attaching a similar KBART file from Bug 34788 but with only a few titles for testing. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 26614] New: Diacritics taken into account in facet sorting
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26614 Bug ID: 26614 Summary: Diacritics taken into account in facet sorting Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 111259 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111259&action=e… Record with subject beginning with É for testing In both OPAC and Intranet, the subject facets are sorted in alphabetical order. However, letters with diacritics are sorted at the end rather than with their corresponding letters. Right now, the sorting is A, B, C, M, O, R, V, Z, É but it should be A, B, C, É, M, O, R, V, Z To replicate: I attached a record with a subject beginning with É 1- Import the record in your catalog 2- If necessary, rebuild zebra 3- In OPAC, search for the record (choose a keyword that is vague enough to get you some results but not too many, otherwise the facet won't show up -- see maxRecordsForFacets), I used the keyword "action" in my catalog 4- If necessary, expand the subject facet 5- Note that the "Égalité des sexes" subject is at the end rather than where E should be 6- Repeat steps 3-5 in Intranet, same problem -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 32693] New: The 'About Koha' page loads slowly
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32693 Bug ID: 32693 Summary: The 'About Koha' page loads slowly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org The 'About Koha' page in the staff interface is noticeably slower to load than other pages in the staff interface (for me, anyway). Using the browser web developer network tools, it shows it took about 4-5 seconds to load the first time (after a flush_memcached, restart_all, and a browser with a cleared cache). Subsequent loads are a lot quicker (about 1-2 seconds). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 32729] New: Deleting an item removes the itemnumber from old_issues when it probably should not
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '24

29 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32729 Bug ID: 32729 Summary: Deleting an item removes the itemnumber from old_issues when it probably should not Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I ran across this when troubleshooting lifetime savings on ISSUESLIPs. To recreate: 1. Checkout an item and check it back in. 2. Look at the old_issues tabe ( select itemnumber from old_issues; ) 3. See the itemnumber 4. Delete the item. 5. Check old_issues again, the itemnumber is now NULL. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20