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

[Bug 13932] New: Allow a header to be considered trusted to provide the userid
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13932 Bug ID: 13932 Summary: Allow a header to be considered trusted to provide the userid Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: robin(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When Koha is placed behind an SSO system, it'd be useful to be able to get the user ID, like happens with basic auth. This patch allows a header to be considered an authoritative source of user ID. This only works with a plack-like environment, when apache is running Koha as CGI I think the headers come through using a different method. An example configuration would be: <Location /> ... mod_auth_mellon config goes here ... Header unset X_REMOTE_USER RequestHeader unset X_REMOTE_USER RequestHeader set X_REMOTE_USER %{MELLON_sfdcid}e </Location> (REMOTE_USER seems to have a special use to apache that means it doesn't work, hence using X_REMOTE_USER.) For testing, you can fake it by replacing the variable with something hardcoded and ignore all the SSO guff. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 13705] New: Move indexation subs in C4::ZebraIndex
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13705 Bug ID: 13705 Summary: Move indexation subs in C4::ZebraIndex Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Move indexation-related subs from rebuild_zebra.pl to new module C4::ZebraIndex and create two new subs IndexRecord and DeleteRecordIndex This should allow easier indexation from scripts other than rebuild_zebra.pl -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 13706] New: Deduping authorities script (dedup_authorities.pl)
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13706 Bug ID: 13706 Summary: Deduping authorities script (dedup_authorities.pl) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: new feature Priority: P5 - low Component: MARC Authority data support Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 11708] New: Display all basketgroups on one page, and new column aqbasketgroups.closeddate
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11708 Bug ID: 11708 Summary: Display all basketgroups on one page, and new column aqbasketgroups.closeddate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 137

[Bug 13666] New: Allow SIP2 checkin/checkout to get branch from institution_id field AO
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13666 Bug ID: 13666 Summary: Allow SIP2 checkin/checkout to get branch from institution_id field AO Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: benjamin.rokseth(a)kul.oslo.kommune.no QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Although SIP2 specifies the required AO field to be institution_id and it doesn't neccessarily map to a branch in Koha, this is probably the case for most. Allowing for AO to set the C4::Context->userenv->{branch} transaction-time would open up for a more flexible transaction scenario: - SIP2 connections could fetch from a pool of connections, so e.g. ten SIP2 workers could easily serve hundreds of clients - SIPConfig.xml would not need reconfiguration each time a new client is added Please advise if this is in collision with other SIP2 logic in Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 10554] New: Add more options to 'AllowSelfCheckReturns' syspref
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10554 Bug ID: 10554 Summary: Add more options to 'AllowSelfCheckReturns' syspref 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: mtj(a)kohaaloha.com This patch modifies the options of AllowSelfCheckReturns syspref from a 2 option selection - 'allow patrons', dont allow patrons' to a 3 option selection - 'allow all patrons', 'allow non-blocked patrons' , allow no patrons' currently, a problem with the syspref behavior in Koha is that enabling the 'AllowSelfCheckReturns' syspref does *not* allow patrons with a 'block' to return items via the SCO. (this is apparently by design, and not a bug) however, some libraries do want to allow patrons to return items via the SCO even if they have a 'block' this patch adds this additional behavior, by adding a new option to the syspref, but also retaining the existing syspref behavior after the patch, there are 2 allow options - 'Allow all' allows all patrons to return items (including blocked patrons) - 'Allow non-blocked' allows only non-blocked patrons to return items (note: this is the current 'allow' behavior) the patch correctly 'upgrades' existing 'allow' selection to the new 'Allow non-blocked' value. so, any existing 'allow' selection works as before -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 12404] New: CSV profiles improvements
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12404 Bug ID: 12404 Summary: CSV profiles improvements 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: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The goal of this development is to provide a better flexibility on creating a CSV profile. Currently it is not possible to: - Concatenate specific subfields into a csv column - Display a field/subfield using a condition - Extract a substring of a subfield value and a lot of other actions. -- You are receiving this mail because: You are watching all bug changes.

1 89

[Bug 14678] New: Update Koha language codes to ISO 639-2 spec
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '15

03 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14678 Bug ID: 14678 Summary: Update Koha language codes to ISO 639-2 spec Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr http://www.loc.gov/standards/iso639-2/php/code_list.php more info to come... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 14601] New: Cardnumber should not be required for patron import
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '15

02 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14601 Bug ID: 14601 Summary: Cardnumber should not be required for patron import Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: danielle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When importing patrons, cardnumber should not be a required field as it can be NULL. This happens if you are matching or not when importing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 12824] New: Create a general purpose koha-config script?
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '15

02 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12824 Bug ID: 12824 Summary: Create a general purpose koha-config script? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)enger.priv.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The discussion over on bug 12805 (and specifically bug 12805, comment 5 from Viktor) got me thinking... Could we create a general purpose config editing script, at least for the <config> part of koha-conf.xml, instead of having specific scripts for lots of different config settings? If we added a (e.g.) YAML file with some metadata about the different setttings (a description, what kind of data it should contain), we could perhaps have a friendly tool that could - toggle settings off/on ("backup_db_via_tools is currently off, are you sure you want to enable it?") - offer options from a list (e.g. "dom" or "grs1" for the indexing modes) - validate the contents of fields (e.g. check that "port" gets a numeric value, or check that settings that take a path get a path that actually exists) Sample usage: Display all current settings: sudo koha-config -l <instancename> Display a specific setting: sudo koha-config <instancename> opacdir Change a specific setting: sudo koha-config <instancename> backup_db_via_tools=on (If backup_db_via_tools was already enabled, the script could say so and exit, if it was not enabled, it could verify that the user wants to change it, and make sure the value of the setting gets a 1. It could accept different input like "on", "1", "enable" etc) There could even be an interactive mode (sudo koha-config -i <instancename>) which would display something like a numbered list of current settings, let the user choose one and prompt for input, validate the input, display the changed setting etc. Of course, some config changes need more work than just changing the setting. If the user tries to e.g. enable plugins by changing the "enable_plugins" setting, the script could give a friendly warning that the user should instead use the koha-enable-plugins script. The script could perhaps take a --configfile parameter, so it could be used to edit configs for non-package-setups too. Would this just be a lot of work for little gain, or could it be a nice addition for making the threshold lower for inexperienced admins? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10