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

[Bug 19349] New: Allow to store biblio record' s creator and last modifier in MARC
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19349 Bug ID: 19349 Summary: Allow to store biblio record's creator and last modifier in MARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This will allow to store borrowernumber and name of biblio record's creator and last modifier in the MARC record. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 25486] New: Problems with automatic creation of biblio records creator and last modifier in MARC
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25486 Bug ID: 25486 Summary: Problems with automatic creation of biblio records creator and last modifier in MARC Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: darkdave26(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I'm having trouble storing the fields, MarcFieldForCreatorId, MarcFieldForCreatorName, MarcFieldForModifierId and MarcFieldForModifierName. I put the fields 991 $ b, 991 $ c, 992 $ b and 992 $ c, respectively, in the system preferences. However, when I create a new record these fields are not correct. The name you created appears in the field of those who modified it and when I modify the record, the field in marc remains empty. I've tried several attempts, in similar cases, like running updatebase.pl, checking the fields, etc., and the results remain the same. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 14648] Batch remove reserve items
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14648 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #4 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Joe, having a look at the patch: 1) QA test tools We have a script the QA team uses to find common mistakes and coding guideline variations in patches. It's a good habit for devs to run the script on their patches too. In this case it alerts of tabs: FAIL course_reserves/course-details.pl OK critic FAIL forbidden patterns forbidden pattern: tab char (line 55) forbidden pattern: tab char (line 56) forbidden pattern: tab char (line 57) forbidden pattern: tab char (line 58) OK git manipulation OK pod OK spelling OK valid FAIL koha-tmpl/intranet-tmpl/prog/en/modules/course_reserves/course-details.tt OK filters FAIL forbidden patterns forbidden pattern: tab char (line 39) forbidden pattern: tab char (line 40) forbidden pattern: tab char (line 41) forbidden pattern: tab char (line 290) forbidden pattern: tab char (line 291) forbidden pattern: tab char (line 292) OK git manipulation In Koha we have agreed to use 4 spaces and no tabs. Please check your editor settings, that should make things easier. 2) I'd like to suggest to change the label on the button. The 'batch' features usually work by giving it a list, what you do is delete all - so I think we should we should name it that and leave the 'Batch remove...' to be added later. "Remove all reserves" -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14648] Batch remove reserve items
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14648 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff Summary|Batch Remove Reserve Items |Batch remove reserve items --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Joe, once you attach a patch for testing, don't forget to set the status to 'Needs signoff' so testers can see it in the queue :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25518] New: Claims returned to offer a 'checkin' option
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25518 Bug ID: 25518 Summary: Claims returned to offer a 'checkin' option Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The new Claims Returned functionality is great but it is not ideal that the item remains on the patron's account and counts towards their checkout limit. It is debatable that this is correct behaviour whilst it is 'pending' but if the claims returned is then marked as resolved, it would be nice if the item was 'checked in' at the same time. In the majority of cases, the case would be resolved as the item would be found by the patron or in the library. Yes the process of marking the claim resolved, could be followed up with a manual checkin but it would be good if this was automatic. I would also argue that some libraries may want to remove the item from the patron's checkouts lists as soon as it is marked claims returned. I can see that there may be some angry patrons who insist they have returned it (which is why it has been marked claims returned) and therefore do not want to see it visible in their list of checkouts and affecting their limit. Perhaps the ClaimReturnedChargeFee system preference could be enhanced to add a further two options? 1) remove the checkout from the patron's record when it has been marked claims returned 2) checkin the item automatically when claims returned is resolved Or have a new preference to deal with this situation specifically? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25269] New: MARC21slim2OPACResults.xsl does not display all formats (physical descriptions)
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25269 Bug ID: 25269 Summary: MARC21slim2OPACResults.xsl does not display all formats (physical descriptions) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client 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 In MARC21slim2OPACResults.xsl we set the 'Format' or physical description by a combination of the 007 first position and 007 second position. In most cases this displays some text (example: chip cartridge or magneto-optical disc) But some set an png icon instead of any text. Like: <img src="/opac-tmpl/lib/famfamfam/world.png" alt="earth moon globe" class="format"/> These will not display at all that is because of this: <xsl:if test="string-length(normalize-space($physicalDescription))"> <span class="results_format"> <span class="label">; Format: </span><xsl:copy-of select="$physicalDescription"></xsl:copy-of> </span> </xsl:if> Without any text the string length is 0 and nothing at all displays. We need to add text along with each png icon. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 6419] Add customizable areas to intranet home pages
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6419 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com --- Comment #4 from Lucas Gass <lucas(a)bywatersolutions.com> --- At this point I think it would be better to add these HTML content areas to the News editor instead of adding new system preferences for each? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 25588] New: 1
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25588 Bug ID: 25588 Summary: 1 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: tokaba03(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 105273 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105273&action=e… butet -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25485] New: TinyMCE broken in Debian package installs
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25485 Bug ID: 25485 Summary: TinyMCE broken in Debian package installs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical 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 When installing the Debian package of Koha, we install the Debian tinymce package and symlink over our own tinymce libs that are in the Koha codebase. This version of tinymce does not have the same files and because of this, tinymce does not get loaded. We should remove the use of the tinymce Debian package, and just use our own version of TinyMCE. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 68

[Bug 25400] New: Circulation and fine rules cloning from one table to another does not copy "current checkouts allowed"
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25400 Bug ID: 25400 Summary: Circulation and fine rules cloning from one table to another does not copy "current checkouts allowed" Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: joe(a)flo.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate this issue: 1. Create a rule in the main Circulation and Fines Rules table and provide a value for Current checkouts allowed such as 10. 2. Use the clone option to clone the rule you created to another library's table. 3. View the clone's table. 4. You should see that in the Current checkouts allowed column in the clone library that the value is now Unlimited. Cloning should copy all of the values from one library to another. See attached screenshots for an example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19