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

[Bug 17961] New: TT syntax for notices - Prove we have an equivalent for our historical custom syntax
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17961 Bug ID: 17961 Summary: TT syntax for notices - Prove we have an equivalent for our historical custom syntax Change sponsored?: --- Product: Koha Version: unspecified 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 Blocks: 15278 This bug report is an omnibus. It will link to bug reports which take care of the migration to the TT syntax for notices. For each special marker we have in our historical custom syntax, an equivalence will be provided. Moreover tests will cover all the changes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 19223] New: Problem with plugins and encodings
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19223 Bug ID: 19223 Summary: Problem with plugins and encodings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com I have created a couple of plugins for Koha: https://github.com/Libriotech/koha-plugin-overview which queries the Koha database and reports things like number og biblio, items, patrons etc. https://github.com/Libriotech/koha-plugin-btj which receives data from an outside source, saves it to the database, creates records and items and displays some of the data to users. The second one does not show any encoding problems, but the first one does. When I look at /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::No::Libriotech::Overview&method=report&detail=items and have the language set to Norwegian, there are problems with the output from the plugin as well as the other parts of the page, such as the main menu at the very top of the page. I can't see that I have done anything very different in those two plugins, and yet they behave differently. Anyone got a clue if this is a problem with my code or with the plugin system? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 19204] New: Fines in days restriction calculation is not taking calender into account
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19204 Bug ID: 19204 Summary: Fines in days restriction calculation is not taking calender into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the fines in days feature, the restrictions will be calculated without taking holidays into account. So the restriction can end in the middle of a period the library is closed. To test: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date now is the same and a holiday. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 16575] New: Irregular behaviour using window.print() followed by window.location.href=
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 Bug ID: 16575 Summary: Irregular behaviour using window.print() followed by window.location.href= Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As we noticed in bug 11014, different browsers handle "window.print()" differently. In the case of window.print() followed by window.location.href=, I've found in IE 11 on Windows 8.1 that the browser changes the window location before the system print dialogue even opens. If I try to mitigate that using the timer from bug 11014, it works in IE and Chrome, but it breaks in Firefox. If I try to use the onafterprint in IE and Firefox, it works in IE but it breaks in Firefox. I started wondering if we even need to be using this window.print() followed by window.location.href= and it occurred to me that we really don't. We should just be using print.css. Patch to follow soon... -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 16653] New: reports/cat_issues_top.pl does not export "Count of checkouts" column as CSV
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16653 Bug ID: 16653 Summary: reports/cat_issues_top.pl does not export "Count of checkouts" column as CSV Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org reports/cat_issues_top.pl does not export "Count of checkouts" column as CSV To replicate: 1/ Make sure that test instance has circulation in a given date range 2/ Go to Home › Reports › Most-circulated items 3/ Select a date range 4/ Select 'To screen into the browser' radio button, click submit. 5/ Note that Columns 'Rank/Biblioitemnumbers', 'Global' and 'Count of checkouts' appear in screen output. 6/ Click the browser's back button 7/ Change output to 'To a file', click submit. 8/ Note that the columns "100/", "Global" and "Total" are exported to the CSV file. "100/" contains the rank, "Global" is still global, and the "Total" column is empty. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15971] New: Allow use of all biblio and biblioitems fields in serial claim letters
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15971 Bug ID: 15971 Summary: Allow use of all biblio and biblioitems fields in serial claim letters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When creating a serial claim letter only title, author and serial are offered as fields in the notice editor. It should be possible to print all fields from the biblio and biblioitems tables including the ISSN in the notices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 18856] New: Cancel Waiting Hold in OPAC does not give useful message
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18856 Bug ID: 18856 Summary: Cancel Waiting Hold in OPAC does not give useful message Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If a hold is 'waiting' for the patron to collect then the patron should be prevented from cancelling the hold via their account in the opac. If a patron tries to cancel the hold, Koha will give an 'are you sure' alert and when you click Yes the page just refreshes and the hold remains. Staff can cancel the hold from the staff interface but they can then action the waiting hold. I think therefore that it is correct behaviour that a patron cannot cancel a hold when it reaches waiting state via the opac but it would be useful to either have a warning to prevent the cancellation or a useful message when they attempt to do so. -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 18521] New: Renew and search hotkeys are swapped on returns page.
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18521 Bug ID: 18521 Summary: Renew and search hotkeys are swapped on returns page. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: tmcmahon(a)wlpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The hotkeys for the tabs on the staff interface returns page (/cgi-bin/koha/circ/returns.pl) are not working correctly. Alt-W selects the tab labeled 'Search the catalog' and should select 'Renew'. Alt-Q selects the tab labeled 'Renew' and should select 'Search the catalog'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 19030] New: We need to mantain the connection order <-> subscription that we create in basket creation
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19030 Bug ID: 19030 Summary: We need to mantain the connection order <-> subscription that we create in basket creation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: z.tajoli(a)cineca.it QA Contact: testopia(a)bugs.koha-community.org In table aqorders there is the fiedl 'aqorders.subscriptionid'. It is present because during creation of a basket if you add an order from a subscription, you register subscriptionid into aqorders.subscriptionid. But when I try to change data (price, change ratio, etc.) of order, using acqui/parcel.pl, the link to order doesn't send the subscriptionid param. So the value of subscriptionid is deleted in aqorders table and the connection is lost. The problem is described in the pdf file here attached and in this e-mail thread: https://lists.katipo.co.nz/pipermail/koha/2017-July/048475.html Probably we need: 1) A new C4::Acquisition function that gives suscriptionid connect with a specific odernumber 2)Changes in acqui/parcel.pl and in koha-tmpl/intranet-tmpl/prog/en/modules/acqui/parcel.tt -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 19116] New: Holds not set to waiting when "Confirm" is used
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19116 Bug ID: 19116 Summary: Holds not set to waiting when "Confirm" is used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When a hold with status transfer is checked in, we offer "Confirm" and "Print and confirm", both should set the item to waiting and create a pick-up letter if set up. But only the second option has this effect. To test: - Place holds on 2 items from another branch - Switch to that branch - Check them in at the other branch to set them into transport status (T) - Switch back to your homebranch - Check items in again, use the different confirm buttons and compare - Only "confirm and print" will be set to waiting, "confirm" remains in transport. Might be related to bug 19020. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60