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

[Bug 14155] New: Placing holds via ILSDI bypass some checks
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14155 Bug ID: 14155 Summary: Placing holds via ILSDI bypass some checks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you make a hold request using ILSDI webservices (HoldItem or HoldTitle) 2 important checks are skipped while they are done using staff user interface. 1) maxreserves system preference is ignored so you can place as many hold as issuingrules allow you even if maxreserves is set. 2) nothing checks if the borrower already reserved the biblio. Patch is coming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 9076] New: Add ability to delete borrowers by expiration date and category code to cleanborrowers.pl
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9076 Priority: P5 - low Change sponsored?: --- Bug ID: 9076 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Add ability to delete borrowers by expiration date and category code to cleanborrowers.pl Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Patrons Product: Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 11352] New: Batch Patron Deletion/Anonmyzation deletes more than warning states it will delete
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11352 Bug ID: 11352 Summary: Batch Patron Deletion/Anonmyzation deletes more than warning states it will delete Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: danielle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 23346 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=23346&action=edit Warning 1 Tested in versions 3.12.6, 3.14 and 3.15 (Bywater demo) When deleting by dateexpiry in batch deletion tool. The warning states a low number, and then when it comes back with a total of deletion, it deletes thousands more than it give a warning for. For instance it warned it would delete 102, the deleted 3661 in one system. We can't get the accurate count it is deleting patron's on either way. When queried with the same parameters (dateexpiry) the number is different. To recreate. Go to Batch Patron/Anonymzation Tool Select a dateexpiry date Warning should come up with count to delete Select to Permanently delete (not put in trash) Count of deleted items will show differently than warning-by thousands. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 7017] New: override_renewals permission confusing
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7017 Bug #: 7017 Summary: override_renewals permission confusing Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com You can set it so that a patron only has override renewals permission, but they can't access the circ module to override the renewals in the first place. I think we need to make it clear which permissions are dependent on other permissions. Having a permission nested does not make that clear because in the example of the tools permissions you can pick and choose which ones you want to provide. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 2

[Bug 6988] New: formatted strings get split in substrings for translation
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6988 Bug #: 6988 Summary: formatted strings get split in substrings for translation Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: gaetan.boisson(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Formatted strings in English (typically with some words in bold) get split around the formatted words. A sentence with one bold word or group of consecutive words thus becomes 3 separate strings. This behaviour makes it pretty difficult to work on this kind of sentence when translating, as the translator has to search for the strings separately in the translation tool. Also this forces the translator to follow the same structure as the original for the translated sentence (e.g. normal BOLD normal) which will not necessarily work out in the target language. There are some examples in the right column ("notes") on the admin page at Home › Tools › Import Patrons. For instance in the last bullet point: "must", translated into French, will have different forms according to what the subject is. It's plural here so it would be "doivent", the translated sentence however has "doit" which is a correct translation when the subject is singular. Finding the correct "doit" in the tool to correct the translation is very impractical. Another similar example can be found at Home › Tools › Patron Card Creator › Manage Images. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 2

[Bug 14459] New: Marking parts of text bold is bad for translation
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14459 Bug ID: 14459 Summary: Marking parts of text bold is bad for translation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr I came across this as a library reported a very strange translation: / koha-tmpl / intranet-tmpl / prog / en / modules / reserve / request.tt 318 [% IF ( alreadypossession ) %] 319 <li> <a href="/cgi-bin/koha/members/moremember.pl?borrowernumber=[% borrowernumber %]">[% borrowerfirstname %] [% borrowersurname %]</a> <strong>is already in possession</strong> of one item</li> 320 [% END %] The problem here is that this ends up as 2 separate strings that make it really hard to build a correct sentence: of one item is already in possession I think for now I'd like to suggest to only use bold formatting on full sentences or single words, but not within a string. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 14321] New: Merge UploadedFile and UploadedFiles into Koha::Uploader
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14321 Bug ID: 14321 Summary: Merge UploadedFile and UploadedFiles into Koha::Uploader Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org One of the main QA concerns on bug 6874 was the introduction of UploadedFiles.pm while we already have UploadedFile.pm. Recognizing the amount of work on that report, it would not be very productive to just park the development in FQA. The older module UploadedFile contains functionality for temporary uploads and has minimum test coverage; the newer module contains functionality for permanent uploads and access via hash id, and with much more unit tests. Koha::Uploader should contain the best of both: allow temporary and permanent uploads, also keeping the progress and ajax upload of the old one. Providing an object that allows for some future extensions. -- You are receiving this mail because: You are watching all bug changes.

1 121

[Bug 5590] New: error message on holds not consistent
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5590 Summary: error message on holds not consistent Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com, oleonard(a)myacpl.org Estimated Hours: 0.0 Created attachment 2964 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2964 batch holds I'm trying to place a batch of holds and the error message at the top says I can't place holds on any of the items, but there is one item that has the option to place a hold (visually) - that one item however is checked out to the patron already, so it shouldn't be allowed to be placed on hold (I don't think). So basically the error message is right, but one of the items that can't be put on hold is still allowing holds. See attached. I need someone to test this further to confirm that it's an error and what's causing it. Also CCing Owen because the errors highlighted in yellow should probably go all the way to the end of the box - they look a bit short/funny now. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 4

[Bug 5788] New: Move ReservesMaxPickupDelay system preference to the Circulation Matrix.
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5788 Bug #: 5788 Summary: Move ReservesMaxPickupDelay system preference to the Circulation Matrix. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5609 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 42

[Bug 5787] New: Move OPACItemHolds system preference to the Circulation Matrix.
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '16

05 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5787 Bug #: 5787 Summary: Move OPACItemHolds system preference to the Circulation Matrix. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 5609 Allowing it to be restricted by itemtype or patrontype, not a blanket preference -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 12