← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 16:09 | HLT | chris: are you about |
| 16:33 | chris | am now |
| 16:53 | owen | chris, are you guys testing 2.2.2 right now? |
| 16:53 | chris | yep |
| 16:53 | owen | I've run across a possible bug and I wondered if you can duplicate it |
| 16:53 | chris | well hlt and unido are testing |
| 16:54 | whats the bug? | |
| 16:55 | owen | It's in biblio frameworks (MARC structure) under parameters |
| 16:56 | Maybe it's not something that you've gotten into, I don't know. | |
| 16:56 | chris | hmm nope havent looked in there yet |
| 16:56 | owen | I find that when I edit the subfields for a particular tag and save the changes, it does the update like an insert, leaving the original subfields and adding the updated ones as duplicates |
| 16:57 | chris | ahhh |
| 16:57 | im prepared to believe that | |
| 16:57 | ive seen that bug before | |
| 16:57 | owen | So I'm ending up with a list of subfields like this : a,b,z,b,z,a,b,z,b,z,a,a |
| 16:57 | chris | right |
| 16:58 | owen | And of course you can't delete the dups because it just deletes all where subfieldcode = a and tag = 00X |
| 16:58 | chris | yep |
| 16:58 | id bug that | |
| 16:58 | owen | I emailed paul about it, but I haven't heard anything |
| 16:58 | At first I thought it was a bug in my template, but it does the same thing in default | |
| 16:59 | chris | no it will be a bug in the sql |
| 17:01 | owen | I'll wait to see what paul says... |
| 03:18 | Sylvain | hi |
| 04:51 | rach | hi |
| 04:56 | hdl | hi sylvain |
| 04:56 | Sylvain | salut hdl |
| 05:05 | rach | hi |
| 10:29 | kados | hey owen |
| 10:29 | owen | Hi |
| 10:30 | I was just checking out the additem problem. | |
| 10:37 | kados | yea ... looks like we've still got a reserves/renewals problem too |
| 10:38 | owen | The reserves problem is one that just hasn't gotten fixed yet. I bugged it a few weeks ago. |
| 10:38 | The renewals problem is a longstanding one that has never gotten any attention. | |
| 10:38 | Folks are just now noticing it. | |
| 10:39 | Here's the reserve override bug: http://bugs.koha.org/cgi-bin/b[…]ow_bug.cgi?id=969 | |
| 10:40 | Hunh...I thought we /didn't/ have the additem problem on 101, but I see now we do | |
| 10:44 | Yup, looks like it happens in the default template as well--if you try to add a new item, the itemnumber doesn't get saved. | |
| 10:59 | Hopefully not into oblivion | |
| 10:59 | kados | hehe |
| 11:00 | owen | I considered making a blocker, but I guess that's a little overblown |
| 11:16 | kados | here's an error: |
| 11:16 | Mon May 02 13:15:00 2005] [error] [client 192.168.3.51] DBD::mysql::st execute failed: Unknown column 'itemcallnumber' in 'field list' at /usr/local/koha/intranet/modules/C4/Biblio.pm line 1874., referer: https://intranet.athenscounty.[…]em.pl?bibid=33745 | |
| 11:16 | that crops up a few times in the log -- I wonder if it's related | |
| 11:17 | that's also the only additem.pl error in the logs | |
| 11:20 | I think we'll have to wait on paul to fix this one | |
| 11:20 | I'm confused about the renewals bug ... I thought it was a new bug | |
| 11:21 | owen | Well, there's two renewals bugs :) |
| 11:21 | kados | At least staff seems to think there was a time when you couldn't renew an item on reserve |
| 11:21 | owen | I think they're wrong |
| 11:21 | kados | two eh? |
| 11:21 | owen | I think they just didn't realize it was happening |
| 11:21 | kados | ok ... well what are the two bugs? |
| 11:22 | owen | http://bugs.koha.org/cgi-bin/b[…]ow_bug.cgi?id=970 |
| 11:22 | That's the other one | |
| 11:24 | kados | right |
| 11:24 | owen | That's the more perplexing one since we don't know why it's happening |
| 11:26 | kados | the biggest problem is the documentation for this stuff |
| 11:26 | we don't have a clear explanation of how a reserve is placed for instance | |
| 11:26 | or how a renewal occurs | |
| 11:26 | step by step | |
| 11:27 | other than the coede | |
| 11:27 | which takes a while to wade through | |
| 11:27 | (and isn't always consistant) |
← Previous day | Today | Next day → | Search | Index