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

[Bug 5579] New: Remove items from biblioitems.marcxml
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '14

17 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5579 Summary: Remove items from biblioitems.marcxml Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: dev_patches(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 -- 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 25

[Bug 10638] New: Show alert when receiving an order with holds/reserves
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '14

17 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10638 Bug ID: 10638 Summary: Show alert when receiving an order with holds/reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org When orders are received, there should be a message saying whether there are any holds/reserves tied to that order's bib record or item records. If AcqCreateItem is set to "receiving an order" or "placing an order", you might want to know if the item you're receiving can fill a bib-level hold (i.e. "the next available item"). If AcqCreateItem is set to "placing an order", you might want to know if the physical item you're receiving already has a item-level hold on it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 11642] New: Batch patron deletion/anonymization should not allow permanent destruction of patron data
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '14

16 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11642 Bug ID: 11642 Summary: Batch patron deletion/anonymization should not allow permanent destruction of patron data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The Batch patron deletion/anonymization tool gives the option of destroying patron data or moving it to the "trash". I see know reason why we allow deletion of patrons without moving them to deletedborrowers first. We don't allow this kind of behavior for records or items, so why patrons? Furthermore it seems far to easy to mis-use this tool by accident, further exacerbating the situation. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 8836] New: Resurrect Rotating Collections
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '14

16 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8836 Priority: P5 - low Change sponsored?: --- Bug ID: 8836 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Resurrect Rotating Collections Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha I think it's time to bring back the Rotating Collections feature. The security issue related to it was fixed, but the feature was never re-enabled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 164

[Bug 11014] New: Slip Print Problem in Chrome
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '14

15 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11014 Bug ID: 11014 Summary: Slip Print Problem in Chrome Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, you can print circulation slips in Internet Explorer, Firefox, Chromium, and probably heaps of other browsers but not Chrome. When one goes to print a slip in Chrome, a new browser tab is opened, and the "printThenClose" javascript initiates a print. However, instead of using the system dialogue box, it uses a Chrome-specific print preview screen. Since this preview screen is non-standard, the javascript doesn't even detect it, and it proceeds to close the window. (Not the most technical description but that's basically what happens.) Alas, I can't think of any way of getting around this problem. Some research suggests that people use timers or keyboard/mouse movement handlers, but none of those are really optimal strategies for fixing the problem. Another way of getting around it in Chrome is to open the browser using the "--args --disable-print-preview" flags. That will use the system dialogue (which halts the processing of the Javascript and thus the closing of the window until after the actual print is either initiated or cancelled) instead of the custom print screen. However, that might be a lot to ask from a lot of users. I suppose another idea might be to make the printing happen "silently" but then you don't get to choose your printer which is also sub-optimal. At the moment, the easiest thing is just to use a different browser (like Firefox) for circulation if the library prints slips. But again...not really an optimal solution to the problem. Just logging it here anyway. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 12396] New: MTT FIX: Due notices (DUEDGST) are multiplicated and not sent to everybody.
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '14

15 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12396 Bug ID: 12396 Summary: MTT FIX: Due notices (DUEDGST) are multiplicated and not sent to everybody. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org So the first patron receives correct letters, but the followings received all the previous ones AND his letters. Eventually you end up with !n letters in message_queue where n = amount of patrons receiving due messages as digest and having something due. Eventually we got 4 000 000 ODUEDGST-letters of which 1 100 000 were sent to our patrons :) This is madness! Test plan: 0/ Delete the content of the message_queue table. 1/ Pick 3 patrons and set them to receive due messages as digest. 2/ Check 1 item out for 3 separate patrons and specify a due date today. 3/ Launch the advance_notices.pl script. 4/ Before this patch, you got 6 notices (1+2+3 [!n]). Now, you get 3 notices, 1 for each patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 12086] New: Hold priorities incorrect, when waiting status was reversed
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '14

15 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12086 Bug ID: 12086 Summary: Hold priorities incorrect, when waiting status was reversed 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Tested on top of patch for 11947! 1) Prepare for headache. 2) Check out an item from any record. 3) Place 3 holds, for patrons a, b, c on the same record. 4) Return the checked out item - it is now waiting for a, b = 1, c = 2 5) Check out the book to b(!), revert waiting status as offered by the GUI You will end up with: a = 1, c = 1 in the holds list, but in the database it's kind of more correct: a = 1, c = 3 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 11677] New: Limit to Only items currently available for loan or reference not working!
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '14

15 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11677 Bug ID: 11677 Summary: Limit to Only items currently available for loan or reference not working! Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The ability to limit a search to only available items does not seem to be working as expected. Sometimes records with available items are not included in the results. Example: http://screencast.com/t/OVgYybzLE -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 11921] New: memcached configuration should be moved back to koha-conf.xml
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '14

15 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11921 Bug ID: 11921 Summary: memcached configuration should be moved back to koha-conf.xml 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: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The configuration settings for specifying the memcached server should be moved back to koha-conf.xml. The current scheme of passing that information via an environment variable breaks badly on Plack without requiring significant machinations -- and if you're using Plack, there is no need to cache the base Koha configuration information in memcached. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 7003] New: canned report to show patrons and permissions
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '14

13 Dec '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7003 Bug #: 7003 Summary: canned report to show patrons and permissions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Reports AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Querying permissions in SQL is very difficult. It would be nice to have a canned report that shows you all of your patrons and the permissions they each have (well not all patrons - but patrons with permissions). Something like this: Patron Name (linked) | Permission Levels (listed) A filter to only show patrons with 'superlibrarian' or other specific permissions would be great too. -- 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 3