| Time |
Nick |
Message |
| 00:05 |
|
RBecker joined #evergreen |
| 00:17 |
|
RBecker joined #evergreen |
| 01:32 |
|
tfaile_ joined #evergreen |
| 01:32 |
|
Callender_ joined #evergreen |
| 02:00 |
|
RBecker joined #evergreen |
| 02:00 |
|
RBecker joined #evergreen |
| 02:03 |
|
RBecker joined #evergreen |
| 02:22 |
|
Mark__T joined #evergreen |
| 02:49 |
|
vmagidson joined #evergreen |
| 02:52 |
vmagidson |
hello! I'm new here. Writing a phone app connecting to the library. I wonder what method I should use to retrieve patron's barcode once I authenticated using user name. I get most of the data (name, last name, etc.) using open-ils.auth.session.retrieve, but it does not include barcode... Any help will be highly appreicated! |
| 02:54 |
vmagidson |
If there is a better place to ask this kind of questions - please point me over. Or, even better, if there was a public API documentation - I couldn't find this kind of info on the site/wiki... |
| 02:59 |
|
Guest6061 joined #evergreen |
| 03:01 |
|
RBecker joined #evergreen |
| 03:34 |
paxed |
vmagidson: the devs are asleep, as they're in USA or Canada, and I don't know the answer to that. |
| 06:04 |
|
RBecker joined #evergreen |
| 06:35 |
|
kivilahtio joined #evergreen |
| 06:46 |
|
mcooper joined #evergreen |
| 07:41 |
|
collum joined #evergreen |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:43 |
|
bkuhn joined #evergreen |
| 07:56 |
|
mrpeters joined #evergreen |
| 08:19 |
|
akilsdonk_ joined #evergreen |
| 08:52 |
|
ericar joined #evergreen |
| 08:53 |
|
kmlussier joined #evergreen |
| 08:59 |
|
Meliss joined #evergreen |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:01 |
|
mmorgan joined #evergreen |
| 09:31 |
|
krvmga joined #evergreen |
| 09:37 |
|
moodaepo_nb joined #evergreen |
| 09:38 |
|
Ruth joined #evergreen |
| 09:46 |
rfrasur |
Congrats to the dev community on meeting the buggy goal. dbwells++ |
| 09:53 |
phasefx |
just needed a buggy whip |
| 09:54 |
rfrasur |
jboyer-isl:I'm reading through the EG cataloging committee minutes and they mention upgrade to 2.3. Am I correct in thinking this was incorrect and we're going straight to 2.4 in Dec? |
| 09:55 |
rfrasur |
phasefx:sometimes, whips can work |
| 09:56 |
jboyer-isl |
Yes, that was either before the upgrade was postponed or someone just missed/forgot the notice that went out. |
| 09:56 |
jeff_ |
2.3, 2.4, whatever it takes. |
| 09:56 |
rfrasur |
whew - minor moment of panic and plans for rebellion |
| 09:57 |
|
BigRig joined #evergreen |
| 09:57 |
rfrasur |
jeff_:it takes a buggy whip |
| 09:59 |
pinesol_green |
[evergreen|Bill Erickson] Repair fine generator memory leak - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db9a773> |
| 10:00 |
berick |
buggy buggy buggy : a broken cart in the middle of a swamp |
| 10:00 |
rfrasur |
berick++ |
| 10:00 |
* rfrasur |
had to read that multiple times |
| 10:02 |
phasefx |
berick: I hope that's not like trying to summon beetlejuice or hastur |
| 10:02 |
rfrasur |
hmm, I think we can handle beetlejuice |
| 10:02 |
berick |
phasefx: well, whatever emerges from the mist, I think we can take it in a fight ;) |
| 10:02 |
berick |
hah, rfrasur++ |
| 10:03 |
rfrasur |
! berick++ |
| 10:04 |
rfrasur |
I absolutely despise the way the ISL has their set up for webinars. Not saying....just saying. |
| 10:05 |
rfrasur |
(stupid adobe connect) |
| 10:12 |
jeff_ |
heh. you're the second person to mention/complain about adobe connect in the past few minutes that i've seen (here and elsewhere) |
| 10:12 |
rfrasur |
maybe we're "going" to the same budget webinar. On the upside, I get to participate from home rather than office. |
| 10:13 |
rfrasur |
on the downside - wireless internet vs. cable |
| 10:31 |
dbs |
rfrasur: btw, [off] is the new ! |
| 10:32 |
rfrasur |
dbs: hehe, my ! was just exclaiming. You've given me far too much credit |
| 10:33 |
dbs |
oh, I thought you were trying to prevent the world from knowing that you incremented berick :) |
| 10:33 |
eeevil |
dbs++ # 8d772605b3 |
| 10:33 |
berick |
i'm controversial |
| 10:34 |
rfrasur |
yeah you are |
| 10:34 |
* berick |
tries to remember the comedian whose line that was |
| 10:34 |
* rfrasur |
has heard that |
| 10:34 |
bshum |
dbs: So I was just reading an article about future google SEO plans to lower rankings for sites that have mobile issues. |
| 10:34 |
* rfrasur |
listens to bshum |
| 10:35 |
bshum |
dbs: I'm adding it as another reason getting more responsive catalog is the way to go. |
| 10:35 |
dbs |
bshum: yessir, I saw that too |
| 10:35 |
bshum |
rfrasur: Basically the gist I got is that if a site redirects you to a m.host (aka, mobile redirect), it'll get downranked in future google searches. |
| 10:35 |
bshum |
Among other things. |
| 10:35 |
dbs |
eeevil: heh, I'm hoping it doesn't slow ingest down too much, but given the specificity of the lookups, it shouldn't be too bad |
| 10:36 |
rfrasur |
rather than just working as is? (ie responsive) |
| 10:36 |
bshum |
So that definitely kills some of the exploration projects we've made into separate skin and apache redirects to a mobile site. |
| 10:36 |
bshum |
Not that we weren't already killing them anyways :D |
| 10:36 |
rfrasur |
yeah...but...it's still nice to have options |
| 10:37 |
rfrasur |
did they offer reasoning? |
| 10:37 |
dbs |
rfrasur: also, if the site redirects you from normal.example.com/record/123456 to m.example.com/index.html (forcing you to search all over again) or to a site that lacks most of the content offered up in the original, you get penalized |
| 10:37 |
|
zerick joined #evergreen |
| 10:37 |
eeevil |
dbs: question ... would you support using, say, an array of insterted row objects to check for dups instead of going to the table on each row addition? (arguably not worth the effort, but "ROW[field,source,value) IS DISTICNT FROM ANY (some_array)" should be faster than going to the table proper) |
| 10:37 |
dbs |
rfrasur: because that sort of mobile web experience sucks for users :) |
| 10:38 |
rfrasur |
dbs: well, that's true. |
| 10:38 |
rfrasur |
okay...I'd much rather talk w/ y'all, but my attention has to be on less pleasant stuff |
| 10:38 |
dbs |
eeevil: sure, I was just going with the simplest approach I could come up with at midnight+ to make things work :) |
| 10:39 |
* rfrasur |
shakes fist at webinar |
| 10:40 |
|
zerick joined #evergreen |
| 10:40 |
dbs |
we're upgrading to 2.4 this weekend, so avoiding another reingest is strong motivation for simple/works |
| 10:41 |
eeevil |
dbs: I'm completely for simple+works for now |
| 10:42 |
eeevil |
and I don't have the tuits to implement the array-cache version right this sec ... but wanted to raise it for discussion |
| 11:03 |
dbs |
after this upgrade, I hope to get back to responsive tpac hacking again |
| 11:09 |
kmlussier |
Dyrcona (or anybody else who has done this) : I have a question about the script you run to link bibs to authority records. |
| 11:10 |
|
mcooper joined #evergreen |
| 11:11 |
kmlussier |
tspindler mentioned that it takes a couple of weeks to run the script for the first time on his system. Once the initial linking is done, does it take as long to run the script. I assume it needs to be run on a regular basis to handle new records in the system. |
| 11:14 |
mcooper |
kmlussier: based on my understanding ongoing linkage is done using the days_back flag (typically), which will re-apply links to newly created or edited records. |
| 11:15 |
Dyrcona |
kmlussier: http://blog.mvlcstaff.org/2012/09/howto-batch-authority-control.html |
| 11:15 |
kmlussier |
Ah, ok. So then it shouldn't be such an arduous process on subsequent runs. Good to know. |
| 11:16 |
Dyrcona |
And, what mcooper said about days_back.... |
| 11:16 |
kmlussier |
Dyrcona++ mcooper++ |
| 11:17 |
Dyrcona |
Summary of the link I shared, if you batch the authority linking and run some of them in parallel, it goes much more quickly the first time. |
| 11:30 |
|
ktomita_ joined #evergreen |
| 11:44 |
|
dboyle joined #evergreen |
| 11:53 |
Dyrcona |
lunch++ |
| 11:53 |
bshum |
lunch++ |
| 11:53 |
bshum |
@love lunch |
| 11:53 |
pinesol_green |
bshum: The operation succeeded. bshum loves lunch. |
| 11:54 |
|
acoomes joined #evergreen |
| 11:55 |
|
jdouma joined #evergreen |
| 12:02 |
|
zerick joined #evergreen |
| 12:04 |
|
eby_ joined #evergreen |
| 12:10 |
|
ldwhalen joined #evergreen |
| 12:27 |
|
ktomita joined #evergreen |
| 12:39 |
|
dboyle_ joined #evergreen |
| 12:41 |
|
kbeswick joined #evergreen |
| 13:23 |
Dyrcona |
@hate Perl |
| 13:23 |
pinesol_green |
Dyrcona: But Dyrcona already hates Perl! |
| 13:23 |
Dyrcona |
Good! |
| 13:24 |
|
yboston joined #evergreen |
| 13:25 |
kmlussier |
Dyrcona: You're consistent! :) |
| 13:28 |
|
dMiller_ joined #evergreen |
| 13:34 |
Dyrcona |
eeevil: Are you around? |
| 13:35 |
eeevil |
Dyrcona: aye |
| 13:35 |
Dyrcona |
I've got a question about code that has your name on it from 7 years ago. :) |
| 13:35 |
eeevil |
BWAHAHAA |
| 13:35 |
eeevil |
shoot |
| 13:36 |
eeevil |
"svn revision 1 ... huh" |
| 13:36 |
Dyrcona |
Line 312 of Open-ILS/src/perlmods/OpenILS/Application/Storage/Publisher/actor.pm looks wrong to me. |
| 13:36 |
* eeevil |
looks |
| 13:37 |
eeevil |
Dyrcona: hrm... there's no lib/ dir in that path ... typo here, or REALLY old branch? |
| 13:37 |
Dyrcona |
If you look up above, there is already a check for $direction <= 0, so I think the check on 312 should be $direction > 0. and not >= |
| 13:37 |
Dyrcona |
I copied from git blame, so that was before lib was added. |
| 13:38 |
Dyrcona |
It should be Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/actor.pm |
| 13:38 |
eeevil |
so, that's not actually used |
| 13:38 |
eeevil |
note: api_level => 0 |
| 13:39 |
eeevil |
it has to be explicitly requested at that api level |
| 13:39 |
phasefx |
should we prune it? |
| 13:39 |
eeevil |
there's an api_level 1 version that is what gets called |
| 13:40 |
Dyrcona |
oops. sorry. |
| 13:41 |
Dyrcona |
Well, the reason that I am looking is that we had a library set their closed dates for Tuesday and Thursday of next week. |
| 13:41 |
eeevil |
phasefx: using sets would be a better implementation, but it never got promoted to default published status ... it's now caused confusion once (that /I'm/ aware of) but (Dyrcona) if you want to fix it up (and that may be the only problem with the code) I'd be in favor of replacing the currently exposed method with that |
| 13:41 |
Dyrcona |
When they checked out 7 day items yesterday, they came up due on Monday the 24th instead of the 19th. |
| 13:41 |
eeevil |
Dyrcona: ahh... yeah, "of next week" doesn't meen anything for HOO |
| 13:42 |
* eeevil |
retracts that last statement |
| 13:42 |
Dyrcona |
Well, the closed dates were 18th, 20th-23rd. |
| 13:42 |
Dyrcona |
Removing the closed dates, the checkouts work just fine, so I'm looking at closed date logic. |
| 13:42 |
* eeevil |
opens the calendar |
| 13:43 |
Dyrcona |
Guess I looked in the wrong place to start. |
| 13:43 |
eeevil |
hrm... |
| 13:45 |
Dyrcona |
Compounding the situation, the hours of operation only have this branch open, Monday, Wednesday, and Saturday, but they don't open Saturday in the summer. |
| 13:46 |
eeevil |
Dyrcona: I don't suppose you have logs enough to see the call to open-ils.storage.actor.org_unit.closed_date.overlap for the circ in question... |
| 13:46 |
eeevil |
the parameters, I mean |
| 13:48 |
Dyrcona |
I might, but it would likely take some digging. I don't recall if I reproduced it on my development server, but it would be in production. |
| 13:49 |
eeevil |
if the second param (the prospective due date) overlaps with an org unit closed date then we have something to attack ... dunno ... if perhaps just the date (or midnight of weds) was sent, and the closed date ended at midnight weds instead of 23:59 on tues, then we need to |
| 13:49 |
eeevil |
OH! |
| 13:49 |
eeevil |
Dyrcona: did they use an "adjusted due date"? |
| 13:50 |
Dyrcona |
No, they didn't. That was my first thought. |
| 13:50 |
eeevil |
the dropdown of "now + one week", or type in a due date? |
| 13:50 |
eeevil |
drat |
| 13:51 |
eeevil |
that's the only way I can imagine a bare date with no time (or midnight time component) being used for due date |
| 13:51 |
eeevil |
(obv not the only way, though, eh?) |
| 13:53 |
Dyrcona |
Well, I don't know if they didn't have a time, yet. |
| 13:53 |
Dyrcona |
I do see some of the dates have a timezone, and others have +0000, but the times in the latter case have four hours added to them. |
| 13:54 |
Dyrcona |
Trouble is finding the DVD circs at a particular branch on a particular day. |
| 13:54 |
|
acoomes joined #evergreen |
| 13:54 |
Dyrcona |
I'll keep digging. If I find anything, I'll shout. |
| 13:54 |
eeevil |
you have the item barcode? |
| 13:55 |
eeevil |
or circ id? (even better) |
| 13:55 |
Dyrcona |
I can get one of the barcodes, 'cause I remember the patron's name. |
| 13:55 |
|
tfaile joined #evergreen |
| 13:56 |
Dyrcona |
hey! look at that! 5 copy barcodes! |
| 13:56 |
Dyrcona |
I'll look for these in the logs. |
| 14:03 |
Dyrcona |
Hmm. Either I don't know how to look in the logs or the due date adjustment happens in a different "thread" (for lack of a better word at the moment). |
| 14:09 |
* csharp |
is digging in PINES logs right now for which staff member marked something claims returned |
| 14:10 |
csharp |
date range of late April to now |
| 14:10 |
mrpeters |
shouldnt the audit tables have that? |
| 14:10 |
csharp |
not for circs |
| 14:10 |
mrpeters |
you could look at all the asset.copy.status changes |
| 14:10 |
csharp |
ah |
| 14:11 |
csharp |
maybe that's the approach I should be taking |
| 14:11 |
mrpeters |
yeah, im thinking it might be easier |
| 14:11 |
csharp |
thanks |
| 14:11 |
bshum |
mrpeters++ |
| 14:17 |
|
jihpringle joined #evergreen |
| 14:50 |
|
dboyle joined #evergreen |
| 14:58 |
|
stevenyvr2 joined #evergreen |
| 15:03 |
Dyrcona |
eeevil: So, I found four of the five circulations in question, they all happened with the minute of 11:20 yesterday. The fifth happened after 11:21. |
| 15:04 |
pastebot |
"Dyrcona" at 204.193.129.146 pasted "closed_date overlap calls." (4 lines) at http://paste.evergreen-ils.org/38 |
| 15:04 |
Dyrcona |
The paste shows that all four transactions have the proper time on the due date. |
| 15:07 |
|
Ruth joined #evergreen |
| 15:08 |
rfrasur |
Just another grea selling point for EG and any ILS w/ offsite server - easier/cheaper disaster recovery. |
| 15:11 |
rfrasur |
grea=great |
| 15:16 |
eeevil |
Dyrcona: have you tried those calls in srfsh? |
| 15:16 |
jcamins |
rfrasur: unless your offsite server is in a navy yard during a hurricane. |
| 15:16 |
jcamins |
(note: I don't run production sites on that server, and actually it remained up throughout Hurricane Sandy) |
| 15:17 |
Dyrcona |
eeevil: Not yet. I've actually obliterated the unnecessary closed dates that they entered, so now, they likely give the expected result. |
| 15:17 |
rfrasur |
well, cheaper for my little library. maybe not cheaper in the broader scope of things |
| 15:17 |
eeevil |
Dyrcona: ahh... so it's likely that there were incorrect closed dates there at the time? which would do what they saw, of course |
| 15:17 |
bshum |
I like to look at the upside of having a transparent understanding of how the system works around. Better than not knowing. Or is knowing too much a bad thing? :D |
| 15:19 |
Dyrcona |
eeevil: Could be... |
| 15:19 |
Dyrcona |
I'm going to try something.... |
| 15:23 |
phasefx |
dbwells: should I target -m2 with anything new that has a pullrequest? |
| 15:23 |
phasefx |
anything new that I do, that is |
| 15:26 |
dbwells |
phasefx: yes |
| 15:27 |
phasefx |
roger that, thanks |
| 15:27 |
pastebot |
"Dyrcona" at 204.193.129.146 pasted "closed_date overlap with restored data." (12 lines) at http://paste.evergreen-ils.org/39 |
| 15:28 |
paxed |
dbwells: good to know - i targeted one i did today to -m2, but wasn't sure i should do that, so didn't target the other one. until just now. |
| 15:30 |
pastebot |
"Dyrcona" at 204.193.129.146 pasted "Umm. What are they doing?" (3 lines) at http://paste.evergreen-ils.org/40 |
| 15:30 |
Dyrcona |
eeevil: I found the culprit in the database. Now to see if it shows up in the client. |
| 15:44 |
|
esimmers joined #evergreen |
| 15:45 |
|
esimmers left #evergreen |
| 15:47 |
Dyrcona |
data-- # 'cause from where I sit, it is all bad..... ;) |
| 16:00 |
|
remingtron joined #evergreen |
| 16:01 |
eeevil |
data-- # indeed |
| 16:06 |
gmcharlt |
data++ # keeps me busy; *especially* if it's messy ;) |
| 16:07 |
* eeevil |
watches gmcharlt wallow like a pig in ... well, you know |
| 16:08 |
bradl |
eeevil: excuse me, the proper term is waller ;) |
| 16:08 |
eeevil |
bradl: pardon, sir |
| 16:09 |
|
dboyle joined #evergreen |
| 16:18 |
kmlussier |
berick: Are bug 833820 and bug 1177916 the same thing? |
| 16:18 |
pinesol_green |
Launchpad bug 833820 in Evergreen "Support PO activation without requiring bibs/items" (affected: 1, heat: 8) [Wishlist,Triaged] https://launchpad.net/bugs/833820 |
| 16:18 |
pinesol_green |
Launchpad bug 1177916 in Evergreen "Cannot activate PO which contains only direct charges (no bibs)" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1177916 |
| 16:24 |
jihpringle |
kmlussier: I don't think they're the same |
| 16:25 |
jihpringle |
1177916 is that you should be able activate a PO with no line item just charges, while 833820 is that you should be able to activate a PO with line items but not automatically load the records into catalogue |
| 16:26 |
kmlussier |
Oh, I see now. |
| 16:26 |
jihpringle |
I think 833820 would be useful for preview orders where the library may or may not keep the items (some of our post-secs do that) |
| 16:26 |
kmlussier |
jihpringle++ |
| 17:11 |
|
mmorgan left #evergreen |
| 17:58 |
|
mrpeters left #evergreen |
| 19:11 |
|
sseng joined #evergreen |
