December 2011 - Koha-bugs - lists.koha-community.org

[Bug 7224] New: Allow patrons to pick their own preferred language
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7224 Bug #: 7224 Summary: Allow patrons to pick their own preferred language Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: ian.walls(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com Depends on: 6481 Allow patrons to select their own preferred language, individually. This can provide an extra level of personalization in multi-lingual environments, and could later be applied to more than just the OPAC or staff client templates (translated notices). The choice should be configurable in the OPAC, under Preferences, without the need to confirm with the librarian (like for contact info changes) The structural changes to Koha required for this development would pave the way for a whole bunch of other individual preference values (beyond just messaging and OPAC privacy preferences), making for more customizable ILS -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 7343] New: search tag usability in MARC framework
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7343 Bug #: 7343 Summary: search tag usability in MARC framework Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: gaetan.boisson(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com After searching for a tag in a marc framework, the list of tags is shown starting with the tag we are looking for, but pages prior to the match are not shown at all, leaving users under the impression that these tags have disappeared. My take on this is that we should either make it work as a filter and only display the match, it would then be clear for the user that he has to empty the search field in order to view the complete list of tags. Or make it work as a simple search that would take us on the page of the match (and maybe highlight the result) but without discarding the previous pages. The behaviour is the same when editing subfields: if the user uses the pagination to go edit the subfields for 995 and then clicks on the name of the framework in the breadcrumb, the page shown is the result page for a search on 995, which hides all the previous pages. This is even more problematic as the user hasn't used the searched box at this point. (In that case i think the link should take the user on the first page of the framework, which is consistent with what is written on the link he has clicked: the name of the framework.) This is the behaviour in 3.6, 3.4 and 3.2. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 7223] New: Move borrowerRelationship to Authorised Values list
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7223 Bug #: 7223 Summary: Move borrowerRelationship to Authorised Values list Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com Rather than a system preference of pipe-delimited values (user unfriendly!), this list should be stored in our all-purpose Authorised Values engine. This will allow for a separation of Code and display values, as well as remove a system preference (there are too many) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 7149] New: authorized values for indicators don't work
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7149 Bug #: 7149 Summary: authorized values for indicators don't work Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com In the frameworks if you click 'edit' to the right of a tag (not a subfield) the last option says "(if you select a value here, the indicators will be limited to the authorized value list)" but they don't seem to work. I tried this and the indicators were still just text boxes, not pull downs. Did this ever work? If so, is there a trick? Or is this just a bug? -- 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 3

[Bug 6946] New: Import Batches _update_batch_record_counts has inefficient SQL
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6946 Bug #: 6946 Summary: Import Batches _update_batch_record_counts has inefficient SQL Classification: Unclassified Change sponsored?: --- Product: Koha Version: Rel_3_8 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org The queries to update the number of biblios and the number of items for any given import batch are much slower than they need to be. UPDATE import_batches SET num_biblios = (SELECT COUNT(*) FROM import_records WHERE import_batch_id = import_batches.import_batch_id AND record_type = 'biblio') WHERE import_batch_id = ? UPDATE import_batches SET num_items = (SELECT COUNT(*) FROM import_records JOIN import_items USING (import_record_id) WHERE import_batch_id = import_batches.import_batch_id AND record_type = 'biblio') WHERE import_batch_id = ?") The "AND record_type = 'biblio'" lines are unnecesary; every record within the same import_batch_id will have the same record_type, and more importantly, 'biblio' is currently the only supported type. Removing the line changes the return time of the subquery from over 2 seconds down to 0.01 seconds (on my machine with 34944 items in a batch). I think this is going to be faster than adding an index on record_type. -- 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 3

[Bug 6563] New: Default OPAC language not set properly
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6563 Bug #: 6563 Summary: Default OPAC language not set properly Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: I18N/L10N AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org For libraries with multiple installed and enabled OPAC languages, the first enabled language in the list of activated languages is selected as default, not the primary language for the installation. To reproduce: 1. Install multiple OPAC languages 2. Active one that is 'higher' on the list than your native install language 3. Go to the OPAC, and see that that language, not your native language, displays Root of the problem: Line 57 of opac/opac-main.pl references "opac-main.tmpl", which no longer exists since the conversion to Template::Toolkit. Changing this to opac-main.tt fixes the issue. Patch forthcoming. -- 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 13

[Bug 6416] New: koha-remove fails when dropping user
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6416 Bug #: 6416 Summary: koha-remove fails when dropping user Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org I have MySQL running on the same machine as Apache/Koha, and have created a new library with "sudo koha-create --create-db demo". When i do "sudo koha-remove demo" I get this: Removing Koha instance demo ERROR 1396 (HY000) at line 1: Operation DROP USER failed for 'koha_demo'@'%' When I log in to mysql as root and do this: DROP USER failed for 'koha_demo'@'%'; I get pretty much the same message. But when I replace % with localhost and do this: DROP USER failed for 'koha_demo'@'localhost'; it succeeds. -- 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 4

[Bug 6798] New: Make koha-create send email with details of created site
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6798 Bug #: 6798 Summary: Make koha-create send email with details of created site Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: magnus(a)enger.priv.no ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org The packages are so awesome, it takes way longer to tell someone you set up an instance for them, than to create the actual instance. So why not make koha-create do even more of the work? I'm thinking of adding two more options: --emailto = Make koha-create send an email to the given address that contains the URLs for OPAC and intranet, username and password. This could be someone who is going to use the instance, or yourself, for future reference or forwarding to whoever needs it. --emailtemplate = point to a custom template for the email, instead of the default one. I'm thinking both of these could be set in the configfiles, as well as on the command line. If you have two different configfiles you might want to have different email templates for each of them. The one usecase I can think of for having the email in a configfile is if you want to send the details of created instances to yourself, either just as a reminder or for forwarding to whoever else needs the information. Sending the password in an email like this might be A Bad Thing, but the passwords are supposed to be temporary anyway, right? -- 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 1

[Bug 5851] New: SIP Slips printed in wrong circumstances -- Local hold and no hold items
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5851 Bug #: 5851 Summary: SIP Slips printed in wrong circumstances -- Local hold and no hold items Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Here is how we would like the check-in process to work in Koha on the SIP connection: 1) a WALKIN item type should never generate a hold slip (currently does) 2) a LOCALHOLD type should only generate a hold slip if there is an unfilled hold for a local patron (currently does for any hold) 3) If a hold slip is generated for any valid circumstances... a) the item processed should be tied to the patron on the slip b) the item should be in the proper status (hold should be confirmed and put in transit if necessary) In summary, when a hold slip is generated we should be able to place the slip in the item and put it in the courier or on our hold shelf. -- 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 6676] New: Acquisition basket access control trivially by-passable
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6676 Bug #: 6676 Summary: Acquisition basket access control trivially by-passable Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: ef(a)math.uni-bonn.de QAContact: koha-bugs(a)lists.koha-community.org Currently, while booksellers.pl tries to restrict a user's ability to view baskets, that's trivially circumvented by simply altering the basketno CGI parameter to, e.g. baket.pl. I can think of three ways to close this security hole: 1. Check permissions in every script that deals with baskets. This would probably require an extension to C4::Auth. 2. Randomise basket numbers. 3. Add a random key to each basket that must be given as a CGI parameter (in addition to basketno) in order for a script to allow access to that basket. -- 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 6