September 2016 - Koha-bugs - lists.koha-community.org

[Bug 17380] New: Cannot edit authorities with authtypecode = default
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '17

30 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17380 Bug ID: 17380 Summary: Cannot edit authorities with authtypecode = default Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: joachim.ganseman(a)ehb.be QA Contact: testopia(a)bugs.koha-community.org Created attachment 55947 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55947&action=ed… Example: after trying to merge PERSO_NAME and TOPIC_TERM "Rossini", the PERSO_NAME record is now authtypecoded as "default" and cannot be edited anymore Editing authorities whose authtypecode is not set to a common value is not possible in Koha 16.05 . This occurs e.g. after trying to (accidentally) merge a PERSO_NAME and TOPIC_TERM authority into one. The resulting authority will have its authtypecode set to "default". Upon trying to correct such an authority, it turns out to be impossible to edit the said authority. An error very similar to 'Can't call method "authtypecode" on an undefined value' appears instead of the editor. This occurs even when there are no authority frameworks defined (i.e. all in the default frameworks), in Koha 16.05 on Debian. -- You are receiving this mail because: You are watching all bug changes.

1 56

[Bug 17214] New: Add item in LIST by Record number
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17214 Bug ID: 17214 Summary: Add item in LIST by Record number Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: mishravk79(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Once the LIST is created in Koha you can add item in that by barcode but is there any option to add item by record number because if there is no barcode assigned to the item how it can be added to the list? For example in case of remotely available resources like e-book/e-journals where library may enter only bibliographic details. -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 17334] New: members-update.pl should show timestamp
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17334 Bug ID: 17334 Summary: members-update.pl should show timestamp 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the management of patron updates, it seems logical that the requests should show the timestamp of when the request was placed. Yes, you can look this up in a report, but this should be a basic feature of managing requests. Ideally, it should show on the same line as the patron name. Probably something like "Requested: 2016-09-05" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 17077] New: Write off all does not let you write a description
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17077 Bug ID: 17077 Summary: Write off all does not let you write a description 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: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When writing off all patron's fines, librarian should be taken to a page where they can write a description for the write-off. It works for individual write-offs, but not for "Write off all". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 17381] New: Add system preference SCOUserHTML
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '17

26 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17381 Bug ID: 17381 Summary: Add system preference SCOUserHTML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org Add a system preference SCOUserHTML to display content on the self checkout page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 17277] New: Current Location column in Holdings table showing empty under OPAC
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '17

25 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17277 Bug ID: 17277 Summary: Current Location column in Holdings table showing empty under OPAC Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: erjon.sulaj(a)uart.edu.al QA Contact: testopia(a)bugs.koha-community.org Created attachment 55333 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55333&action=ed… item details opac Hi, for a couple of days I tried to resolve the problem by double checking the cataloging process, or item details, but at no avail. The problem is that the holdings detail table does not show anything under the "current location" field when accessing item details under OPAC, while it shows all the details if accessed from staff interface. I am attaching the pictures for what I stated above. Best regards, -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 16911] New: Koha::Patrons - Move ExtendMemberSubscriptionTo to -> extend_subscription
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '17

24 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16911 Bug ID: 16911 Summary: Koha::Patrons - Move ExtendMemberSubscriptionTo to ->extend_subscription Change sponsored?: --- Product: Koha Version: master 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 The goal of these patches will be to move the 2 subroutines GetExpiryDate and ExtendMemberSubscriptionTo to the 2 methods of Koha::Patron::Category->get_expiry_date and Koha::Patron->get_expiry_date This way, we will have a nice code like my $patron = Koha::Patrons->find( 42 ); $patron->move_to_deleted; # From bug 16907 $patron->delete; # Which will handle the different deletion to do before deleting a patron -- You are receiving this mail because: You are watching all bug changes.

1 52

[Bug 16187] New: Add a script to cancel unfilled holds after a specified number of days
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '17

20 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16187 Bug ID: 16187 Summary: Add a script to cancel unfilled holds after a specified number of days Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Work to be done: 1) Create new script cancel_unfilled_holds.pl --days DAYS 2) This script would accept a --days parameter, and trigger C4::Reserves::CancelReserve for all unfilled holds with a 'reservedate' older than the the given number of days. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 16313] New: Koha::Logger doesn't forward the Log::Log4perl::Logger return value
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '17

15 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16313 Bug ID: 16313 Summary: Koha::Logger doesn't forward the Log::Log4perl::Logger return value 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Log::Log4perl::Logger->$method returns undef if the log level is not logged or something bad happened and true or something similar on success. This allows chaining different loggers to trigger if Log4perl failed to log. Koha::Logger is hardwired to return 1 if Log4perl is configured properly regardless of whether the Log4perl actually succeeded in printing the log message. This is a Log4perl best practice: $Koha::Logger->debug() or syslog("LOG_DEBUG", ...); which should revert to syslog() to log if Log4perl cannot for some reason do the logging. (eg. is disabled) This patch makes the Koha::Logger work with Log4perl better in tandem and return the proper return values. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 15958] New: ZOOM/Zebra-connection cache flushing
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '17

15 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15958 Bug ID: 15958 Summary: ZOOM/Zebra-connection cache flushing 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org When writing tests related to searching, When searching the local index repeatedly, changes in the index are not applied to the search results if the results always return the same records. This is due to ZOOM caching the results. This feature adds a ZOOM::Connection flushing subroutine to get rid of old caches. -- You are receiving this mail because: You are watching all bug changes.

1 5