| Time |
Nick |
Message |
| 02:43 |
|
sandbergja joined #evergreen |
| 07:32 |
|
plux joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 08:16 |
|
bos20k joined #evergreen |
| 08:19 |
|
bdljohn joined #evergreen |
| 08:41 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:57 |
|
lsach joined #evergreen |
| 09:03 |
|
jvwoolf joined #evergreen |
| 09:39 |
Dyrcona |
Twenty-three attendees signed up for the hack-a-way. I think that's a record. |
| 09:50 |
JBoyer |
People must have heard the infinite energy center has really good coffee, heh. |
| 09:51 |
Dyrcona |
:) |
| 10:30 |
Bmagic |
good coffee, ha! |
| 10:31 |
Bmagic |
Has anyone dealt with the MARC editor throwing "DATABASE_UPDATE_FAILED" what seems like random. Anything in particular I should be looking for? Perhaps the MARC isn't sound? EG 3.1 XUL |
| 10:34 |
JBoyer |
usually it's that the marc has a problem but it's hard to point to anything in particular. Have any failing examples you can look at? |
| 10:36 |
Bmagic |
Yeah, but of course, the MARC is in the database just fine. It's probably the stuff in the interface that I need to capture |
| 10:36 |
mmorgan |
Bmagic: I have seen that when a staff user was editing a MARC record and made an error with a MARC tag. Could usually find the exact issue in the logs |
| 10:37 |
Bmagic |
ok great. I'm parsing logs now. I was sort of thinking that was the direction |
| 10:40 |
|
Christineb joined #evergreen |
| 10:48 |
JBoyer |
And depending on what kind of postgres logs you keep you may be able to pull the edited marc out of there. |
| 10:49 |
JBoyer |
I suspect the specific problem you'll find is something about invalid marc in the 901 maintainer trigger, bur I don't recall if it gives you the specific failure or not. |
| 11:03 |
|
khuckins joined #evergreen |
| 11:28 |
|
jwoodard joined #evergreen |
| 11:40 |
|
bos20k joined #evergreen |
| 11:53 |
|
nfBurton joined #evergreen |
| 11:55 |
|
yboston joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:43 |
|
bdljohn1 joined #evergreen |
| 12:50 |
|
beanjammin joined #evergreen |
| 13:26 |
|
jvwoolf joined #evergreen |
| 13:27 |
|
khuckins joined #evergreen |
| 13:35 |
|
khuckins joined #evergreen |
| 13:35 |
|
sandbergja joined #evergreen |
| 13:42 |
JBoyer |
Cool, cool. So today is the second time this week that we've heard from libraries where offline mode just won't do the thing. |
| 14:12 |
JBoyer |
Everything appears to work, but the console starts off with a lovely "UpUp is not defined..." and you can't save transactions because there's nothing in the working location box. |
| 14:13 |
JBoyer |
Which is confusing to me, because my understanding is that UpUp has to be working to see the interface at all, so... |
| 14:16 |
Dyrcona |
JBoyer: Tell them to use the XUL offline interface. It still works AFAIK. |
| 14:18 |
JBoyer |
They did, but they tried the web one first. |
| 14:18 |
JBoyer |
Come Nov 17 that work around isn |
| 14:18 |
JBoyer |
t around to work anymore. |
| 14:19 |
JBoyer |
(And we have an increasing number of systems that have never had the xul client installed.) |
| 14:19 |
Dyrcona |
It can be if you build the XUL client or leave the old XUL files in place. |
| 14:20 |
JBoyer |
We'd like to avoid giving them a reason to never move on to the new thing. (so long as the xul client can login some places will never touch the web client. :/ ) |
| 14:21 |
JBoyer |
I'm not in a panic to figure it out, the library today is back online anyway, I just wondered if anyone else has seen this. |
| 14:21 |
Dyrcona |
Understood. |
| 14:21 |
Dyrcona |
I've seen the offline mode fail a number of times, but don't recall that message about UpUp. |
| 14:22 |
JBoyer |
Worse, if you open the staff client, go somewhere else, pull the cable and then go back it works fine. If you close the browser completely, cut the cable, and go back it's DOA. That's the most common scenario... |
| 14:22 |
Dyrcona |
I've also never seen it (personally) in production, nor do I know of any reports of it failing in production here. |
| 14:22 |
Dyrcona |
Yes, that I have seen every single time. |
| 14:22 |
Dyrcona |
If it starts unable to connect, it won't come up. |
| 14:25 |
JBoyer |
That helps. The thing I was most worried about was that it was something local. |
| 14:25 |
|
khuckins joined #evergreen |
| 14:25 |
JBoyer |
or difficult to reproduce, etc. |
| 14:57 |
|
jvwoolf joined #evergreen |
| 15:00 |
|
khuckins joined #evergreen |
| 15:03 |
|
yboston joined #evergreen |
| 15:45 |
berick |
someone remind me what the copy_active flag is for on copy_status? I see refs to it in the rank_copy SQL (for catalog display?) but that's about it. feel like I'm missing something... |
| 15:46 |
berick |
oh right active_date, which is checked for age protect |
| 15:46 |
Dyrcona |
It means that copy is active for circulation, etc. It's main use is setting the active date on the copy itself. |
| 15:47 |
Dyrcona |
:) |
| 16:47 |
|
yboston joined #evergreen |
| 16:56 |
pinesol |
[evergreen|Remington Steed] Docs: Fix minor release notes formatting bug - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7dd1ec8> |
| 16:56 |
mmorgan |
Happy Halloween #evergreen! |
| 16:57 |
|
mmorgan left #evergreen |
| 17:22 |
|
jvwoolf joined #evergreen |
| 19:03 |
|
beanjammin joined #evergreen |
| 20:41 |
|
beanjammin joined #evergreen |
| 20:59 |
|
jasong joined #evergreen |
