Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 15:07 | fbcit | I used to have a button to add a new MARC record |
| 15:08 | arsenic | fbcit: did you change something in the YUI config? |
| 15:08 | fbcit | no, but yui has been upgraded since yesterday |
| 15:09 | arsenic | ok.. that is probaly wuy. who changed that? |
| 15:09 | wuy = why | |
| 15:09 | fbcit | it was upgraded to the latest ver |
| 15:10 | arsenic | the latest version of YUI doesn't support button.beta |
| 15:10 | it's now just button | |
| 15:16 | hdl | owen around ? |
| 15:44 | fbcit | anyone else rebased up and missing the tool bars from either addbooks.pl or members-home.pl? |
| 15:44 | paul_ | yes, i've rebased |
| 15:44 | and see that the nice buttons have disappeared :-( | |
| 15:44 | replaced by a standard link | |
| 15:44 | (hi fbcit) | |
| 15:45 | fbcit | paul_: I'm missing the link too |
| 15:45 | hello paul | |
| 15:45 | hdl | think it is because of change in yui version. |
| 15:45 | atz | most likel |
| 15:45 | *likely | |
| 15:45 | paul | yep |
| 15:45 | hdl | patch it up with frederic patch |
| 15:46 | kados | paul: can you confirm bug 2020? |
| 15:46 | have you guys tried shift-refresh? | |
| 15:48 | fbcit | tnx hdl |
| 15:48 | paul | kados : nope, I can't confirm it. I don't have the problem. |
| 15:48 | hdl | mice and men is searching OK. |
| 15:48 | paul | http://o18.bureau.paulpoulain.[…]=harry+and+potter |
| 15:49 | hdl | and returning no biblio |
| 15:49 | paul | (same for i18, but no public login) |
| 15:49 | MatthewMetzger | hdl: really? I can help isolate it, if needed |
| 15:49 | kados | :( |
| 15:49 | paul | (and = et in french. I suspected an empty word problem) |
| 15:49 | kados | paul: it sounds like a load problem |
| 15:50 | paul: how big is your database? | |
| 15:50 | paul | around 15 000 biblios |
| 15:51 | no problem, even when i've added AND as a stopword. | |
| 15:51 | kados | I will ask some additional questions on bugzilla |
| 15:51 | so it could be a MARC21 prob | |
| 15:52 | or it could be too many records | |
| 15:52 | or maybe not right hardware for him | |
| 15:52 | I'll ask | |
| 15:52 | MatthewMetzger | kados: bugzilla is good. I'm the reporter of the bug, so if you need fast answers, I'm here. |
| 15:52 | kados | oh, hi MatthewMetzger |
| 15:52 | MatthewMetzger: so ... how many bib and items? | |
| 15:53 | MatthewMetzger | I believe just under 6000 items. Is there a fast way to check from the admin interface? |
| 15:53 | kados | ok, that's small |
| 15:53 | very strange | |
| 15:53 | MatthewMetzger | we have a very small library |
| 15:53 | kados | MatthewMetzger: I may have some time tonight to test marc21 searching with nozebra on |
| 15:53 | MatthewMetzger: otherwise, maybe paul or hdl can help right now | |
| 15:54 | I've got to head to a presentation | |
| 15:54 | ttyl | |
| 15:54 | MatthewMetzger | okay. I'll answer the questions on bugzilla, so it's documented. |
| 15:54 | kados: good luck on your presentation | |
| 15:54 | paul | MatthewMetzger: do you have the problem with a search containing "OR" ? |
| 15:54 | "NOT" | |
| 15:54 | MatthewMetzger | paul: I'll check right now... |
| 15:54 | paul | like "mice or men" |
| 15:55 | q=mice and men should be interpreted as "search mice" and do a AND with "search men" | |
| 15:57 | MatthewMetzger | mice or men - same behavior, ramps up cpu and memory usage. I have to kill the process. |
| 15:57 | paul | a search on "mice" works fine ? |
| 15:57 | idem for a search on "men" | |
| 15:57 | ? | |
| 15:59 | MatthewMetzger | mice works fine. |
| 16:00 | individual words and author's names return searches fine. | |
| 16:00 | paul | could you set debug ON and tell me what appears on the log ? |
| 16:00 | MatthewMetzger | It seems that "and" and "or" in the search cause the "crash" |
| 16:01 | paul: could you remind me where that setting is? | |
| 16:01 | It may already be on. | |
| 16:01 | paul | in the virtual host, just add : SetEnv DEBUG 1 |
| 16:01 | MatthewMetzger | what log file am I looking for |
| 16:01 | paul | in the virtual host, just add : SetEnv DEBUG=1 |
| 16:01 | the one you see in the apache VHost | |
| 16:01 | MatthewMetzger | okay, just a minute |
| 16:02 | paul | no, it's SetEnv DEBUG 1 |
| 16:02 | definetly | |
| 16:02 | i have to leave. | |
| 16:03 | you'll see things like : | |
| 16:03 | warn "query =$query" if $DEBUG; | |
| 16:03 | query = ... | |
| 16:03 | string : .... | |
| 16:03 | no parenthesis. left : ... operator: ... right: ... | |
| 16:04 | node : .../.../... | |
| 16:04 | leftresult : ... | |
| 16:04 | rightresult : ... | |
| 16:04 | paste everything in bugzilla pls | |
| 16:04 | you may also get : "NZAND" | |
| 16:23 | hdl | gmcharlt: around ? |
| 16:24 | gmcharlt | hdl: yes |
| 16:25 | hdl | I am experiencing some differences between "box search" and advanced kw search |
| 16:25 | is this expected ? | |
| 16:26 | http://o17.hdlaurent.paulpoula[…]ha/opac-search.pl | |
| 16:26 | 24.082 | |
| 16:26 | you have 2 results | |
| 16:27 | with advanced search, you get 29 | |
| 16:31 | in fact, queries generated are not the same : | |
| 16:32 | 24.082 for the simple one | |
| 16:32 | @attr 1=1016 @attr 4=6 24.082 for advanced one. | |
| 16:34 | gmcharlt | hdl: yeah, looks like one is interpreting as a phrase search, and one is interpreting as a keyword search with like "24 and 082" |
| 16:35 | hdl | well... This is quite embarassing... Because depending on the place you type your query, results are not the same. |
| 16:35 | Worse, | |
| 16:35 | gmcharlt | probably should be made consistent, but we should think carefully about when and where to add qualifiers to a default search |
| 16:36 | hdl | results with advanced search are less accurate than with simple box. |
| 16:36 | I agree. | |
| 16:37 | Would there be a place where we may think together and define some test cases ? | |
| 16:37 | Maybe a google document would be fine ? | |
| 16:38 | gmcharlt | that, or use the dev wiki |
| 17:11 | tim | When I click on a call number in the search results of the opac or intranet interface I get the error No results match your search for “callnum:AF KOO" using version3 beta2. |
| 17:17 | There are no errors in the logs for this, but getting to the search results screen gives me an error 3 times. | |
| 17:17 | File does not exist: /usr/share/koha/intranet/htdocs/opac-tmpl, referer: http://koha2.wlpl.org:8080/cgi[…]sort_by=relevance | |
| 17:19 | That was from Koha-error_log. I don't get any errors on the OPAC. | |
| 17:20 | Or at least not in the logs. Just in the browser. | |
| 17:21 | hdl | you could have errors in zebra logs. |
| 17:25 | tim | That's wierd. Zebra hasn't logged anything. |
| 17:49 | I got zebra logging. Nothing in the error log, but there was an error in the output log. | |
| 17:49 | Search biblios ERROR 114 1 1+0 RPN @attrset Bib-1 @attr 1=20 "AF KOO" | |
| 17:50 | That was the koha-zebradaemon-output.log | |
| 17:50 | gmcharlt | tim: looks like a missing indexing definition (or a mismatched one) |
| 17:51 | enough for me to go on | |
| 17:54 | tim | I was thinking it would probably be something like that. |
| 17:55 | I was also thinking I don't know what to do about it. Would that be in record.abs? | |
| 18:13 | gmcharlt | tim: yes, looking in record.abs to verify that appropriate MARC fields are mapped to callnumber index, bib1.att to confirm attribute (1=20) and ccl.properties to verifying that callnumber is mapped to the 1=20 attribute |
| 19:32 | ryan | tim: also, be sure you actually have data in the itemcallnumber field. |
| 19:33 | tim: note the default frameworks have changed quite a bit from 2.2 -> 3.0 , so you'll have to deal with mapping | |
| 20:26 | MatthewMetzger_ | Regarding bug 2020: I noticed a discrepancy with with my perl install. mod_perl is 5.8.8 while koha reports it as 5.010000. (5.10.0). Could this be a problem? |
| 22:28 | tim | thanks gmcharlt. I finally got the time to try what you suggested (a long time ago now) and it worked. |
| 22:43 | gmcharlt | tim: great! |
Today | Next day → | Search | Index