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

[Bug 14251] New: style discharge letter
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14251 Bug ID: 14251 Summary: style discharge letter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 39365 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=39365&action=edit contents of letter Would be nice if the discharge letter was a bit more styled - maybe a library logo to make it look like letterhead? Or at least a few more line breaks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 10616] New: hold warning needs design work
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10616 Bug ID: 10616 Summary: hold warning needs design work 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: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 19804 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19804&action=edit holds warning The attached image is confusing. The radio buttons only apply if you click the 'yes' button. But if you click the 'no' button the radio buttons are ignored. The functionality is good! But it's confusing to the user because it makes it look like the radio buttons apply no matter what button you choose and both buttons end up messing with the hold so users don't want to choose anything. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 9198] New: total holds in opac doesn't stand out
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9198 Bug ID: 9198 Summary: total holds in opac doesn't stand out Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com Created attachment 13849 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=13849&action=edit holds number at the bottom When you have OPACShowHoldQueueDetails set to show holds in the opac it puts the holds at the bottom of the list of holdings in regular font. It gets lost when you have a lot of items. It needs some styling and/or moving. This goes for both themes. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 8751] New: printable version of holds queue printing different pages
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8751 Priority: P5 - low Change sponsored?: --- Bug ID: 8751 Assignee: oleonard(a)myacpl.org Summary: printable version of holds queue printing different pages Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Templates Product: Koha When printing the holds queue it's giving different numbers of results based on how you have the data sorted. Using the example I have: Initial Holds Queue: 122 items Unsorted, then print preview: 13 pages Sorted by Call #, then print preview: 4 pages Sorted by Title, then print preview: 12 pages Sorted by date, then print preview: 8 pages My guess is that the CSS that controls the printable version doesn't take in to account the sorting and that's screwing with things. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 6420] New: in house use checkouts should check for circ statuses
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6420 Bug #: 6420 Summary: in house use checkouts should check for circ statuses Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement 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 When recording in house use it appears that Koha does not check to see if the item is checked out or has a hold. That would be very useful. Regular checkout is aware of the status of the item, why not in house use? -- 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 9525] New: group floating rules
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9525 Bug ID: 9525 Summary: group floating rules Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be handy if you could create groups for floating rules. Right now you can set an item type to float in the circ and fine rules, but there is no way to specific which branches it floats between. This would be a development for consortia so that nearby libraries can have floating collections but not necessarily the entire system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 13624] New: Remove columns branchcode, categorytype from table overduerules_transport_types
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13624 Bug ID: 13624 Summary: Remove columns branchcode, categorytype from table overduerules_transport_types Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: charles.farmer(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Sponsored by Halland County Library This patch is a requirement to Bug #12771. Instead of keeping 'branchcode' and 'categorytype' in the table overduerules_transport_types, a foreign key named 'overduerules_fk' now references the appropriate entry in the table overduerules. This will be necessary once we start managing more than 3 levels of overdue notice. -- You are receiving this mail because: You are watching all bug changes.

1 65

[Bug 15009] New: Planning dropdown button in aqbudget can have empty line
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15009 Bug ID: 15009 Summary: Planning dropdown button in aqbudget can have empty line Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 43391 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=43391&action=edit Planning dropdown having useless fourth row When displaying a budget, the Planning button in the admin toolbar displays Plan by months Plan by libraries Plan by item types Plan by The last one is empty, due to C4::Budgets::GetBudgetAuthCats returning an empty field if the budget has no sort defined. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 14647] New: Make the file name extension dynamic on exporting records
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14647 Bug ID: 14647 Summary: Make the file name extension dynamic on exporting records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Tools --> Export Data (or /cgi-bin/koha/tools/export.pl) Under the Output format sections (on both the bibliographic and authority records tabs) there is a drop-down menu to select the file format of the exported file. The default file format is marc and default file name is 'koha.mrc', but I think it would be a good idea to make the extension dynamic so that when the user selects a different file format (xml or csv) the file name changes respectively (ie to 'koha.xml' or 'koha.csv'). Makes the system more efficient for users and teaches them about correct filenames and extensions without having to actually teach them anything. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 13022] New: Hardcoded limit causes records with more than 20 items to show inaccurate statuses
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '16

25 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13022 Bug ID: 13022 Summary: Hardcoded limit causes records with more than 20 items to show inaccurate statuses Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a record has more than 20 items, all the items over 20 will show as available on the search results even if they are not! This is a hard coded limit in the Search module. This number should be configurable. -- You are receiving this mail because: You are watching all bug changes.

1 42