| Time |
Nick |
Message |
| 06:56 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
rfrasur joined #evergreen |
| 07:48 |
|
collum joined #evergreen |
| 08:30 |
|
mantis1 joined #evergreen |
| 08:40 |
|
sandbergja joined #evergreen |
| 08:48 |
|
dbwells joined #evergreen |
| 08:50 |
|
mmorgan joined #evergreen |
| 09:11 |
|
Dyrcona joined #evergreen |
| 09:12 |
|
alynn26 joined #evergreen |
| 09:40 |
|
jvwoolf1 joined #evergreen |
| 09:50 |
|
rfrasur joined #evergreen |
| 09:55 |
|
mllewellyn joined #evergreen |
| 09:55 |
|
mllewellyn left #evergreen |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:22 |
|
mmorgan joined #evergreen |
| 10:32 |
|
rfrasur joined #evergreen |
| 10:56 |
jeff |
Interesting. Getting ACTOR_USER_NOT_FOUND when overriding a checkout event in 3.1 webstaff, problem seems to be that the checkout.full.override call has arguments that include a null patron_id |
| 10:59 |
* jeff |
eyes bug 1852316 |
| 10:59 |
pinesol |
Launchpad bug 1852316 in Evergreen "Overrideable events at checkout should not be hard coded" [Undecided,New] https://launchpad.net/bugs/1852316 |
| 11:01 |
mmorgan |
jeff: We're beyond 3.1, but I don't remember encountering ACTOR_USER_NOT_FOUND when overriding. |
| 11:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:02 |
* mmorgan |
also ponders the reasoning behind hard-coded overrideable events ... |
| 11:05 |
Dyrcona |
It's easier that way. Sometimes generic overrides are hard. |
| 11:07 |
mmorgan |
Problematic in the long run, though :-( |
| 11:14 |
dbs |
ah that fun moment when you realize you've been running through the OpenSRF install instructions meant for your dev system on your production system instead |
| 11:16 |
dbs |
theoretically opensrf 3.2 should just work in place of 3.1, I suppose |
| 11:18 |
dbs |
apache websockets should continue to function as before |
| 11:18 |
dbs |
Guess I'll test restarting things late at night and see if anything blows up :) |
| 11:19 |
jeff |
found it. local experiment. |
| 11:23 |
Dyrcona |
dbs: Yeah, it should work. |
| 11:23 |
|
yboston joined #evergreen |
| 11:25 |
|
khuckins joined #evergreen |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:14 |
|
nfBurton joined #evergreen |
| 12:19 |
|
Christineb joined #evergreen |
| 12:38 |
|
collum joined #evergreen |
| 12:52 |
|
jihpringle joined #evergreen |
| 13:01 |
|
jvwoolf joined #evergreen |
| 13:17 |
|
sandbergja joined #evergreen |
| 13:57 |
|
yboston joined #evergreen |
| 14:22 |
|
jvwoolf joined #evergreen |
| 14:53 |
|
mantis2 joined #evergreen |
| 14:53 |
|
laurie_ joined #evergreen |
| 14:54 |
|
Christineb_ joined #evergreen |
| 14:56 |
|
bshum_ joined #evergreen |
| 15:14 |
|
Christineb joined #evergreen |
| 15:28 |
|
khuckins joined #evergreen |
| 15:35 |
|
nfBurton joined #evergreen |
| 15:48 |
|
mantis2 left #evergreen |
| 16:14 |
dbs |
hmm. is COPY_DELETE_WARNING.override dialogue expected when an item is in "lost & paid" status? We're not sure what alternative there is to deleting an item in this status |
| 16:15 |
dbs |
seems like that was the intention of bug # 1735566 |
| 16:18 |
mmorgan |
dbs: I would expect that dialog if config.copy_status.restrict_copy_delete were set to TRUE for the Lost & Paid status. |
| 16:18 |
dbs |
mmorgan: right - i understand that Lost & Paid is a 'precarious' status, but are there any other steps to be followed before deleting it that would avoid that warning? |
| 16:18 |
mmorgan |
Ours is set to FALSE, as we don't see an alternative to deleting them. |
| 16:19 |
dbs |
checking it in seems like a bad idea :) |
| 16:19 |
dbs |
Ah, that's a good approach. Wonder why TRUE is the default... |
| 16:20 |
mmorgan |
dbs: Agreed that checking them in is a bad idea :) |
| 16:25 |
dbs |
mmorgan++ |
| 16:37 |
dbs |
"npm install -g @angular/cli@^7.0.7", alright... |
| 16:48 |
dbs |
"Open-ILS/src/eg2/src/styles.cssBrowserslist: caniuse-lite is outdated. Please run next command `npm update caniuse-lite browserslist`" |
| 16:48 |
dbs |
Should I actually run that? |
| 16:50 |
berick |
dbs: IIRC, the udpate won't succeed cuz dependencies |
| 16:51 |
dbs |
mmm, okay. thanks berick++ |
| 16:52 |
|
rfrasur joined #evergreen |
| 16:58 |
dbs |
now to try and figure out why I'm seeing "Firefox have not captured in 60000 ms, killing" when firefox is installed :/ |
| 17:02 |
|
mmorgan left #evergreen |
| 17:21 |
* dbs |
gives up |
| 21:06 |
|
sandbergja joined #evergreen |
| 21:23 |
|
sandbergja joined #evergreen |
| 21:38 |
|
rfrasur joined #evergreen |
| 22:35 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 23:46 |
|
sandbergja joined #evergreen |
