| 00:27 |
|
zerick joined #evergreen |
| 01:05 |
|
timlaptop joined #evergreen |
| 05:14 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:39 |
|
jboyer-isl joined #evergreen |
| 05:39 |
|
wjr joined #evergreen |
| 05:39 |
|
wjr joined #evergreen |
| 09:52 |
asimon |
What is the best way to delete all patrons from the database and load them again (with the same barcode numbers)? |
| 09:53 |
bshum |
asimon: Out of curiousity, what are you attempting to gain by doing so? |
| 09:53 |
Dyrcona |
asimon: Blow the database out and start over. |
| 09:54 |
asimon |
bshum: I'm trying to replace a test set of patrons with the latest information. |
| 09:54 |
asimon |
Dyrcona: I can't do that because of all the other information in the database. |
| 09:55 |
Dyrcona |
asimon: Then, you're mostly stuck because of referential integrity triggers. |
| 09:55 |
Dyrcona |
asimon: Assuming the patrons are tests, shouldn't the rest of the data be test data, too? [Though I guess not.] |
| 09:56 |
|
atlas__ joined #evergreen |
| 09:57 |
bshum |
In our system, we load student data during new schoolyears and overlay the original entry in Evergreen with new data based on a matching identifier (like student ID or barcode) |
| 09:59 |
asimon |
Dyrcona: No. I have deleted the sample bib and copy records and I am loading a new set beginning with a different id range, and I want to do the same thing with the patron records, but I'm getting: ERROR: duplicate key value violates unique constraint "usr_usrname_key" |
| 10:55 |
|
phasefx joined #evergreen |
| 10:56 |
|
jwoodard joined #evergreen |
| 10:57 |
|
Sato`kun joined #evergreen |
| 11:00 |
yboston |
Dyrcona++ # wading through RDA |
| 11:01 |
|
ericar joined #evergreen |
| 11:03 |
yboston |
Dyrcona: let me know how I can help. I don't have a 2.6.x VM set up right now but I can set one up to test RDA or authority code out, etc. |
| 11:06 |
|
pmurray_away joined #evergreen |
| 11:10 |
Dyrcona |
yboston: That branch should apply to 2.5 at least. |
| 11:10 |
yboston |
Dyrcona: that is what I was hoping as I looked at the code |
| 11:11 |
yboston |
Dyrcona: would you like me to try it out on my test 2.5.x server? |
| 11:11 |
|
Wyuli joined #evergreen |
| 11:11 |
Dyrcona |
yboston: If you want to, just cherry-pick the top commit. |
| 11:12 |
yboston |
Dyrcona: I will have to do it manually since the tests ervers I have are not git based, but it should not be too hard |
| 11:20 |
|
kmlussier joined #evergreen |
| 11:27 |
|
Guest25194 joined #evergreen |
| 11:34 |
Dyrcona |
Is the dev. meeting today? |
| 11:57 |
eeevil |
asimon: it does not. jeff: right |
| 11:57 |
* eeevil |
looks for that code... |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:22 |
bshum |
kmlussier: I think they're required because PINES required them :) So we inherit that from them. |
| 12:25 |
bshum |
jihpringle: Huh... have you guys updated your test server to 2.6-rc yet? |
| 12:25 |
|
ningalls joined #evergreen |
| 12:26 |
bshum |
jihpringle: I've got some reports on our test system that the acq/cataloging loader (vandelay) isn't matching anymore and basically just running forever with no results. |
| 12:26 |
jihpringle |
bshum: not yet, but we're hoping to have a test server running 2.6rc soon |
| 12:27 |
bshum |
jihpringle: All good, I'm digging through things on my end to try figuring out what's happening with our system and if maybe we're just on the tail end of some bad setup |
| 12:27 |
bshum |
jihpringle: I'm crossing my fingers that it's something small and we didn't break acq and cataloging before 2.6.0 :\ |
| 12:27 |
jihpringle |
fingers crossed |
| 12:28 |
jihpringle |
I'll find out when we're getting our new test server and take a look at this as soon as we do |
| 12:41 |
Dyrcona |
bshum: I've emailed our catalogers to ask them to test Vandelay on our training server. It is up to date as of Friday. |
| 12:41 |
bshum |
Dyrcona: Cool, that's appreciated. |
| 12:41 |
eeevil |
asimon: http://pastebin.com/nDj80KVW ... that's from a pre-staging schema, custom thing, but I think it's close. it'll update or insert staged patrons, matching on the barcode |
| 12:42 |
kmlussier |
bshum / jihpringle / Dyrcona: I just loaded order records on Dyrcona's dev system without any problems. |
| 12:59 |
dbs |
Even the bestest RDFa in the world isn't going to smooth that over. |
| 13:01 |
kmlussier |
Dyrcona: How recent is master on your training server? I know this was working a couple of weeks ago, but if you've updated it since then, it might affect your acq pilots. |
| 13:04 |
Dyrcona |
kmlussier: I updated it Friday. |
| 13:05 |
Dyrcona |
kmlussier: I reloaded the database, too, forgetting that it would blow out their test acquisitions data. |
| 13:05 |
Dyrcona |
On the plus side, they get more acquisitions practice. :) |
| 13:06 |
Dyrcona |
+1 to release blocker status |
| 13:06 |
kmlussier |
Dyrcona: Heh. I'll send them a quick e-mail asking them to hold off on trying order record uploads for a while. |
| 13:24 |
pinesol_green |
Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 1, heat: 6) [Critical,Confirmed] |
| 13:24 |
bshum |
I'll start looking for what's broken next, but I've filed the bug to start |
| 13:24 |
bshum |
Well, maybe right after lunch |
| 13:34 |
* jeff |
exploits a test wheezy system |
| 13:34 |
jeff |
yup. |
| 13:34 |
jeff |
that easy. |
| 13:46 |
bshum |
14 minutes till the dev meeting |
| 13:46 |
bshum |
There's a few action items on the list from past meeting |
| 13:46 |
bshum |
See agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-04-08 |
| 14:24 |
kmlussier |
dbwells: Yes, looks like I fogot to do that. I can target it now. |
| 14:24 |
dbwells |
kmlussier: thank you! |
| 14:25 |
eeevil |
I'll raise my hand for 1304559 ... I think dbwells is on the right track in the bug comment |
| 14:25 |
bshum |
fwiw, we added the icons kmlussier mentions in the branch to our test system and it seemed fine. So I'd be happy to push things along. |
| 14:25 |
gmcharlt |
jeff: I think 1303940; since it looks like Dyrcona has reviewed it and given a (virtual) signoff, I'll do a final test and push it today |
| 14:25 |
gmcharlt |
s/1303940/1303940 is/ |
| 14:26 |
dbwells |
jeff: I guess we'll see :) |
| 14:26 |
Dyrcona |
I'd like to see some thought given to dbwells' suggestion on 1303940. |
| 14:26 |
gmcharlt |
(and look at dbwells comment) |
| 14:29 |
jeff |
#info Please review the acknowledgements for Evergreen 2.6 and make any additions/updates |
| 14:29 |
jeff |
#link https://bugs.launchpad.net/evergreen/+bug/1302113 bug 1302113 - acknowledgments in release notes |
| 14:29 |
pinesol_green |
Launchpad bug 1302113 in Evergreen 2.6 "acknowledgments in release notes" (affected: 1, heat: 6) [Undecided,New] |
| 14:29 |
dbwells |
eeevil: I did a very quick test of subbing in record_attr_flat for record_attr in vandelay._get_expr_push_jrow(). So far, nothing exploded, but I haven't tested it very hard yet. |
| 14:29 |
jeff |
#info Evergreen 2.5 bug fixes? |
| 14:30 |
jeff |
dbwells: you're still wearing the release maintainer hat for 2.5, correct? |
| 14:30 |
eeevil |
dbwells: that will work fine, I'm only concerned about performance ... my plan is to look directly at the vector |
| 14:33 |
jeff |
#info Evergreen 2.4 - final release? |
| 14:33 |
eeevil |
I'll align that with dbwells' next week |
| 14:33 |
eeevil |
after pushing in as many fixes as we can safely |
| 14:34 |
jeff |
#info Final planned Evergreen 2.4 maintenance release scheduled for April 16 |
| 14:35 |
jeff |
eeevil, dbwells: any specific things that either of you would like to call attention to in terms of things that you'd like more testing/eyeballs on for any of the above releases? |
| 14:35 |
dbwells |
jeff: nothing I can think of, thanks |
| 14:36 |
eeevil |
nothing specific |
| 14:37 |
jeff |
moving on! |
| 15:08 |
dbwells |
bshum: I was thinking of branching at RC, but at this point, we might as well wait for .0, I think. |
| 15:08 |
dbwells |
so, yest |
| 15:08 |
dbwells |
I mean yes |
| 15:09 |
bshum |
Cool deal. I'll try adding new things later this evening if I can carve out some time to test more and signoff |
| 15:09 |
dbwells |
bshum: kmlussier: here's a very quick attempt at ferreting out the Vandelay issue - http://pastebin.com/CtujPy6z |
| 15:09 |
bshum |
I can drop that into our test system and see what happens. |
| 15:10 |
dbwells |
I know eeevil is cooking up something better, but this should be really easy to test, and might tell us if we're on the right track. |
| 15:10 |
bshum |
Will do |
| 15:10 |
kmlussier |
dbwells++ |
| 15:10 |
kmlussier |
I'll leave it in bshum's capable hands while I head home. :) |
| 15:45 |
Melanion |
The CRs in question were added in 8/13, at which time our system was running..2.3? Maybe 2.2. So it could have happened before the fix. |
| 15:47 |
dbwells |
bshum: you can ignore my earlier function paste, I accidentally threw an extra '=' in there anyway. |
| 15:48 |
mmorgan |
Someone correct me if I'm wrong, but I believe nullifying action.circulation.xact_finish for those transactions would make them reappear on the patron records. |
| 15:48 |
dbwells |
bshum: We're better off testing this, since it's ready now: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/1304559_and_1271661_vandelay_fixes |
| 15:49 |
Dyrcona |
mmorgan: I believe it would. |
| 15:52 |
bshum |
dbwells: That I can do. We didn't get to work on the first one, mary ended up heading out early for something else |
| 15:53 |
|
CleverNameHere joined #evergreen |
| 16:53 |
|
kmlussier joined #evergreen |
| 16:54 |
CleverNameHere |
So when running a report through evergreen it sends me a link to https://localhost/blah/blahblah/blahblahblah. Anyone know how |
| 16:54 |
CleverNameHere |
iI can configure that to our evergreen servers name |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:58 |
jeff |
CleverNameHere: in your opensrf.xml configuration file, look at the value under reporter/setup/base_uri |
| 16:58 |
kmlussier |
I don't know the answer, but I wish I had come up with a screen name that's as clever as CleverNameHere's. :) |
| 17:03 |
|
Wyuli joined #evergreen |
| 17:18 |
* gmcharlt |
grabs 0854 |
| 17:19 |
gmcharlt |
bah |
| 17:19 |
gmcharlt |
correction, 0878 |
| 17:33 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1303940: pg_tap regression test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=16eec85> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: improve readability of test case - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1764ceb> |
| 17:33 |
pinesol_green |
[evergreen|Mike Rylander] LP#1303940: Protect against bogus data that can breaking indexing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c964cd4> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: don't attempt to store NULL values in keyword, browse, or facet indexes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9984b11> |
| 17:33 |
pinesol_green |
[evergreen|Galen Charlton] LP#1303940: pin schema upgrade to 0878 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=149ffb3> |
| 17:33 |
jeff |
@who can breaking indexing? |
| 17:33 |
pinesol_green |
pmurray_away can breaking indexing. |
| 17:34 |
CleverNameHere |
Thanks Jeff. I found it. |
| 01:29 |
|
pinesol_green` joined #evergreen |
| 01:31 |
|
berick joined #evergreen |
| 01:33 |
|
DPearl joined #evergreen |
| 04:57 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:33 |
|
robbat2 joined #evergreen |
| 07:33 |
|
robbat2 joined #evergreen |
| 08:19 |
|
ericar joined #evergreen |
| 09:09 |
bshum |
Dyrcona: Yes, that happened to me. |
| 09:09 |
|
yboston joined #evergreen |
| 09:10 |
Dyrcona |
bshum: Did you figure it out? |
| 09:10 |
bshum |
Dyrcona: What I found was that local definitions were breaking things in browse for some reason. I never did get to the bottom of that with eeevil. |
| 09:10 |
bshum |
We had an added author entry that was also for browse and something in the xpath or such was breaking the indexing process. |
| 09:11 |
bshum |
I think I set it aside in my testing by making it not a browse entry for the moment and then things proceeded as expected. So something in how I defined a local index broke things. |
| 09:11 |
Dyrcona |
I'll check. We probably have a similar situation. |
| 09:11 |
bshum |
Though i'm not 100% sure why. |
| 09:11 |
bshum |
I think it was a combination of explicit marcxml definition vs. mods32 stuff |
| 09:11 |
Dyrcona |
I don't recall adding browse search definitions. As I recall, the one that I tried adding never worked. |
| 09:11 |
bshum |
And the browse-xpath entry borked something |
| 09:12 |
* dbs |
wonders if phasefx's live testing script could be repurposed to also leave a running system at dev.evergreencatalog.com at the end; and set up not just master, but also current stable for demo.evergreencatalog.com |
| 09:13 |
Dyrcona |
Heh. My laptop just updated "libmagic1." I wish it really lived up to the name. :) |
| 09:16 |
|
Guest37989 joined #evergreen |
| 09:17 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Only browse_xpath we added" (3 lines) at http://paste.evergreen-ils.org/48 |
| 10:07 |
Dyrcona |
I think we might have changed one or two, but my memory is fuzzy. I'll have to compare with the stock entries in 950.*.sql or wherever. |
| 10:07 |
bshum |
Dyrcona: Unfortunately no, I was just messing with the function's definition directly in my pgadmin window and learning how to apply the raise statements. |
| 10:07 |
Dyrcona |
bshum: NP. Just thought I'd ask. |
| 10:07 |
bshum |
I don't think I have that anymore because we blew away that test system already :( |
| 10:08 |
Dyrcona |
I am going to run another browse ingest and capture all of the output to a file. |
| 10:08 |
Dyrcona |
Then, I'll know if it is every record or just some records. |
| 10:08 |
Dyrcona |
Maybe I'll try adding the raise statements beforehand. |
| 13:55 |
eeevil |
Dyrcona: k. you got an LP already? if not, I'll create one and toss this up |
| 13:55 |
Dyrcona |
eeevil: No, I didn't make a bug, yet. |
| 13:55 |
eeevil |
on it |
| 13:56 |
dbs |
For further win, add a pgtap test that triggers the problem (until the fix goes in, natch) |
| 13:56 |
|
hbrennan joined #evergreen |
| 13:56 |
eeevil |
dbs: this is a good point. Dyrcona, do you think you could do that? |
| 13:57 |
phasefx |
jeff: tsbere: do either of you know how to configure a staff client for a "silent" install? |
| 13:58 |
Dyrcona |
eeevil dbs: I don't usually use concerto, but I could add a record from our collection that triggers it. |
| 13:58 |
tsbere |
phasefx: What kind of silent install are you looking for? |
| 13:58 |
dbs |
Dyrcona: yeah, for a pgtap test you could just insert the record directly as part of the test. No need to rely on concerto |
| 13:58 |
eeevil |
Dyrcona: that, or forcing in a record shaped like this one at id=-2, say, and watching it blow up |
| 13:59 |
phasefx |
tsbere: the only context given to me was for "automated background installation", but I can solicit more info |
| 14:00 |
tsbere |
phasefx: Look into passing /S to the installer, if my memory is correct. If that doesn't work I can google the information. |
| 14:00 |
phasefx |
tsbere: thanks man |
| 14:01 |
Dyrcona |
dbs: I'll look into inserting the record. I recall seeing another test that does that. |
| 14:03 |
|
Wyuli joined #evergreen |
| 14:04 |
tsbere |
phasefx: I think that /autoupdate, /noautoupdate, /permachine, /nopermachine, and /developer are also accepted (when the client was built with those options) |
| 14:06 |
dbs |
Pg/t/regress/lp1242999_unbreak_new_encode.pg may be what you're looking for :) |
| 14:07 |
eeevil |
Dyrcona: a branch to base your tap test on: working/user/miker/lp1303940-browse-hates-null |
| 14:07 |
Dyrcona |
dbs && eeevil Thanks to you both. |
| 14:09 |
dbs |
eeevil is in my head |
| 14:10 |
eeevil |
dbs: it's very cold, but polite, in here |
| 14:11 |
jl- |
uhm, so about that bib_tag in the database for each record.. what is it? |
| 14:11 |
eeevil |
jl-: I confess, I have no idea what you are describing... |
| 14:11 |
jl- |
makes 2 of us |
| 14:13 |
eeevil |
oh! hah... that just pins the bib id of the records in that test dataset |
| 14:13 |
phasefx |
tsbere: invoking the installer works with /S, not sure if we can build an installer with that behavior enabled by default, but maybe /S to the installer will suffice. thanks man |
| 14:13 |
tsbere |
phasefx: I believe we could make it do so by default |
| 14:14 |
tsbere |
would require editing the nsi file, though |
| 14:16 |
* tsbere |
isn't sure that is the best idea and prefers the /S option |
| 14:16 |
* phasefx |
nods |
| 14:16 |
eeevil |
it looks to be used for constructing the last_xact_id. you can ignore that, unless you want to be able to use that to identify batches of records that you use marcxml_import() to pull in |
| 14:18 |
jl- |
eeevil: correct, but in my case it's not a test dataset I'm using it to load our university bibs |
| 14:20 |
eeevil |
jl-: so ... what's your question. last_xact_id is used for optimistic locking in the normal workflow. it can also do double duty as a way to identify records that came into the system in batch. you can ignore it, or use it, but it's just an opaque string, insofar as the software is concerned... does that help? |
| 14:20 |
jl- |
eeevil: yes, so it might be useful in the database, but it has no functionality in the frontend? |
| 14:22 |
jl- |
see the example here: http://paste.debian.net/92250 |
| 14:22 |
jl- |
of course I have ~200k following |
| 14:28 |
Dyrcona |
jl-: Note what eeevil said about "optimistic locking in the normal workflow." If a user has a record open while something else changes it in the background, the staff client won't save the user's changes if the last_xact_id has changed in the meantime. |
| 14:29 |
Dyrcona |
jl-: It's particular value is usually unimportant. |
| 14:31 |
jl- |
Dyrcona: in my case I'm planning ahead, we don't have any users. I'm running test-migrations |
| 14:32 |
Dyrcona |
jl-: I understand. We're telling you what that field is used for. Basically, it doesn't matter what you put into it at the start. |
| 14:33 |
Dyrcona |
jl-: I did something like IMPORT-{UNIX_timestamp} during our migration. |
| 14:37 |
|
RoganH joined #evergreen |
| 15:17 |
Dyrcona |
wifi-- |
| 15:18 |
bshum |
@blame wifi |
| 15:18 |
pinesol_green` |
bshum: wifi 's bugfix broke bshum's feature! |
| 15:18 |
kmlussier |
berick: I got a little lost in the discussion for bug 1187993. Would it indeed be useful for me to ask somebody to do a small JAWS test of a site using HTML5 datalist elements? |
| 15:18 |
pinesol_green` |
Launchpad bug 1187993 in Evergreen "Auto suggest causes significant accessibility issues for using basic search in some browsers" (affected: 3, heat: 18) [High,Confirmed] https://launchpad.net/bugs/1187993 |
| 15:18 |
Dyrcona |
So, is it normal for pg_tap to say that you gave it a bad plan if a test fails? |
| 15:18 |
kmlussier |
berick: If so, I'll do it ASAP. |
| 15:18 |
jeff |
I see no left joins, SET copy_id, or even UPDATE statements in that trigger. |
| 15:19 |
jeff |
anyone else who cares to, i'd be interested if this turns up a non-zero value: select count(*) from asset.opac_visible_copies where copy_id is null; |
| 16:57 |
jeff |
gsams: pay particular attention to the basics, like the reverse DNS (PTR) record for the mail server. |
| 16:58 |
gsams |
jeff++ #that will be super helpful! |
| 16:59 |
gsams |
jeff: yeah the basics, I'm pretty sure are solid. But the also recommend portion is definitely questionable for us. |
| 16:59 |
jeff |
also, generating some test messages to a gmail account you control can help when you get to the point of reviewing your SPF record, etc. -- it's useful to do a before and after there. |
| 16:59 |
jeff |
FWIW, we do not currently do DKIM or DMARC on our transactional email from the ILS, and have not had problems. |
| 17:00 |
jeff |
But we also have a pretty strong separation between transactional and promotional -- our promotional stuff goes through completely different channels. |
| 17:01 |
jeff |
The unfortunate truth is that in some cases, a handful of users hitting "this is spam" can hurt you regardless of what you do. |
| 17:01 |
jeff |
for sufficiently large values of "handful" :-) |
| 17:01 |
gsams |
yeah, that also had occured to me. I know at least this is purely transactional though, so I've got that going for me. |
| 17:02 |
gsams |
and SPF is setup already... |
| 17:02 |
jeff |
worth a test to ensure that your spf record as seen by and interpreted by google is resulting in a pass. |
| 17:03 |
jeff |
(headers as viewed in gmail "View Original" will help there) |
| 17:03 |
gsams |
well, the odd thing for me: v=spf1 include:_spf.google.com ~all |
| 17:05 |
gsams |
I'm honestly not sure if that is odd actually... |
| 17:05 |
jeff |
sounds like you're a google apps user, and sounds like that SPF record is intended to identify the mail for that domain that is sent through google apps. it does not appear to account for the mail being sent from the ILS. |
| 17:09 |
jeff |
with ~all and the sending server not in the list, you'll get a softfail. |
| 17:09 |
jeff |
which is in most cases worse than not having any SPF record. :-) |
| 17:09 |
jeff |
even with the "Receiving software SHOULD NOT reject the message based solely on this result" bit. |
| 17:26 |
gsams |
well a postfix test showed it heading to spam for my gmail. I've gone in and added an SPF record for our system, so we will see in a bit if it helps us out. |
| 17:26 |
gsams |
jeff++ Dyrcona++ |
| 17:26 |
gsams |
thanks again! |
| 17:26 |
gsams |
bshum++ as well |
| 17:27 |
bshum |
gsams++ # raising the question and getting me wondering about our own systems too.... |
| 17:31 |
gsams |
roanoke_patrons++ #for raising the issue enough times to get me to do that! |
| 17:31 |
pinesol_green` |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:46 |
|
book` joined #evergreen |
| 18:56 |
gmcharlt |
FYI, OpenSSL has released a major security fix http://heartbleed.com/ |
| 18:56 |
rangi |
yeah, upgrade all the things |
| 00:05 |
|
ningalls joined #evergreen |
| 00:10 |
|
torrie joined #evergreen |
| 04:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:36 |
|
Dyrcona joined #evergreen |
| 07:54 |
|
collum joined #evergreen |
| 08:12 |
csharp |
hmm - looks like the change in 80e3f6f may have borked some long-standing PINES reports templates |
| 08:13 |
|
timlaptop joined #evergreen |
| 08:13 |
|
asimon joined #evergreen |
| 08:15 |
|
akilsdonk joined #evergreen |
| 08:19 |
asimon |
*: I am trying to load a file of bib records into a test server. In order to preserve the rest of the data, I did a truncate cascade on the bre table (there are no copy records) and set record_entry_id_seq to 500000. When I load the records, the id numbering starts at 001. The load script is clearly using the TCN (which begins at 500001) as the id. How is this possible? |
| 08:22 |
csharp |
asimon: there's a "global flag" that determines that behavior, if I recall correctly |
| 08:23 |
csharp |
config.global_flag? (I don't have access to our DB right this second to check) |
| 08:24 |
csharp |
also available via the staff client in the Server Admin section, btw |
| 10:52 |
bshum |
New bug usually. |
| 10:53 |
bshum |
would be what I would recommend when dealing with something that's already been released. |
| 10:54 |
mmorgan |
I'll poke around some more and open one if warranted. Thanks! |
| 10:58 |
bshum |
Hmm |
| 10:58 |
bshum |
mmorgan: Can you tell us a little more about the org unit structure and which ou you're disallowing from hold pickup? |
| 10:59 |
bshum |
(when I tested it just now, it worked fine to disable the option on the place hold screen...) |
| 11:01 |
mmorgan |
Interesting. Here's a pic: http://screencast.com/t/AIs8afgOj0gZ |
| 11:02 |
csharp |
could it be autogen.sh related? |
| 11:02 |
mmorgan |
We have NOBLE(All libs) as consortium, then Phillips Academy as a system. It's some of the branches I'm trying to disallow, like Phillips Addison |
| 13:05 |
bshum |
Haha |
| 13:06 |
Dyrcona |
:) |
| 13:07 |
* dbs |
wonders if anyone is willing to add serial.* data to the --load-all side of things |
| 13:08 |
bshum |
berick: I have a question about websockets and upcoming changes to OpenSRF. |
| 13:08 |
bshum |
As I work my thoughts together about the XUL vs. web client |
| 13:09 |
bshum |
I'm wondering if any changes in the underlying architecture would require us to test also the XUL client to make sure we don't break things? |
| 13:09 |
bshum |
While we transition to the web client |
| 13:10 |
berick |
bshum: websockets will have no effect on the xul client. it has to be activated within the script / application to be used, and the browser client code is the only thing (for now, anyway) that activates it. |
| 13:10 |
berick |
the activation occurs within the base browser staff template |
| 13:10 |
bshum |
berick: Ah, cool deal. Then I feel slightly better on that front. |
| 15:20 |
dbs |
For that matter, the 69x mappings are supposed to be local too. There are only a couple that match even OCLC's definitions. |
| 15:20 |
yboston |
jl-: congrats |
| 15:20 |
yboston |
jl-: which import approach did you use? |
| 15:20 |
jl- |
I'm hoping to get one of our libraries as a gineau pig for a pilot now, maybe for a dvd collection, or something.. wean them off voyager |
| 15:21 |
jl- |
yboston: I used the sql_loader which is pretty close to the staging table from dbs |
| 15:21 |
jl- |
in /openils/Evergreen-ILS-2.5.1/Open-ILS/tests/datasets/sql/ |
| 15:22 |
jl- |
I made a script that formats them simialr to the concerto files |
| 15:26 |
jl- |
anyway, have a good weekend everyone |
| 15:27 |
jeff |
neat, we have an action.billable_cirulations view. i wonder if that's a known typo or something specific to us. :-) |
| 15:28 |
hbrennan |
jl-: Ugh, it's 11:30 here, but my body thinks it's later so I can leave too right? |
| 15:28 |
jeff |
(we also have action.billable_circulations) |
| 16:01 |
bshum |
That's the first time in a long time someone's used that... |
| 16:03 |
bshum |
I suppose we don't really use LP that way. |
| 16:05 |
|
madseumas joined #evergreen |
| 16:10 |
ericar |
bshum: out of curiosity, I just tried recreating what she's reporting. I can't reproduce the results. tested on 2.5.3b |
| 16:11 |
bshum |
ericar: Thanks for taking a look over. I wasn't too sure what all the circumstances are here. |
| 16:12 |
bshum |
The LP account who opened that question seems to be someone from Evergreen Indiana. |
| 16:12 |
ericar |
bshum: me either |
| 16:14 |
Bmagic |
csharp: Thanks for the info |
| 16:14 |
bshum |
mmorgan: Oh interesting... holding the key down does give me various JS errors. |
| 16:14 |
bshum |
For different Fn keys |
| 16:15 |
madseumas |
Hello, everyone. I just updated a small (20k items or so) library from 2.3.2 to 2.5.3b on a test VM. Upgrades all went fine, no db errors. She (it's my wife's library; I'm a unix admin by trade so I help her maintain it) was using jspac, which is gone now. Should the uncustomized tpac still be able to return records or does it need some basic level of customization before it will? Keyword searches that work on her liv |
| 16:15 |
bshum |
madseumas: You got cut off at "keyword searches that work on her live" |
| 16:15 |
bshum |
IRC has a cap on how much you can type at once. So just break up the sentences a bit :) |
| 16:16 |
madseumas |
argh sorry, will do |
| 16:16 |
madseumas |
should read " Keyword searches that work on her live system return nada on this test one." |
| 16:16 |
ericar |
mmorgan: yes, first time got TypeError: $("patronStrings").getString is not a function second try got TypeError: $("commonStrings") is null. Held the key for about 2 seconds |
| 16:16 |
madseumas |
haven't done IRC in 10 years or so :) |
| 16:17 |
mmorgan |
lp 1300789 |
| 16:24 |
rjackson-isl |
it is repeatable |
| 16:24 |
madseumas |
csharp: yes, ran reingests, very carefully followed DB script output from each |
| 16:24 |
rjackson-isl |
use F4 and before the screen pops up hit another F key |
| 16:25 |
dbs |
madseumas: does the test VM have enough memory? 2.0 GB of RAM or more? |
| 16:25 |
csharp |
madseumas: well, at the very least, VACUUM ANALYZE all of the metabib.* tables |
| 16:25 |
rjackson-isl |
other sequence such as F1 then F4 does not produce this |
| 16:25 |
madseumas |
dbs: test VM has 2GB of RAM. No memory pressure, catalog is quite small |
| 16:26 |
dbs |
although... if title searches are working, one would think all db calls should |
| 16:26 |
dbs |
madseumas: heh, 2.0 GB is barely enough for our ~200 test record set with all services running |
| 16:27 |
csharp |
yeah, I use a minimum of 4 GB, even on small test servers |
| 16:27 |
ericar |
rjackson-isl: I just reproduced the error you describe above. However, it was from holding the F4 key while still trying to use another F key. Also, holding the F4 too long will reproduce the results |
| 16:27 |
dbs |
bshum: 901c, yeah, that's something |
| 16:27 |
csharp |
but you should see swapping or i/o wait in top when the searches are processed |
| 16:32 |
dbs |
madseumas: wondering if it's the missing 901 fields, then, as bshum suggested |
| 16:33 |
|
mrpeters left #evergreen |
| 16:34 |
madseumas |
csharp: command line search, limit 10, I see 10 ids being returned |
| 16:34 |
dbs |
SELECT COUNT(*) FROM biblio.record_entry WHERE marc !~ 'tag="901"'; -- if you can query the database would be a good test |
| 16:34 |
dbs |
Result should be 0. |
| 16:34 |
madseumas |
dbs: will do, one sec |
| 16:35 |
madseumas |
dbs: result was 11780 |
| 16:35 |
bshum |
Oops |
| 17:26 |
hbrennan |
Access?! Oh jeez. |
| 17:27 |
madseumas |
yah, the forms allowed you to search by specific title or author but that was it. cataloging was a nightmare. |
| 17:27 |
hbrennan |
I can only imagine. |
| 17:30 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
madseumas |
quick question, where do the default book jackets in a tpac catalog search come from? |
| 17:32 |
madseumas |
I had thought google books stuff was turned off by default |
| 17:33 |
bshum |
madseumas: By default in newer versions I believe the added content handler is for OpenLibrary |
| 03:07 |
|
dbwells joined #evergreen |
| 03:25 |
|
dkyle joined #evergreen |
| 05:55 |
|
flopaul joined #evergreen |
| 07:37 |
csharp |
@later tell gmcharlt I'll need to re-review it. I have a fresh 14.04 vm to test with, so it'll be today |
| 07:37 |
pinesol_green |
csharp: The operation succeeded. |
| 08:10 |
|
tfaile joined #evergreen |
| 08:10 |
|
ktomita_ joined #evergreen |
| 10:55 |
* pinesol_green |
brews and pours a cup of Ethiopia Washed Yirgacheffe, Koke Grade 1, and sends it sliding down the bar to gmcharlt |
| 10:55 |
kmlussier |
Two lemon sherberts in one morning. :( |
| 11:05 |
|
collum joined #evergreen |
| 11:06 |
csharp |
gmcharlt: my ubuntu-14.04 OpenSRF Makefile branch installs fine and passes the opensrf.math test, but I haven't run Evergreen on it yet |
| 11:06 |
gmcharlt |
csharp: great - do you expect to have tuits to do an Evergreen test soonish? |
| 11:07 |
csharp |
sure - I'll install EG after lunch |
| 11:07 |
csharp |
virsh_snapshot-create++ |
| 11:12 |
jeff |
tspindler: i have more than one kringle from that bakery in Racine on my kitchen counter at this very moment. :-) |
| 12:53 |
Dyrcona |
csharp++ # for wrangling with the Trusty Tahr. |
| 12:53 |
Dyrcona |
heh, goatherding. :) |
| 12:53 |
jeff |
technically 14.04 isn't even out yet, so it's of course tricky claiming support for it. In theory, it should be pretty stable now. |
| 12:53 |
csharp |
jeff: it's pretty solid in our smoke tests |
| 12:54 |
jeff |
yeah, I meant "stable" as in "no longer a moving target" |
| 12:54 |
jeff |
i should have clarified. |
| 12:54 |
csharp |
though, I did hit a bug in the installer when configuring LVM |
| 13:36 |
berick |
antimarcite |
| 13:42 |
kmlussier |
@dessert |
| 13:42 |
* pinesol_green |
grabs a slice of Red Velvet Cheesecake and sends it sliding down the dessert bar to kmlussier |
| 13:59 |
bshum |
csharp: Fwiw, I put a copy of our full database into a PG 9.3 running on 12.04 and that seems to be fine so far. Or at least I haven't hit any significant pains yet. (once I upgraded to include the 9.3 fixes) |
| 13:59 |
bshum |
I'll be curious what you come up with for 14.04. We'll get to it sometime. |
| 14:00 |
bshum |
I'm still deciding whether during our next upgrade we'll move from 9.1 to 9.3 in production too. |
| 14:00 |
bshum |
That stuff I just said was for our test server only. |
| 14:03 |
csharp |
cool |
| 14:06 |
csharp |
okay - looks like we're down to 3 CPAN dependencies with 14.04 |
| 14:06 |
csharp |
so that's nice |
| 15:04 |
* csharp |
doesn't build from scratch very often nowadays |
| 15:05 |
dbs |
I think we agreed to deep-six Lucid support for 2.6, right? Add 14.04, drop 10.04. |
| 15:05 |
csharp |
yep |
| 15:07 |
bshum |
I think nobody's tested 2.6 with Lucid anyways. So... it's already dead to me! |
| 15:07 |
bshum |
(but probably works) |
| 15:08 |
* dbs |
tries removing ld.so.conf.d entry on Fedora 20 to see if that whole section can be wiped out |
| 15:08 |
csharp |
okay - this shows my limited autotools knowledge, but how does make find the right library? |
| 15:08 |
gmcharlt |
dbwells: needless to say, I'm perfectly fine with you squashing that branch mercilessly |
| 15:09 |
dbs |
Nope, still necessary on Fedora. |
| 15:10 |
dbs |
"Failed to dlopen library file oils_pcrud.so: libdbdpgsql.so" |
| 15:10 |
|
kmlussier joined #evergreen |
| 15:11 |
dbs |
csharp: very rough approximation, autotools runs a million tests to detect its environment and configure things as automagically as possible. and then you can override behaviour to boot. |
| 15:11 |
kmlussier |
gmcharlt++ #acknowledgements |
| 15:11 |
csharp |
dbs: okay - I figured |
| 15:13 |
|
gsams joined #evergreen |
| 16:42 |
|
tspindler left #evergreen |
| 17:07 |
|
bmills joined #evergreen |
| 17:08 |
|
gsams joined #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:22 |
|
mmorgan left #evergreen |
| 17:24 |
|
Dyrcona joined #evergreen |
| 17:35 |
|
tsbere joined #evergreen |
| 00:05 |
|
remingtron__ joined #evergreen |
| 03:39 |
|
b_bonner joined #evergreen |
| 03:39 |
|
mtcarlson_away joined #evergreen |
| 05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:56 |
|
timlaptop joined #evergreen |
| 07:18 |
|
Callender joined #evergreen |
| 07:32 |
|
Callender joined #evergreen |
| 11:54 |
|
mrpeters left #evergreen |
| 11:54 |
|
mrpeters joined #evergreen |
| 11:57 |
phasefx |
bshum: no worries. I have no strong opinions about LP other than that its search function could use improvement, so I'm glad you care enough about it to act on things |
| 12:08 |
csharp |
ok, I'm trying to get EDI working on a test server... we create a purchase order and activate it. 5 minutes later I see the A/T event process, then the edi_pusher.pl script runs and by its feedback messages, it appears to be working (after enabling passive FTP). However, the vendor did not receive the file - any thoughts? The lack of error logs is handicapping me here |
| 12:10 |
csharp |
2014-04-01 15:33:38 acq ./edi_pusher.pl: [INFO:20745:RemoteAccount.pm:595:] OpenILS::Utils::RemoteAccount : successfully sent <vendorURL> /tmp/bzVbVKKjQp --> Out//bzVbVKKjQp |
| 12:14 |
|
mcooper joined #evergreen |
| 12:15 |
* csharp |
will rule out human error (e.g., wrong FTP directory) before continuing to beat on it |
| 12:25 |
rfrasur |
Cheesecake has arrived and pictures will be forthcoming since that's the only way I know to digitize them so far (and a 3D scanned and printed model would just be mean). |
| 12:26 |
Dyrcona |
rfrasur: There is talk of 3D printed "food." |
| 12:26 |
rfrasur |
Hmm, then there are better possibilities for the future than pictures. But not yet :D |
| 15:21 |
sseng |
jihpringle: acq |
| 15:21 |
jihpringle |
there are some claiming bugs in the manual process in acq depending on what version you're running |
| 15:22 |
sseng |
jihpringle: oh ok |
| 15:23 |
jihpringle |
we've tested manual claiming in acq but none of our libraries currently use it |
| 15:23 |
jihpringle |
the bug to watch out for is - https://bugs.launchpad.net/evergreen/+bug/1195063 |
| 15:23 |
pinesol_green |
Launchpad bug 1195063 in Evergreen "ACQ: Claim Vouchers Do Not Appear and Cause Problems with Profiles" (affected: 2, heat: 12) [Undecided,New] |
| 15:24 |
sseng |
jihpringle: having a hard time finding claimings documentation in terms of automated claming . and now that it's been clarified that it's currently manual only... thanks! |
| 15:24 |
jihpringle |
np |
| 15:31 |
jeff |
csharp: huh. well that's interesting. one of my working theories here was that the issue was related to trying to walk a bunch of holds that the copy wasn't eligible to fulfill, and that combined with something else was causing the breakage. |
| 15:31 |
jeff |
csharp: the example i had the other day was an age protected copy with 80+ holds at non-local libraries. |
| 15:31 |
csharp |
the first example was probably a fluke - a patron requested the title literally 90 seconds before staff began checkin and it captured for the new hold - staffperson assumed it was the "old" hold |
| 15:31 |
jeff |
so it did the hold permit test 80+ times... twice, I think. |
| 15:32 |
csharp |
jeff: ah |
| 15:33 |
pastebot |
"csharp" at 64.57.241.14 pasted "log messages for clear hold shelf checkin modifier failure" (5 lines) at http://paste.evergreen-ils.org/41 |
| 15:34 |
csharp |
jeff: ^^ this is what we see server side at the time of the network errors in our library's case |
| 16:46 |
krvmga |
kmlussier: you got the single layer icons? |
| 16:47 |
kmlussier |
krvmga: I did and I've rolled everything into a git branch. |
| 16:47 |
kmlussier |
krvmga++ |
| 16:57 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:58 |
yboston |
@marc 400 |
| 16:58 |
pinesol_green |
yboston: unknown tag 400 |
| 17:06 |
krvmga |
is there any way to do a call number search limited to the children's collection in eg 2.4? i'm thinking that it might be possible in 2.5. |
| 00:14 |
dcook |
Hehe. I was just thinking it must be fairly massive. |
| 00:15 |
dcook |
biblioitems in Koha is rather enormous though. It stores the full MARCXML (minus items) in a field, then bits and pieces in other fields. |
| 00:15 |
dcook |
Anyway, thanks for the info :) |
| 00:17 |
bshum |
Sure thing :) |
| 00:20 |
bshum |
@later tell dbwells Oh you know... maybe this is weird 9.3 stuff. This is a newer postgres we're using for our test server and maybe it's mucking something up? I really will look more closely tomorrow on why it's creating nonsense. |
| 00:20 |
pinesol_green |
bshum: The operation succeeded. |
| 00:25 |
bshum |
Well it works fine with our concerto database. So, maybe I just have some really strange records causing things to break down. |
| 00:28 |
bshum |
I can't even figure out why it would even try inserting what it did. We don't have any bib IDs that go that high. |
| 00:31 |
bshum |
There's two |
| 00:31 |
* bshum |
hits head on table |
| 00:49 |
dcook |
:( |
| 01:07 |
bshum |
Grr |
| 01:07 |
bshum |
It's got to be something weird with some other browse index in my system. I removed the one we're testing and it's still failing and doing weird stuff. |
| 01:07 |
bshum |
I wish I could figure out which bib was breaking this |
| 01:15 |
* dcook |
believes in bshum! |
| 01:49 |
bshum |
Whee, added a RAISE NOTICE statement to read off the bib_id for whatever it tries inserting |
| 01:49 |
bshum |
Now I'll find the culprit bib! |
| 10:29 |
jl- |
http://vf-stlib.klnpa.org/vufind/ |
| 10:29 |
jl- |
looks so much better |
| 10:30 |
berick |
kmlussier: yep, known issue. will get back to that soon |
| 10:30 |
jl- |
http://vf-stlib.klnpa.org/vufind/Search/Results?lookfor=test&type=AllFields&submit=Find |
| 10:30 |
kmlussier |
berick: Thanks! |
| 10:31 |
* dbs |
submitted some fixes for the Evergreen driver for VuFind recently, that were accepted. |
| 10:32 |
dbs |
jl-: Conifer is Laurentian University, Algoma University, Northern Ontario Medical School, Collège Boréal, and a bunch of smaller libraries. |
| 11:26 |
jl- |
I've had mild success with the concerto sql loader (50k records) and the staging table (http://docs.evergreen-ils.org/dev/_migrating_your_bibliographic_records.html) however, for the records past that number both scripts went into a crazy loop, never stopping until disk space (>100GB) was full |
| 11:26 |
jl- |
it might be my records fault tho but I did clean them |
| 11:27 |
jl- |
Im not sure what technique to stick with |
| 11:27 |
jboyer-isl |
This is semi-recent, though not personally tested: http://docs.evergreen-ils.org/2.5/_migrating_your_bibliographic_records.html |
| 11:28 |
jboyer-isl |
That section covers more than just records. |
| 11:28 |
jl- |
http://docs.evergreen-ils.org/2.5/_migrating_your_bibliographic_records.html |
| 11:28 |
jl- |
sry |
| 11:28 |
jboyer-isl |
Oh, hey, you apparently were looking at a recent version of that. Oops. :( |
| 12:21 |
gmcharlt |
interesting could be good or bad... :) |
| 12:21 |
jcamins |
gmcharlt: wahanui, is that you?!? |
| 12:21 |
Dyrcona |
:) |
| 12:21 |
gmcharlt |
jcamins: hey! I pass the Turing test at least 3/4 of the time! |
| 12:24 |
Dyrcona |
yboston: Have you changed your ssh key lately? |
| 12:25 |
yboston |
I switch to a new machine, but I was under the impression that the old key came over |
| 12:25 |
yboston |
but I was wondering if this was part of the issue |
| 12:28 |
gmcharlt |
yboston: not to worry -- you would have to try very hard to do something that tsbere and I couldn't fix |
| 12:28 |
yboston |
gmcharlt: BTW I have been watching your Git tutorial video, good job |
| 12:29 |
gmcharlt |
how was the recording? |
| 12:29 |
yboston |
though not done watching yet. I also watched a 5 hour lynda.com training videeos that was good too |
| 12:29 |
yboston |
the audio and video are not perfect, but I had a very clear shot of the screen |
| 12:30 |
yboston |
I am watching it without any compression (audio or video), so if I post it to YOutube, etc it might nto be as goos |
| 12:30 |
yboston |
*good |
| 12:30 |
yboston |
I can prepare a sample on youtoube as a test |
| 12:31 |
gmcharlt |
ok |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:46 |
|
mrpeters joined #evergreen |
| 13:51 |
dbwells |
I know bshum was poking it and got derailed, but if anyone can review and commit https://bugs.launchpad.net/evergreen/+bug/1259665 , I'd be very appreciative. It is the only thing holding up the RC at this point. |
| 13:51 |
pinesol_green |
Launchpad bug 1259665 in Evergreen "Series search in 2.5 does not retrieve 800 |t" (affected: 3, heat: 20) [High,Confirmed] |
| 13:52 |
dbwells |
It is my understanding the bshum's issues were not related to the minor changes in this branch, but I can't say that 100%. |
| 13:52 |
bshum |
dbwells: Correct, my issues seem unrelated. I did find a few 800t's to test with and they seemed fine on reingest. But I have to enable the browse stuff fully to check things out. |
| 13:53 |
bshum |
Pretty confident we can just merge though :) |
| 13:53 |
bshum |
I'll try and do that after a few more meetings end. |
| 13:53 |
bshum |
Sorry :\ |
| 13:57 |
Dyrcona |
@marc 800 |
| 13:57 |
pinesol_green |
Dyrcona: An author/title series added entry in which the author portion is a personal name. (Repeatable) [a,b,c,d,e,f,g,h,j,k,l,m,n,o,p,q,r,s,t,u,v,4,6,8] |
| 13:57 |
Dyrcona |
t is the title? |
| 16:18 |
|
denishpatel joined #evergreen |
| 16:26 |
Dyrcona |
Hey, bartender! Hey, man! Lookee here! Draw one, draw two, draw three, four glasses of beer! |
| 16:26 |
* Dyrcona |
channels Floyd Dixon. |
| 16:28 |
yboston |
jl-: My biggest batch with that script was like 2200 records without holdings from EBSCO ebooks service via OCLC. It ran fine on my test server, but I had a timeout error when loading them to my production server hosted by ESI |
| 16:28 |
yboston |
jl-: which is a few states away from here, so there shoudl have been latency issues |
| 16:29 |
yboston |
jl-: BTW< did we meet at the conference? |
| 16:34 |
|
afterl left #evergreen |
| 16:38 |
|
afterl joined #evergreen |
| 16:45 |
|
afterl left #evergreen |
| 16:55 |
bshum |
Ack, rebase on other pushed commits. |
| 16:55 |
* bshum |
does the dance |
| 16:55 |
bshum |
And we're good |
| 16:56 |
yboston |
mceraso++ for testing OSRF |
| 16:56 |
|
mdriscoll left #evergreen |
| 16:56 |
kmlussier |
mceraso++ |
| 16:57 |
bshum |
mceraso++ |
| 00:54 |
|
alynn26 joined #evergreen |
| 01:30 |
|
Polonel joined #evergreen |
| 01:38 |
|
fredp_ joined #evergreen |
| 05:05 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:15 |
|
remingtron_ joined #evergreen |
| 05:15 |
|
dbwells_ joined #evergreen |
| 05:29 |
|
flopaul joined #evergreen |
| 13:50 |
pinesol_green |
rfrasur: hussein Hussein-ify your anagram! |
| 13:50 |
rfrasur |
good grief |
| 13:50 |
|
pams joined #evergreen |
| 13:50 |
jcamins |
rfrasur: I guess you don't want to hear "a focus group of actual users/usability test with a mockup of the cheap version of the site might help." |
| 13:51 |
kmlussier |
yboston: I didn't document too many commands in the quick start guide because I didn't want to overwhelm newbies. But I think it would be nice to have a page that documents all of the commands we can use. |
| 13:51 |
Dyrcona |
@loves |
| 13:51 |
pinesol_green |
Dyrcona loves git; Tina Dico; you anyway; scripted sign off; sed; Monique Ortiz; and OpenBSD |
| 13:52 |
jcamins |
If you don't ask, you'll just be guessing, and that's a waste of your time! |
| 13:52 |
* jcamins |
gets off soapbox sheepishly. |
| 13:52 |
rfrasur |
fwiw, I know. You just asked what I WANTED. Not what I know needs to happen. |
| 13:52 |
kmlussier |
rfrasur: A simple usability test can be something simple to implement. |
| 13:52 |
jcamins |
lol |
| 13:52 |
jcamins |
That's true. |
| 13:52 |
rfrasur |
^ |
| 14:22 |
lstjohn |
kmlussier: +++1 conference was stellar thanks for the planning |
| 14:22 |
mbcraw |
how do you know when a remote meeting is scheduled? do you get an email notice? |
| 14:22 |
ddale |
afterl: how do you have a private chat. |
| 14:22 |
rangi |
speaking of which Dyrcona, current tstate of play for teh NCIP stuff is it is in preliminary testing with MassCat .. but the NCIP/ILS/Evergreen.pm still needs to be written, and about 20 more handlers (ive covered all the ones for ILL) <-- useful stuff |
| 14:22 |
rangi |
also, I hate NCIP |
| 14:22 |
afterl |
jihpringle: thank you so much |
| 14:22 |
rfrasur |
mbcraw: many of the announcements go through the ils-general email list. |
| 14:22 |
terranm |
I do like IRC for meetings, but I'm not usually in here otherwise because I don't have the mental bandwidth with my other work |
| 15:37 |
|
tonyb_ohionet joined #evergreen |
| 15:38 |
berick |
dbwells: you around? like to get some UI feedback from you when you get a sec |
| 15:39 |
dbwells |
berick: sure, ask away |
| 15:39 |
berick |
kmlussier too if you got a sec.. |
| 15:39 |
berick |
https://bill-dev2.esilibrary.com/eg/staff/test/autogrid (admin / demo123) |
| 15:39 |
berick |
working on grid column width and sort priorities |
| 15:39 |
berick |
drop down menu along top right, Configure Columns |
| 15:40 |
berick |
adds a new inline config option |
| 15:40 |
berick |
(which is much better than a popup, because you can see what you're doing) |
| 15:40 |
berick |
anyway, the display is not all there yet, needs to be more well.. visually documented or some such |
| 15:40 |
kmlussier |
Nice |
| 15:40 |
berick |
but curious about suggestions, plusses, minuses |
| 15:41 |
kmlussier |
Is there a way users can resize the columns? |
| 15:47 |
dbwells |
berick: new Chrome works fine |
| 15:47 |
berick |
dbwells: cool |
| 15:48 |
berick |
jihpringle: cool, thanks |
| 15:48 |
eeevil |
berick: in your test, are you doing server-side sorting? (and are you paging ... which is the driver for my question) |
| 15:48 |
jihpringle |
berick: would the column widths stay or would you have to redo them everytime you go into the interface? |
| 15:49 |
berick |
jihpringle: they would eventually persist |
| 15:49 |
berick |
so, you would jsut set them once |
| 16:20 |
eeevil |
fixed height rows, yes, agreed |
| 16:20 |
dbwells |
glad you guys sorted that out, wasn't sure what was being asked of me :) |
| 16:21 |
jihpringle |
the ability to toggle to wrap text in places where long titles display would be handy (like the hold shelf browse), but other than that fixed height rows work for me |
| 16:21 |
berick |
here's another one, with scrolling on (but not paged yet) -- https://bill-dev2.esilibrary.com/eg/staff/test/autogrid2 -- and the template code: http://paste.lisp.org/display/141804 |
| 16:23 |
eeevil |
some way to see the full content, but elipsis-truncated for long data (CSS!!! text-overflow:ellipsis) |
| 16:23 |
berick |
template code for the other, with explicit fields and (some) labels http://paste.lisp.org/display/141805 |
| 16:23 |
berick |
eeevil++ |
| 16:50 |
dbwells |
berick: I also just looked at your second example, and even with longer data, the variable height rows aren't as bad as I thought they would be. Still, that's a small sample, so my general tendency toward convention stands :) |
| 16:51 |
dbwells |
berick: also, as random bug report you probably know about shift-click selection is turning everything blue. |
| 16:52 |
kmlussier |
berick++ |
| 16:52 |
berick |
dbwells: fixed-height: https://bill-dev2.esilibrary.com/eg/staff/test/autogrid2 |
| 16:53 |
jeff |
dbwells: i believe that's just the default browser behavior when shift-click isn't being trapped, which as berick noted earlier is simply because it hasn't been implemented yet. :-) |
| 16:53 |
berick |
dbwells: yeah, i was confused by that at first. does the same when you click then mouse over |
| 16:54 |
jeff |
as i look at the normalized title/author, what was the name or bug number for the "materialized better-than-simple record extracts" idea/work/branch? |
| 23:43 |
|
rfrasur joined #evergreen |
| 23:54 |
pastebot |
"bshum" at 64.57.241.14 pasted "reingest failure?" (8 lines) at http://paste.evergreen-ils.org/37 |
| 23:55 |
* Guest2223 |
expected "reingest failure" to be related to food in some way |
| 23:55 |
bshum |
Hehe |
| 23:55 |
bshum |
Unfortunately not. |
| 23:56 |
bshum |
@later tell dbwells Testing the reingest command at the end of the 800t reingest with the new browse broke something on my test server. Not sure if it's index related or something deeper. Will investigate more tomorrow. |
| 23:56 |
pinesol_green |
bshum: The operation succeeded. |
| 23:56 |
dcook |
And I'm back |
| 23:57 |
dcook |
Quick ? for you bshum if I may? |
| 16:44 |
* csharp |
t rie s to type fffro m code4libbbbbbbbb |
| 16:44 |
rfrasur |
hehe, nice |
| 16:45 |
jeff |
and i am pleased to report that there was no $18/day charge on my bill for in-room wifi, either. :-) |
| 16:45 |
dbs |
so csharp / bshum , have you written any selenium tests yet? |
| 16:46 |
rfrasur |
jeff: that was also quite lovely. |
| 16:46 |
* dbs |
is delighted to only be dealing with crappy wifi here |
| 16:46 |
csharp |
dbs: nossir |
| 16:46 |
dbs |
csharp: what are you waiting for? 15 minutes of intro so far! :) |
| 16:46 |
jeff |
i need to look at selenium again. i think my last selenium tests were for jspac. :-) |
| 16:46 |
csharp |
heh |
| 16:47 |
jeff |
and they were more along the lines of "it takes HOW long to load X from a cold browser cache?" |
| 16:47 |
dbs |
jeff: really good presentation on it right now |
| 16:47 |
bshum |
dbs: I haven't poked at it, but I remember the lightning talk in vancouver about it |
| 16:48 |
jeff |
<META NAME="Generator" CONTENT="Microsoft Word 97"> |
| 16:48 |
jeff |
<TITLE>NOIMAGE1</TITLE> |
| 16:49 |
phasefx |
we can make it easier for selenium tests too if we embed some non-localizable keywords to indicate state in the HTML we produce |
| 16:50 |
phasefx |
then you can make assertions against the presence or absence of those keywords |
| 16:50 |
dbs |
phasefx: that sounds kind of terrible, actually |
| 16:51 |
phasefx |
I saw that in use when I researched it, but the whole practice of UI testing is kind of terrible IMO :) |
| 16:52 |
phasefx |
why does that specifically sound terrible? |
| 16:53 |
Dyrcona |
"the whole practice of software is kind of terrible" FTFY, phasefx. |
| 16:53 |
Dyrcona |
:) |
| 16:53 |
phasefx |
thanks man |
| 16:53 |
dbs |
Dyrcona++ |
| 16:53 |
* Dyrcona |
is tired and cranky at the moment. |
| 16:53 |
dbs |
phasefx: test the actual things in the UI, like class properties for state |
| 16:54 |
* rfrasur |
is too. |
| 16:54 |
Dyrcona |
rfrasur++ # for putting up with a different brand of crazy. |
| 16:54 |
rfrasur |
I'm not sure how much I put up with it. I feel like I'm nagging at people every five minutes. |
| 16:55 |
* dbs |
takes meds these days and finds he's not as cranky (believe it or not) |
| 16:55 |
phasefx |
dbs: I think I erred using a word like state; too strong. What I read was that you aim for testing the widgets/controls, but don't go for testing functional behavior per se |
| 16:55 |
* rfrasur |
takes a deep breath and goes to get some tea. |
| 16:55 |
* csharp |
never saw much actual sign reading in his frontline public library staff days |
| 16:56 |
rfrasur |
csharp: not even when the librarian is actually putting her hand under the words and reading it aloud? |
