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

[Bug 17863] New: Problems with repeating subfields linked to an authorised value
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '17

09 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17863 Bug ID: 17863 Summary: Problems with repeating subfields linked to an authorised value Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I kinda hope it's only me, but this is what happens: I created a new field and subfield 991$a, linked to CCODE for testing. The field and the subfield are marked as repeatable. Problem 0: - Try to repeat the field without filling in a value - It will not work, there is a JavaScript error message: TypeError: divs[i].getAttribute(...) is null cataloging.js:100:12 Problem 1: - Select a value for the subfield. - Repeat the field. - The value is copied form the original field into the repeated field (should be empty). Problem 2: - Try to clear the value in the repeated field using the X in the pull down. - It won't work. Problem 3: - Try to open the pull down in the repeated field - It won't work. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 17621] New: API: Should the 'update_on' Patron field really be a datetime?
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '17

09 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17621 Bug ID: 17621 Summary: API: Should the 'update_on' Patron field really be a datetime? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: hector.hecaxmmx(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, lari.taskula(a)jns.fi, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 16276, 17607 Blocks: 17620 Bug #17607 highlighted that all other date fields in the Patron response are simply 'date', whereas update_on is a date-time (without a timezone). We should assess whether it's actually necessary for the update_on field to record the timestamp as opposed to just a date, and if it required we should ensure we record and return the timezone detail along with it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16276 [Bug 16276] When automatically deleting expired borrowers, make sure they didn't log in recently https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17607 [Bug 17607] Fix patron definition in Swagger https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17620 [Bug 17620] Fix format of date/data-times in Swagger definition -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 17612] New: Vocative version of name and surname: database and form field
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '17

08 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17612 Bug ID: 17612 Summary: Vocative version of name and surname: database and form field Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello, Czech (and some other languages) use vocative at names. We really need use this name form in notices and slips. So fist step: - create place in database - field in patron form. It will be optinal feature, because its special just for some languages. Mike -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 16584] New: All SQL queries should be compatible to 'ONLY_FULL_GROUP_BY'.
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '17

08 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16584 Bug ID: 16584 Summary: All SQL queries should be compatible to 'ONLY_FULL_GROUP_BY'. Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: ngson2000(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org As the mode 'ONLY_FULL_GROUP_BY' is ON by default on MySQL 5.7, non ONLY_FULL_GROUP_BY queries in Koha will be rejected. This caused several issue including the error when adding a new patron even the patron categories exist. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 17862] New: Misleading error message if Apache config is invalid
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '17

08 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17862 Bug ID: 17862 Summary: Misleading error message if Apache config is invalid Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: gmcharlt(a)gmail.com Reporter: danmichaelo+kohabugs(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When I ran `koha_create`, I got the error message "Koha requires mpm_itk to be enabled within Apache in order to run." from the `check_apache_config` method even though I had mpm_itk enabled. The real problem was a typo in one of my Apache config file, but the test on line 148 in `koha_create` doesn't distinguish between an invalid Apache config and a valid Apache config with mpm_itk missing: /usr/sbin/apachectl -M 2> /dev/null | grep -q 'mpm_itk' I suggest to check for a valid Apache config before checking for mpm_itk. For instance like so: if ! /usr/sbin/apachectl configtest 2> /dev/null ; then cat 1>&2 <<EOM apachectl configtest failed. Please check your Apache config. EOM die fi -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17861] New: I cant install Koha on Debian Wheezy-Unmet dependences
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '17

07 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17861 Bug ID: 17861 Summary: I cant install Koha on Debian Wheezy-Unmet dependences Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: bugs.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: felixchisoni(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hello, I am installing Koha on Debian Wheezy (Fresh Installation). However, I have experienced the following error when I run "sudo apt-get install koha-common" The following packages have unmet dependencies: koha-common : Depends: libarchive-extract-perl but it is not installable Depends: libgd-perl but it is not installable Depends: libwww-youtube-download-perl but it is not installable E: Unable to correct problems, you have held broken packages. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 15503] Grab Item Information from Order Files
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '17

07 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15503 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Patch doesn't apply --- Comment #55 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Matthias, could you please rebase your patches? Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11897] Stock Rotation for Koha
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '17

07 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11897 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #22 from Owen Leonard <oleonard(a)myacpl.org> --- I've done a quick run-through of this and nothing looks broken. The tests all pass. I think the biggest gap is documentation. There should be a help file for the whole process, especially the things which aren't self-explanatory. For instance: - What does the 'cyclical' setting do? - What is the purpose of the "Start" item in the stages and duration column of the manage items table? - What does the "In demand" setting do? I take it the process is: Create rota -> Add items -> Wait for cron job to put items in transit? I'm curious whether available items should be put in transit automatically after putting them on a rota. Minor problems: - Our capitalization rules say the heading should say "Stock rotation" instead of "Stock Rotation" https://wiki.koha-community.org/wiki/Coding_Guidelines#HTML4:_Upper_and_low… - I don't the the alert-style div is correct for showing a confirmation of items added. I would put the confirmation message in a <div class="dialog message"></div> and show a table of results below that. - In the manage items table, there is no <tr> wrapping <th>. - The page title and breadcrumbs should be made more specific for each page. For instance, when on the manage items page the breadcrumbs should be: Home › Tools › Stock rotation > Manage items This provides an easily accessible link back to the main stock rotation page. Suggestions: - Add a toolbar to the manage items page with a 'New rota' and 'Edit rota' buttons. - Move the add items forms to the top of the - In the manage items table, I think title and barcode should link to the bibliographic record and items page, respectively. - Make the manage items table a DataTable with sorting and searching. Unless you think the items table will typically hold so much data this would become cumbersome? - Should item status information be displayed in the manage items table? Is it relevant to the process to know whether something is checked out, lost, etc? - Since the drag-to-sort interaction is new to Koha it probably needs a hint at the top to suggest it. (Looks good and work well, though). I'm marking this as failed for now for the minor fixes and to get more information. Thanks. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11523] Make framework code available to stylesheets to allow for more customized display
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '17

07 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11523 --- Comment #3 from Eugene Espinoza <eugenegf(a)yahoo.com> --- As posted in the koha-community list to which Galen Charlton replied, it can be possible. Where to put the settings is probably in framework editing where one can assign xslt for a particular framework. This since the feature enhancement asked is to let a user choose an xslt for MARC frameworks. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 17452] New: Checking in item at remote location via SIP does not trigger branch transfer
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '17

07 Jan '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17452 Bug ID: 17452 Summary: Checking in item at remote location via SIP does not trigger branch transfer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com I'm using the following for illustration: Item: BARCODE User: USER Homebranch: HUNTSMAN SIP check in branch RICHFIELD Steps to re-create: Check item with barcode BARCODE out from HUNTSMAN. Then simulate the check in at RICHMOND using sip_cli_emulator.pl: /usr/share/koha/bin/sip_cli_emulator.pl --host HOSTNAME --port PORT --sip_user sip_techlogic --sip_pass ********** --terminator CR --location RICHFIELD --patron USER --password ********** --item BARCODE --message checkin If you then check the database, you will the item information as items.homebranch = HUNTSMAN items.holdingbranch = RICHFIELD and no branch transfer is created for the item. The logs look like this: INPUT MSG: '9300CNsip_techlogic|CO**********|CPRICHFIELD' Successful login/auth for 'sip_techlogic' of 'RICHFIELD' OUTPUT MSG: '941' read_SIP_packet, INPUT MSG: '09N20161014 13105520161014 131055APRICHFIELD|AORICHFIELD|ABBARCODE|AC**********|BIN' INPUT MSG: '09N20161014 13105520161014 131055APRICHFIELD|AORICHFIELD|ABBARCODE|AC**********|BIN' OUTPUT MSG: '101YNY20161014 131056AORICHFIELD|ABBARCODE|AQHUNTSMAN|AJDistracted :|AAUSER|CS302 J1636D|CV04|' read_SIP_packet input undefined, end of input. raw_transport: shutting down The sip response 101YNY20161014 131056AORICHFIELD|ABBARCODE|AQHUNTSMAN|AJDistracted :|AAUSER|CS302 J1636D|CV04|' Corresponds to --- command_name: Checkin Response fields: - Header: - Command ID: 10 - OK: 1 - Resensitize: Y - Magnetic media: N - Alert: Y - Transaction Year: 2016 - Transaction Month: 10 - Transaction Day: 14 - Transaction Timezone: '' - Transaction Hour: 13 - Transaction Minute: 10 - Transaction Second: 56 - Institution id: AORICHFIELD - Item identifier: ABBARCODE - Permanent location: AQHUNTSMAN - Title identifier: 'AJDistracted :' - Sort bin: AAUSER - Patron identifier: CS302 J1636D - Fixed width 1: - Media type: CV0 - Item properties: 4 - Screen message: "'" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2