| Time |
Nick |
Message |
| 07:47 |
|
collum joined #evergreen |
| 08:09 |
|
jeffdavis joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:50 |
|
Dyrcona joined #evergreen |
| 11:02 |
|
sandbergja joined #evergreen |
| 11:30 |
|
jihpringle joined #evergreen |
| 11:35 |
|
pinesol joined #evergreen |
| 11:42 |
|
redavis joined #evergreen |
| 11:53 |
|
jihpringle joined #evergreen |
| 14:19 |
pinesol |
News from commits: LP2097385 Dark Mode z39.50 View MARC modal colors <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=889275f04a55bcec933540cd1427ecd5b84d15d6> |
| 14:49 |
pinesol |
News from commits: LP2107141 dark mode :host selector corrections <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9fc80355383bd2c0b24e7face10f332aaae5aea5> |
| 15:01 |
|
smayo joined #evergreen |
| 15:01 |
smayo |
sleary++ |
| 15:19 |
pinesol |
News from commits: LP2093225 Acq worksheet grid header row colors <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e207c47c895c5ca7cee4c4c360e15fe7dcae2af6> |
| 15:19 |
pinesol |
News from commits: LP1836097 use XML / generate008() to set date <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5ac350f8e66ef772cdee83803ab0cdf2883a4799> |
| 15:19 |
pinesol |
News from commits: LP1836097 Set 008 date to today in new MARC records <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=da7532c8d08f2009374b21ea30ad6a58b5a38327> |
| 15:27 |
|
sandbergja joined #evergreen |
| 16:35 |
eeevil |
Bmagic: re your holds question from last Friday, in EG, it has never (except for a very short time during the 1.2-ish era, and not even in a release, because it grinds everything to a halt) been the case that new items will magically find existing holds and add themselves to the potentials list, and be immediately capturable after adding. the staff are mistaken about it ever working like that. the reason: you would have to retarget (say) 500 holds |
| 16:35 |
eeevil |
each time an item is added to a "hot" record, and that takes (some amount of human-visible) time. put another way, if they want the item say "send me to this pickup lib to fill a hold" at the next scan after it's added, then the item-adding process has to wait for all possibly-related holds to retarget at save time, or they have to delay the next scan until *something* causes that retargeting to happen. That "something" could very well be, say, an A/ |
| 16:35 |
eeevil |
T event -- there's a item-added event hook -- and doesn't need to be built from scratch from the ground up, but (without changing deep, internal logic and definitions) it is probably not simply "toss the item on all possibly-related hold-copy-maps". |
| 17:02 |
|
mmorgan left #evergreen |
| 18:47 |
|
jihpringle joined #evergreen |
| 19:45 |
|
jihpringle joined #evergreen |
