June 2012 - Koha-bugs - lists.koha-community.org

[Bug 7705] New: IE postdata issue - expiring sessions when back button is used
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7705 Priority: P5 - low Change sponsored?: --- Bug ID: 7705 Assignee: oleonard(a)myacpl.org Summary: IE postdata issue - expiring sessions when back button is used QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: shelley.gurney(a)nzica.com Hardware: All Status: NEW Version: rel_3_6 Component: OPAC Product: Koha The majority of our users are still using IE and navigate via the browser buttons. This is causing some issues with their sessions expiring when they navigate forwards and backwards several times. Is there a fix for this in Koha, to stop this from happening? Can we trick IE into not cancelling the session. (not an apparent issue in Chrome or Firefox) -- You are receiving this mail because: You are watching all bug changes.

1 2

[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 7524] New: Make it possible to generate a .koc file using the Firefox KOCT plugin
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7524 Bug #: 7524 Summary: Make it possible to generate a .koc file using the Firefox KOCT plugin Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com I tried testing the Firefox plugin for offline circulation today, because I was not aware that the feature is still blocked by bug 5877. As the missing tables are scheduled to be added for 3.8, it's currently not possible to make use of this nice plugin for older versions of Koha. A nice enhancement would be an option to generate a standard .koc file from the plugin. The upload option is already in Koha for a longer time, so a lot of libraries could make use of the plugin without having to wait for the release of the new version and updating. -- 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 4

[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 7594] New: Google Cover CSS suggestions
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7594 Bug #: 7594 Summary: Google Cover CSS suggestions Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: ssammons(a)npelem.com QAContact: koha.sekjal(a)gmail.com In google-jackets.js there is hard coded "style" on line 48 using... http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=koha-tmpl/opac-tm… I suggest this is moved to a .css file, as to allow the end user to impose changes to the style. Additionally, it would be nice if a unique class can be added to all the image preview types. Currently they are all dynamic (class & id). Added a class such as "gbs-cover" or similar would allow end users to use CSS to uniquely style each book cover used. I am not able to find where this is generated or I would suggest the lines of code to change. Finally, the "No Image Available" does not appear in the HTML source code. The JS shows it creating a "span" element with a class of no-image. Is there anyway to actually have that appear in the actual source code? All suggested changes should allow for an end user to have easier and clearer control of OPAC search generated images. -- 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 5

[Bug 8280] New: SRU should be filterable by Koha Item Type
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8280 Priority: P5 - low Change sponsored?: --- Bug ID: 8280 CC: m.de.rooy(a)rijksmuseum.nl Assignee: gmcharlt(a)gmail.com Summary: SRU should be filterable by Koha Item Type Severity: enhancement Classification: Unclassified OS: All Reporter: martin.renvoize(a)ptfs-europe.com Hardware: All Status: NEW Version: rel_3_8 Component: Z39.50 / SRU / OpenSearch Servers Product: Koha It would be very useful to be able to query the SRU server by the current index's in Koha, including the Item Type Index. My understanding is the standard CQL queries should work, so: :9998/biblios?version=1.1&operation=searchRetrieve&query=itype=XXX should yeild results conatining all records of itype (952$y in Marc21 Koha) XXX, but I have not been able to get this to work. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 8331] New: hidden field does not work accurately
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8331 Priority: P5 - low Change sponsored?: --- Bug ID: 8331 Assignee: gmcharlt(a)gmail.com Summary: hidden field does not work accurately Severity: normal Classification: Unclassified OS: All Reporter: epietrocupo.hlhl(a)ssss.gouv.qc.ca Hardware: All Status: NEW Version: rel_3_6 Component: MARC Bibliographic data support Product: Koha There is this bug that seem similar http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1756 But it does not seem to solve my problem. The hidden field does not hide what it should hide. The first problem is the documentation which is simply illogical if it's a simple bitfield: --------------------------------------- 9 => Future use -8 => Flag -7 => OPAC !Intranet !Editor Collapsed -6 => OPAC Intranet !Editor !Collapsed -5 => OPAC Intranet !Editor Collapsed -4 => OPAC !Intranet !Editor !Collapsed -3 => OPAC !Intranet Editor Collapsed -2 => OPAC !Intranet Editor !Collapsed -1 => OPAC Intranet Editor Collapsed 0 => OPAC Intranet Editor !Collapsed 1 => !OPAC Intranet Editor Collapsed 2 => !OPAC !Intranet Editor !Collapsed 3 => !OPAC !Intranet Editor Collapsed 4 => !OPAC Intranet Editor !Collapsed 5 => !OPAC !Intranet !Editor Collapsed 6 => !OPAC Intranet !Editor !Collapsed 7 => !OPAC Intranet !Editor Collapsed 8 => !OPAC !Intranet !Editor !Collapsed 9 => Future use --------------------------------------- If you try to find the binary pattern in this you will not be able to do it. For example, I found that the 3rd bit ( value 4 ) trigers the display in the editor. According to the table above, 4 does not trigger it, but 5 does. But 5 is a combination of 4 and 1, so if 5 does, than 4 should block it too since 1 since used for collapsing. According to my tests: Bit 1 (value 1): Trigger the collapsing Bit 2 (value 2): does nothing Bit 3 (value 4): Hide the field from the editor Bit 4 (value 8): does nothing Sign Bit (+/-): does nothing Which leave the following options not working: Hide in OPAC Hide in Intranet I tried it with field 590 and field 300 which both are shown in OPAC and intranet. I was wondering if there could be something else that could override the the hidden field. -- 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