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

[Bug 12137] New: Extend CalendarFirstDayOfWeek to be any day
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '15

20 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12137 Bug ID: 12137 Summary: Extend CalendarFirstDayOfWeek to be any day Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On the Koha list, Mubassir Ahsan<mahsandu(a)gmail.com> asked: > Is there any option to set Saturday as First Day of Week. Please help me. I > am [stuck]. CalendarFirstDayOfWeek is either Sunday|Monday. By converting it to 0|1|2|3|4|5|6 (Sunday, Monday, ..., Saturday), we can allow any day of the week to be the first day of the week in the date picker. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 11620] New: dissertation-information is only defined for UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '15

20 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11620 Bug ID: 11620 Summary: dissertation-information is only defined for UNIMARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The dissertation-information index is added by bug 11202 for UNIMARC but does not exist for others marc formats. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 9006] New: autoload in C4::Context is a bad idea
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '15

20 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9006 Priority: P5 - low Change sponsored?: --- Bug ID: 9006 Assignee: gmcharlt(a)gmail.com Summary: autoload in C4::Context is a bad idea Severity: minor Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha The comment in C4/Context.pm pretty much sums it up: # AUTOLOAD # This implements C4::Config->foo, and simply returns # C4::Context->config("foo"), as described in the documentation for # &config, above. # FIXME - Perhaps this should be extended to check &config first, and # then &preference if that fails. OTOH, AUTOLOAD could lead to crappy # code, so it'd probably be best to delete it altogether so as not to # encourage people to use it. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 9164] New: Only allow kohaadmin login under special conditions
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '15

20 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9164 Bug ID: 9164 Summary: Only allow kohaadmin login under special conditions Classification: Unclassified 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: m.de.rooy(a)rijksmuseum.nl Would it be an idea to separate the Koha password of kohaadmin [or whatever you name it during installation] from the database password (in terms of security)? Furthermore, is it necessary that kohaadmin can login via opac? And even, could we disable staff client login via kohaadmin under normal circumstances, only allowing login under special conditions (installer, maintenance mode, or so). We could define these conditions and provide a way for system administrators to "force these conditions" without compromising security again. Will ask for some ideas in this regard on the dev list. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 11623] New: Errors with upgrade from 3.00.00.070 to 3.14.02.000
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '15

20 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11623 Bug ID: 11623 Summary: Errors with upgrade from 3.00.00.070 to 3.14.02.000 Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: dswhite42(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are a number of database upgrade errors that take place when upgrading from 3.00.00.070 to 3.14.02.000 * A number of upgrades expect the tables to have foreign keys and be in InnoDB format. In 3.00.00.070, MyISAM (and no foreign keys) is the standard. With no testing to see if the keys exist, these commands fail with (errno: 152) Problem examples: ALTER TABLE issues DROP FOREIGN KEY `issues_ibfk_1` ALTER TABLE issues DROP FOREIGN KEY `issues_ibfk_2` ALTER TABLE `message_transports` DROP FOREIGN KEY `message_transports_ibfk_3` ALTER TABLE patronimage DROP FOREIGN KEY patronimage_fk1 * In updatedatabase.pl, in the section for DBVersion 3.00.00.091, there are references to the @sql_scripts "installer/data/mysql/en/optional/sample_notices_message_attributes.sql" and "installer/data/mysql/en/optional/sample_notices_message_transports.sql" . These should be "installer/data/mysql/en/mandatory/sample_notices_message_attributes.sql" and "installer/data/mysql/en/mandatory/sample_notices_message_transports.sql" * Even when that's corrected, the sample_notices_message_transports.sql script fails because it references foreign keys to the "letters" table that have not been created yet. The reserves/HOLD combo isn't created until the 3.01.00.05 section of the updatedatabase.pl script, and circulation/CHECKIN and circulation/CHECKOUT are not created until the 3.01.00.013 section. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 9422] New: Patron picture uploader ignores patronimages syspref
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '15

20 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9422 Bug ID: 9422 Summary: Patron picture uploader ignores patronimages syspref Classification: Unclassified 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: jcamins(a)cpbibliography.com Although the patronimages syspref says it sets whether or not patron images can be uploaded, in fact all it does is toggle display. The uploader should probably not be available when the feature is disabled, to prevent librarians from getting frustrated when it seems not to work. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 13291] New: Suppress OPACFallback syspref - its use and itself
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '15

19 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13291 Bug ID: 13291 Summary: Suppress OPACFallback syspref - its use and itself 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: frederic(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org Since 'prog' theme doesn't exist anymore, OPACFallback syspref is without object anymore. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 9750] New: bring routing lists in to notices & slips
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '15

19 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9750 Bug ID: 9750 Summary: bring routing lists in to notices & slips Classification: Unclassified 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: nengard(a)gmail.com Routing Lists should be managed in Notices & Slips so that people can customize them with notes or news or whatever they want. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 9055] New: Mandumah.com's multiple branch search, multiple branch security mod
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '15

18 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9055 Priority: P5 - low Change sponsored?: --- Bug ID: 9055 CC: dpavlin(a)rot13.org Assignee: gmcharlt(a)gmail.com Summary: Mandumah.com's multiple branch search, multiple branch security mod Severity: enhancement Classification: Unclassified OS: All Reporter: wrobertson1981(a)gmail.com Hardware: All Status: NEW Version: master Component: Authentication Product: Koha This mod creates the ability to search multiple branches using a jquery dropdown, instead of just one or all branches. This mod also replaces SearchMyLibraryFirst preference, giving three options. All = no change from standard koha setup. Preferhome = Prefers patron's home library (others may be searched), koha's current functionality of SearchMyLibraryFirst. Securehome = Only patrons' home library and other assigned libraries (if any) can be searched. With multiple instances of branchcode inside Borrower extended attributes, a patron can be given multiple branches to search within. The Securehome concept also includes the branch given in the apache enviroment of the host/virtualhost contacted, from OPAC_SEARCH_LIMIT = "branch: blah" This patch not only filters the GetBranches results, filtering the patrons ability to see other branches other than the ones given, it also filters the branches given in the limit branch: search options, so that even if a user manually inputted a branch, they are still only getting what they are ment to get. This enhancement would be useful for big libraries, in which its members would be restricted to searching and borrowing from a subset of its books. Overall, the multiple branch search dropdown should prove useful, even with unsecure installations. What is not included yet, is a method to decide what branches to show to a guest, not-logged-in, user. To use this patch, you need to create a branchcode Patron Extended Attribute, and have the patron your working with, have one or more branchcode extended attributes. So, total branches that patron will get: OPAC_SEARCH_LIMIT branch + Patron record home branch + whatever branchcodes you put into Borrower_attributes. You also need to set the preferences, In opac, set SearchableBranches In Patrons, set multibranch. In Searching, set MultiBranchSelect -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 10762] New: Not able to adjust size of barcode numbers
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '15

17 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10762 Bug ID: 10762 Summary: Not able to adjust size of barcode numbers Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: jesse(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I created a new layout (section 2.5.3.1 in the manual) that just shows the barcode, and I set the font size big. First I did 14, then 32 just to make sure my eyes weren't deceiving me. The numbers below the barcode didn't change size! It seems like the font settings only affect the bibliographic data. What I want to change is the barcode number itself. -- You are receiving this mail because: You are watching all bug changes.

1 9