Time |
Nick |
Message |
00:02 |
|
dat_ joined #evergreen |
00:03 |
dat_ |
Hi all1 I need help. when I started Z39.50 import, error message appears ---> TypeError: obj.active_services is undefined <--- I use version 2.5 |
01:38 |
|
letsgofightdrag1 joined #evergreen |
01:54 |
|
letsgofightdrag1 joined #evergreen |
02:21 |
|
letsgofightdrag2 joined #evergreen |
05:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:34 |
|
wsmoak joined #evergreen |
06:34 |
|
wsmoak joined #evergreen |
06:35 |
|
eeevil joined #evergreen |
06:36 |
|
Callender joined #evergreen |
06:36 |
|
TaraC joined #evergreen |
06:36 |
|
phasefx joined #evergreen |
06:36 |
|
mtate joined #evergreen |
06:37 |
|
graced joined #evergreen |
07:05 |
|
letsgofightdrag2 left #evergreen |
07:28 |
|
RBecker joined #evergreen |
07:41 |
|
sarabee joined #evergreen |
07:47 |
|
rjackson-isl joined #evergreen |
07:55 |
|
akilsdonk joined #evergreen |
08:08 |
csharp |
@weather 30345 |
08:08 |
pinesol_green |
csharp: The current temperature in North Briarcliff, Atlanta, Georgia is 17.2°F (8:08 AM EST on November 19, 2014). Conditions: Clear. Humidity: 70%. Dew Point: 8.6°F. Windchill: 17.6°F. Pressure: 30.44 in 1031 hPa (Rising). |
08:08 |
|
mrpeters joined #evergreen |
08:08 |
csharp |
brrrrr |
08:19 |
|
RBecker joined #evergreen |
08:33 |
|
_bott_1 joined #evergreen |
08:33 |
|
dkyle joined #evergreen |
08:39 |
|
mmorgan joined #evergreen |
08:49 |
|
collum joined #evergreen |
08:58 |
tsbere |
csharp: Heh, I should bug my friend down there. He is probably hating the temp too. |
09:02 |
rjackson-isl |
chsarp: Saw an ammusing weather update on bbc.com this AM indicating all 50 states were experiencing freezing temperatures! Can I get a snopes fact check on that? ;-) |
09:03 |
csharp |
heh |
09:04 |
collum |
@weather 96740 |
09:04 |
pinesol_green |
collum: Error: timed out |
09:05 |
csharp |
rjackson-isl: http://www.weather.com/weather/map/interactive/30334 makes it look like that's true |
09:07 |
rjackson-isl |
maybe it is snowing on the lava flows! |
09:08 |
tsbere |
csharp/rjackson-isl: Did anyone bother to look at Hawaii? |
09:09 |
collum |
That's what that random Zip was. That's what I get for choosing a random Zip |
09:09 |
csharp |
@weather honolulu |
09:09 |
pinesol_green |
csharp: The current temperature in Pacific Heights, Honolulu, Hawaii is 73.4°F (4:07 AM HST on November 19, 2014). Conditions: Scattered Clouds. Humidity: 68%. Dew Point: 62.6°F. Pressure: 30.08 in 1018 hPa (Rising). |
09:09 |
csharp |
looks like 49 of the 50 states then ;-) |
09:09 |
tsbere |
@weather houston, tx |
09:09 |
pinesol_green |
tsbere: The current temperature in SE-Svc-Cntr, Houston, Texas is 50.2°F (8:09 AM CST on November 19, 2014). Conditions: Clear. Humidity: 82%. Dew Point: 44.6°F. Pressure: 30.36 in 1028 hPa (Steady). |
09:10 |
rjackson-isl |
http://www.npr.org/blogs/thetwo-way/2014/11/18/364972644/baby-its-cold-outside-all-50-states-hit-32-degrees |
09:10 |
rjackson-isl |
guess I should have checke! |
09:10 |
csharp |
"Yep. Even Hawaii, where Mauna Kea, a dormant volcano reaching 13,800 feet above sea level, was below freezing." |
09:10 |
csharp |
so hah! in your face, snopes! |
09:22 |
|
kmlussier joined #evergreen |
09:23 |
|
mdriscoll joined #evergreen |
09:34 |
mrpeters |
nobody is up in Buffalo right? yikes...i will stop complaining about 2 inches of snow now |
09:35 |
mrpeters |
do the bills have a home game this week? haha that might be worth tuning into if it were on tonight :) |
09:39 |
jeff |
Buffalo snow Buffalo snow snow snow Buffalo snow: https://twitter.com/CathyWurzer/status/535061638735355904 |
09:54 |
* tsbere |
has dealt with things like that before. Not fun. |
09:55 |
|
Shae joined #evergreen |
10:04 |
rjackson-isl |
wonder if the family vehicle is in the driveway? |
10:13 |
mrpeters |
wow jeff that is uts |
10:16 |
csharp |
dbs++ # your SQL function template saved me tons of time and heartache ;-) |
10:17 |
csharp |
jeff: wow - it took me several seconds to comprehend that photo |
10:18 |
* csharp |
is from a place where 2" of snow shuts the entire area down for days |
10:19 |
csharp |
the blizzard of 1993 was the most snow I remember |
10:19 |
csharp |
and that was something like 3 feet where I was |
10:21 |
|
sbrylander joined #evergreen |
10:21 |
|
dcook joined #evergreen |
10:31 |
dbs |
csharp++ # so happy it helped! |
10:33 |
mrpeters |
tsbere: i was looking at one of your old patches (http://markmail.org/thread/heeacpi4p46s26vw) in reference to bug 300789 -- I'm curious...did you go the prefs.js route for this for flexibility, or was that the only way to make the toolbar buttons open in new tabs? I'm looking at a patch to do the same for the F keys. |
10:34 |
pinesol_green |
Launchpad bug 300789 in gnuvd (Ubuntu) "Please merge gnuvd 1.0.10-1 (multiverse) from Debian unstable (contrib)" (affected: 0, heat: 4) [Wishlist,Fix released] https://launchpad.net/bugs/300789 |
10:34 |
mrpeters |
ehhh not that bug -- https://bugs.launchpad.net/evergreen/+bug/1300789 |
10:34 |
pinesol_green |
Launchpad bug 1300789 in Evergreen "F4 (Search for Patrons) Results in Multiple Popup Errors if Interrupted" (affected: 3, heat: 16) [Undecided,Confirmed] |
10:36 |
tsbere |
mrpeters: I figured I might eventually make an actual menu option for changing it, and not everyone *wants* the same behavior on the toolbar buttons. |
10:36 |
mrpeters |
yeah, agreed |
10:36 |
mrpeters |
im not sure of another way to avoid the reported bug (other than not hitting one key, then quickly hitting another) |
10:36 |
tsbere |
mrpeters: The latter means it had to be an option *somewhere* and prefs.js is basically "workstation level" - Which for us is important due to our members insisting on use of generic accounts instead of individual accounts |
10:37 |
mrpeters |
10-4 |
10:39 |
mrpeters |
part of me wants to say "Will not fix" to this....if I recall, the library has some history of bitterness towards Evergreen and just looks for anything they can break, to sway their director back to another ILS |
10:42 |
mrpeters |
jboyer-isl: rjackson-isl: would you want a one-off patch for this to make all of the F keys open in new tabs? I highly doubt that would be accepted into master, but if it solves the bug for your customer I'm happy to work on it |
10:44 |
kmlussier |
mrpeters: If it is truly a bug, then that's probably not a good reason to set it to "Won't Fix." The new web client may be a better reason to set it to "Won't Fix," but it should probably wait until the web client is ready for production. :) |
10:44 |
kmlussier |
mrpeters++ #Looking at dusty bugs. |
10:45 |
mrpeters |
im not sure it is a bug |
10:45 |
mrpeters |
you are stopping the page load (so the javascript doesnt get to render) by refreshing (or changing) the contents of the tab |
10:46 |
mrpeters |
holding down the key does a refresh, hitting F4 then F3 real quick is like a stop, then load new page |
10:46 |
jboyer-isl |
mrpeters, I'd say don't worry about it. The whole thing goes away with the web client, and I imagine that very few people would want their F-keys to always be new tabs, especially just to get around this one sort-of-bug. |
10:46 |
mrpeters |
so all of the getStrings stuff for the patron search form doesnt get time to render. I'm not sure how we would avoid those popups, since they are legitimate errors. |
10:47 |
tsbere |
I can reduce the number of errors. <_< |
10:47 |
* tsbere |
has gotten it down to 1 per, it appears, with some menu.js code changes |
10:47 |
mrpeters |
which error stays around? |
10:48 |
tsbere |
looks like TypeError: $("commonStrings") is null |
10:48 |
mrpeters |
would that be caused by all of the translations not getting a chance to finish loading? |
10:50 |
tsbere |
No |
10:50 |
tsbere |
That is caused by "something is still aiming for a translation despite the page no longer being in memory" |
10:51 |
mrpeters |
ah |
10:52 |
mrpeters |
so its a completely legitimate error, do we need to supress that? |
10:52 |
tsbere |
I am still unsure where it is happening. I note that F1 has a similar issue, BTW. |
10:53 |
mrpeters |
what shortcut is F1 again? |
10:53 |
csharp |
checkout |
10:53 |
tsbere |
Checkout/load patron |
10:53 |
mrpeters |
ah, interesting. that is just a barcode search isnt it? |
10:54 |
|
RoganH joined #evergreen |
11:05 |
* tsbere |
is now curious as to where this stupid popup is coming from |
11:06 |
mrpeters |
Stompro: just saw your reponse on https://bugs.launchpad.net/evergreen/+bug/1124498 -- Reason I used the Errors-To: header was probably because I copied an existing template that was doing something similar :) |
11:06 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 4, heat: 30) [Wishlist,In progress] - Assigned to Josh Stompro (u-launchpad-stompro-org) |
11:23 |
tsbere |
mrpeters: So, I can stop all but the commonStrings ones (usually), but I at least know what causes them! |
11:25 |
tsbere |
mrpeters: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/stop_before_remove stops most of the popups. The last of them appears to be caused by the onunload handlers in the pages or subpages due to them trying to run before the page actually finished loading. |
11:46 |
mrpeters |
oh man, nice |
11:47 |
mrpeters |
ill test and sign-off then, thanks |
11:52 |
mrpeters |
was also looking at 506689 -- but should probably see if the behavior exists in the web client too -- would anyone be willing to insert a non-stock config.ident_type value to one of the web client test servers (Bill - Utility Company), perhaps to test the sort order outside of License, SSN, and Other? |
11:52 |
mrpeters |
bug 506689 that is |
11:52 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 1, heat: 8) [Wishlist,Confirmed] https://launchpad.net/bugs/506689 |
12:00 |
|
sandbergja joined #evergreen |
12:13 |
* tsbere |
is amazed at finding patrons with a "last circ month" in 1992 in the system |
12:13 |
mrpeters |
haha |
12:14 |
mrpeters |
pretty awesome you guys kept data that far back |
12:14 |
|
ldwhalen joined #evergreen |
12:15 |
tsbere |
mrpeters: We didn't except for where people owed money >_> Also, I am told by a reliable source that any circulation that old was from at least 2 systems ago. |
12:16 |
mrpeters |
makes sense then, i would want the money too, but they probably aren't coming back haha |
12:24 |
|
ldwhalen joined #evergreen |
12:45 |
|
dreuther_ joined #evergreen |
12:47 |
|
yboston joined #evergreen |
12:50 |
|
dreuther joined #evergreen |
12:55 |
|
akilsdonk_ joined #evergreen |
12:58 |
kmlussier |
dbwells++ #Call number browse is working much better for me know. |
12:59 |
kmlussier |
dbwells: I'll take a closer look at it this afternoon and hopefully get a sign-off in before I leave for the day. |
12:59 |
dbwells |
kmlussier++ |
13:00 |
dbwells |
Seems like I've been on a bad run lately, so nice to get something working :) |
13:33 |
kmlussier |
dbwells: A bad run? I just figured that was the nature of coding. |
13:35 |
RoganH |
The fickle finger of fate foretells fortune foul and fair for all. |
13:41 |
jboyer-isl |
mmorgan, are you about? I've got a couple questions about your test results re: bug 1210541 |
13:41 |
pinesol_green |
Launchpad bug 1210541 in Evergreen "Copy locations table should have a 'deleted' flag" (affected: 9, heat: 52) [Wishlist,Confirmed] https://launchpad.net/bugs/1210541 |
13:43 |
jboyer-isl |
Alas. I'll look into them when I have time to put a good test together. :) |
13:43 |
kmlussier |
jboyer-isl: She's around, but away from her desk at the moment. |
13:45 |
jboyer-isl |
ok. |
13:46 |
mmorgan |
jboyer-isl: be back in a few minutes ... |
13:55 |
gsams |
I've got an oddity, we have predue notifications setup in our system. For most libraries it is set to run the day before an item is due. |
13:55 |
gsams |
FOr one library, they checkout computers on an hourly basis, and these patrons keep getting predue notifications |
13:56 |
gsams |
And I'm failing to understand why it would run those |
13:56 |
gsams |
I'm wondering if I'm missing something on that. |
13:57 |
csharp |
gsams: you might have to play with max validity delay |
13:58 |
|
vlewis joined #evergreen |
13:58 |
mmorgan |
jboyer-isl: What are your questions? |
13:58 |
gsams |
csharp: I see that appears to be unset! |
13:58 |
gsams |
csharp++ I was completely unaware of this |
14:00 |
jboyer-isl |
In your comment for points 5 and 6, you mentioned the copy group and location order settings interfaces. Were deleted locations still appearing in groups/etc. after they had been deleted, or were you able to add them to a group or sort order again after they were deleted? |
14:01 |
jboyer-isl |
I ask because I added a rule to delete any entry in either of those tables on deleting the location. (Though I may have missed something that would allow you to add them back) |
14:01 |
gsams |
csharp: what sort of interval would avoid sending these out for hourly checkouts? Would I just set the delay to longer than the general checkout period? |
14:01 |
jboyer-isl |
csharp, isn't there a value like that with min in the name, or is that option's name confusing? |
14:02 |
gsams |
jboyer-isl: In the system I'm seeing max_delay (evergreen staff client call it Max Event Validity Delay. |
14:03 |
gsams |
I'm not seeing a minimum, but if it acts as a minimum wait time that would be an appropriate change in my mind. |
14:03 |
mmorgan |
jboyer-isl: The deleted locations still appeared in the interfaces where groups and order could be configured. |
14:04 |
jboyer-isl |
mmorgan, Ah, ok. Bummer. Back to my testing then. |
14:04 |
jboyer-isl |
Thanks! |
14:04 |
jboyer-isl |
mmorgan++ |
14:04 |
tsbere |
gsams: I would pick something like 12 hours or so. Or 1 hour more than however long from midnight your a/t runners pick up on the events to go out. |
14:04 |
mmorgan |
No, thank YOU! |
14:04 |
tsbere |
er, 1 hour less |
14:04 |
mmorgan |
jboyer-isl++ |
14:05 |
gsams |
tsbere: This might run into another problem that I've gone a different direction to fix... |
14:05 |
tsbere |
gsams, Bah, I can't recall the best way. Ours are easier as the "before due" is several days before, not the day before, so we just say "valid for a whole day" |
14:06 |
gsams |
tsbere: I understand that, at least one of our libraries goes 3 days before, and they never seem to run into problems with those notices |
14:07 |
tsbere |
gsams: Oh, and we don't do "per library" variants either. Global only. >_> |
14:07 |
gsams |
tsbere: heh, lucky. |
14:07 |
gsams |
tsbere: we don't have a way to make that happen yet. I'm hopeful that eventually we can all go unified experience. |
14:09 |
csharp |
gsams: sorry - head down on multiple things - I see tsbere is helping too - I can tell you that if you have processing delay and max validity delay set, they will become a BETWEEN delay AND max_delay (respectively) in the SQL query that gets run |
14:10 |
csharp |
not sure about negative values there, though (if those become necessary) |
14:11 |
csharp |
actually, I think the perl sees which value is lower and puts it in the right place |
14:11 |
tsbere |
for negative the overall idea still holds. |
14:11 |
csharp |
it's been about a month and a half since I looked at the code |
14:11 |
tsbere |
Our 3 day pre-due notices have a delay of -3 days and a max_delay of -2 days |
14:12 |
gsams |
csharp: So ideally, if one is set to -1 days and the other is set to -12 hours it would only pull notices for items due the following day? |
14:13 |
csharp |
gsams: I kind of go crosseyed with this when we talk about it in the abstract, but, yeah, that sounds sane to me |
14:13 |
tsbere |
gsams: If you have hourly circs I would say -1 day "delay" and -2 hours "max_delay" - As the 1 hour circ will never be 2 hours away from being due it won't trigger |
14:13 |
tsbere |
Increase the -2 hours as appropriate for your hourly circ durations |
14:13 |
gsams |
tsbere: excellent, thank you for walking me through it |
14:13 |
csharp |
tsbere++ # had a feeling you'd come through ;-) |
14:13 |
gsams |
csharp++ |
14:13 |
gsams |
tsbere++ |
14:14 |
gsams |
tsbere: although this does walk into another issue I've "fixed" in the past |
14:14 |
jboyer-isl |
OH. Now I understand what you're talking about. From the earlier discussion I thought max_delay was being suggested where delay would be used instead. oops. |
14:14 |
gsams |
currently I have the 1 day predue notices set with a -2 delay |
14:15 |
tsbere |
gsams: Which, depending on when your a/t runs, may be good |
14:15 |
gsams |
tsbere: 12:15 AM it looks like |
14:15 |
gsams |
normally, there is a backup running to catch anything that gets missed currently every 10 minutes |
14:16 |
gsams |
which would be what is really catching those other notices |
14:16 |
gsams |
so that should still be fine as is, just add in the extra padding for the hourly items and I'm good. |
14:16 |
gsams |
tsbere: thanks so much for the help! |
14:34 |
|
_bott_ joined #evergreen |
14:37 |
mrpeters |
what vimrc settings do most of you use for .tt2 files? |
14:37 |
* bshum |
is still a "nano" guy :) |
14:38 |
mrpeters |
nothin wrong with that! |
14:38 |
mrpeters |
took me a long time to force myself to stop using pico |
14:39 |
|
hbrennan joined #evergreen |
14:39 |
bshum |
dbwells: I have some reports of quirks with the serials batch receive interface. Apparently folks are clicking on the issuance to receive and then getting a small blue circle that spins, leading to the client crashing. |
14:39 |
tsbere |
mrpeters: Most of my vim settings have nothing other than auto-syntax for file type changes |
14:39 |
bshum |
They're for really big serial bibs, like People and Time |
14:40 |
bshum |
I'm wondering if maybe there's some timeout or other issue going on there |
14:40 |
bshum |
This is as of 2.7ish |
14:40 |
bshum |
I'm looking now to see if anything's changed in this area |
14:43 |
bshum |
So far the only thing I'm coming up with that's new is this 43d11f960def1b8ad9e3a8ac07cd18c6c7b5f58a |
14:43 |
pinesol_green |
[evergreen|Bill Erickson] LP#1081551 Serials batch recv. dupe barcode check - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=43d11f9> |
14:46 |
|
_bott_1 joined #evergreen |
14:48 |
|
_bott_1 joined #evergreen |
15:25 |
mrpeters |
in register_table.tt2 I'm seeing lots of references to fmclass and fmfield -- I'm taking a leap, and assuming those refer to the fm_IDL.xml, correct? |
15:34 |
kmlussier |
Doh. I suppose using an LC classification scheme would make it easier to test this LC Call number fix. |
15:38 |
|
vlewis_ joined #evergreen |
15:47 |
jeff |
mrpeters: *nod* |
15:47 |
jeff |
mrpeters: what brings you into the user editor? |
15:48 |
mrpeters |
oh, im still trying to hack at that old bug about the sort order of Ident Type not being alpha |
15:48 |
mrpeters |
I think I've got things traced back to open-ils.actor.user.ident_types.retrieve |
15:49 |
mrpeters |
i think that is what performs the database query on config.ident_type to get the values |
15:49 |
jeff |
ah |
15:49 |
mrpeters |
and i want to see if i can somehow do an ORDER BY name |
15:50 |
bshum |
That'd be handy for the patron groups too (within their respective subgroups) |
15:51 |
mrpeters |
i'd be happy to expand onit if i get this figured out |
15:51 |
mrpeters |
bug is 4 years old, yikes haha i thought it would be a good one to try and get my bug fixing chops back since i have more time in my days allowed for that now |
15:51 |
bshum |
Heh |
15:52 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/816615 (was reported when we were on 2.0... guess maybe I've let that one go long enough) |
15:52 |
pinesol_green |
Launchpad bug 816615 in Evergreen "patron profile permission group sort order" (affected: 4, heat: 30) [Wishlist,Triaged] |
15:52 |
mrpeters |
oh was that your bug? i didnt even notice |
15:52 |
mrpeters |
id still like to fix it |
15:53 |
mrpeters |
and, kmlussier made a good point, some of this stuff may leak into web client too so it doesnt hurt to fix now, and make sure the same bug doesnt pop up in the new web client |
15:53 |
bshum |
Well the user editor is basically taken as is I think to the web client, more or less. |
15:53 |
bshum |
So yeah, definitely :) |
15:53 |
mrpeters |
https://bugs.launchpad.net/evergreen/+bug/506689 |
15:53 |
pinesol_green |
Launchpad bug 506689 in Evergreen "Patrons > Identification Type > (Sort order)" (affected: 1, heat: 8) [Wishlist,Confirmed] |
15:53 |
mrpeters |
thats the one im digging at |
15:54 |
bshum |
Ah, good times |
15:59 |
mrpeters |
looks like there are some examples where this happens -- order_by => { acp => { create_date => { transform => 'max', direction => 'desc' } } }, (SuperCat.pm) |
16:00 |
mrpeters |
so i think order_by = { cit = {name}, direction = 'desc} might be somewhat on the right track |
16:01 |
jboyer-isl |
mrpeters, I wouldn't do direction='desc' unless it's a date. That's Z-A order for names. |
16:01 |
|
dreuther_ joined #evergreen |
16:01 |
jboyer-isl |
But Newest - Oldest for dates. |
16:01 |
mrpeters |
ah, right |
16:02 |
jboyer-isl |
Other than that I don't have a lot to offer, I've barely touched json queries. |
16:02 |
mrpeters |
yeah, no worries...im at least getting used to where certain things link up again |
16:02 |
jboyer-isl |
Oops, those are some form of perl, shows how much I deal with that. |
16:03 |
mrpeters |
yeah its from the perl code |
16:08 |
mrpeters |
Actor.pm (here, specifically - http://pastie.org/9730896) seems like where I need to be but it doesn't look like some of the other perl where it's performing actual SQL that I can follow in perl form |
16:10 |
mrpeters |
so, my question i guess is "where you get yo info from API!" |
16:10 |
mrpeters |
i think, from retrieve_all_config_identification_type, which i beleive is loaded into memory when you login to the staff client |
16:12 |
mrpeters |
and now i'm looking at Storage/CDBI/ stuff which is scaring me :P i think i'm going to dig a hole to china! |
16:14 |
mrpeters |
http://pastie.org/9730906 feels like the end of the line... |
16:54 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
16:55 |
|
akilsdonk joined #evergreen |
16:56 |
|
mdriscoll left #evergreen |
16:59 |
|
nhilton joined #evergreen |
17:00 |
|
chatley joined #evergreen |
17:00 |
|
jwoodard joined #evergreen |
17:04 |
|
mmorgan left #evergreen |
17:26 |
|
dreuther joined #evergreen |
17:28 |
|
nhilton_ joined #evergreen |
17:39 |
|
nhilton joined #evergreen |
17:51 |
dbwells |
mrpeters: I don't think retrieve_all can take an order_by, so you'll probably want to use an editor search instead. Something like (untested): $e->search_config_identification_type({id => {'!=' => undef}}, {order_by => {cit => 'name'}}) |
17:52 |
dbwells |
where $e is a cstore editor |
17:53 |
dbwells |
I'm also not sure if the first argument (the 'where') can be blank, so the example I gave just puts in a simple condition which will be true for every row. |
17:55 |
|
ldwhalen joined #evergreen |
17:56 |
|
jihpringle joined #evergreen |
17:57 |
Bmagic |
anyone familiar with the TPAC tt2 widget that makes "Featured books" example: https://catalog.tadl.org |
17:59 |
dbwells |
Bmagic: well, that is jeff's catalog, so he probably knows something about it :) That said, it isn't part of stock TPAC. |
18:00 |
Bmagic |
jcarousel ... do I need to just write it myself or do we have something to start with? |
18:00 |
berick |
looks like http://sorgalla.com/jcarousel/ |
18:01 |
berick |
plus some php |
18:02 |
Bmagic |
berick: jeff is using php on his TPAC ? |
18:02 |
dbwells |
Bmagic: it's framed in |
18:02 |
Bmagic |
dbwells: i just noticed that, aha! |
18:03 |
Bmagic |
ok, that makes for a totally different discussion |
18:03 |
Bmagic |
thanks everyone |
18:12 |
pinesol_green |
[evergreen|Dan Wells] Revert "LP#1198465 lost overdues generated in main xact" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac6ba25> |
18:12 |
pinesol_green |
[evergreen|Dan Wells] Revert "LP#1198465 Allow fine generator to respect a stop_fines filter" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b915d4b> |
18:41 |
* jeff |
chuckles |
18:53 |
|
jihpringle joined #evergreen |
18:56 |
|
jihpringle joined #evergreen |
19:22 |
|
squash joined #evergreen |