Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139
| 08:57 | Callender joined #evergreen | |
| 08:59 | tfaile joined #evergreen | |
| 09:01 | mmorgan1 joined #evergreen | |
| 09:02 | dbs | bshum: don't sigh about acquisitions testing, please... we're going to try seriously adopting acq after we upgrade to 2.4, and I'm sure all the basic stuff works flawlessly. _flawlessly_. |
| 09:02 | * dbs | still needs to test that basic stuff, is crossing fingers. |
| 09:15 | kmlussier | dbs: acq has come a long way in the past year. I hope your testing goes well! |
| 09:24 | jeff___ joined #evergreen | |
| 09:25 | Simon21 joined #evergreen | |
| 09:25 | pmurray_away joined #evergreen | |
| 09:41 | Dyrcona | The 404 is likely 'cause I missed something that needs to be configured. |
| 09:42 | rjackson-isl | we have a book mobile in offline mode due to poor connectivity and wondered if this would help... |
| 09:42 | jeff_ | the offline patron list downloads a list of barred/lost/expired/penalized patron barcodes, and it depends on offline-blocked-list.pl being run (usually via cron) to generate the list. |
| 09:43 | rjackson-isl | ok - I will see if I can get that going in test jeff_ ++ |
| 09:43 | bshum | Yeah, for some reason Indiana's list.txt is empty. |
| 09:43 | shadowsp1r joined #evergreen | |
| 09:45 | Dyrcona | jeff_++ # I should have known that. |
| 09:47 | dbs | kmlussier: thanks for the reassurance :) |
| 09:48 | kmlussier | dbs: What tools did you use when testing accessibility in tpac? |
| 09:49 | tater joined #evergreen | |
| 09:54 | kmlussier | dbs: nm, I found it. |
| 09:54 | bshum | dbs: I only sigh about testing new acq "features". It's hard to test expected behavior sometimes :( |
| 09:54 | bshum | But I agree with kmlussier that acq has come a very long way from when we first started using them back in 2.0 days. |
| 09:54 | mllewellyn joined #evergreen | |
| 10:15 | kmlussier | Should https://bugs.launchpad.net/evergreen/+bug/1155278 be backported since it is an accessibility issue? Looks like it was only committed to 2.4. |
| 10:15 | pinesol_green` | Launchpad bug 1155278 in Evergreen "TPAC: Accessibility audit compliance" (affected: 3, heat: 14) [Undecided,Fix released] |
| 12:20 | kyleonalaptop joined #evergreen | |
| 12:21 | mllewellyn joined #evergreen | |
| 12:23 | ldwhalen joined #evergreen | |
| 12:25 | eeevil | paxed: it looks ok to me, but I haven't tested it |
| 12:25 | paxed | the material() sees only the full 007 field, not the one character from pos 1 |
| 12:30 | eeevil | this won't address that, but start_pos is 0-based |
| 12:30 | paxed | yes, and i'm looking for the 2nd character. |
| 12:50 | eeevil | what does the following return for you? SELECT biblio.marc21_extract_fixed_field( $bibid, 'material'); -- replace $bibid with an appropriate bib id |
| 12:51 | eeevil | to purge material, UPDATE metabib.record_attr SET attrs = attrs - 'material'; |
| 12:51 | paxed | that returns just one char, correctly |
| 12:52 | eeevil | cool. so, I guess, purge and then reingest a couple records. then search for "material(x)" (no quotes, replace "x") to test |
| 12:52 | paxed | # UPDATE metabib.record_attr SET attrs = attrs - 'material'; |
| 12:52 | paxed | ERROR: Unexpected end of string |
| 12:53 | eeevil | maybe got smartquotes from cut/paste? |
| 15:07 | * rfrasur | prefers analog legos |
| 15:08 | eeevil | paxed: so, there's already a sophisticated 007 parser. what, in particular, are you trying to accomplish? SMD filtering, I believe? |
| 15:09 | paxed | eeevil: it started as a learning experience, now i'm just trying to get this working. SMD? what 007 parser? |
| 15:10 | kmlussier | dbs: Have you loaded the fixes from https://bugs.launchpad.net/evergreen/+bug/1155278 to your production server? I was using your catalog for comparison when testing a problem here, but then remembered you're not on 2.4 yet. |
| 15:10 | pinesol_green` | Launchpad bug 1155278 in Evergreen "TPAC: Accessibility audit compliance" (affected: 3, heat: 14) [Undecided,Fix released] |
| 15:11 | * kmlussier | wonders if there are any production systems using both 2.4 and auto suggest. |
| 15:11 | eeevil | 007/01 (second character in 007) is described as the SMD field for ... well ... it looks like all record types. http://www.oclc.org/bibformats/en/0xx/field007table.html (easier to read, IMO, than the LOC version) |
| 15:11 | kmlussier | Ooh! Looks like SC LENDS is. |
| 15:12 | paxed | eeevil: well, i usually read the marc21 format in finnish, so i wouldn't know/remember what "SMD" stands for. |
| 15:12 | dbs | kmlussier: our test server ( http://laurentian-test.concat.ca ) has that loaded - and I think I did apply it to our production server, but can't recall for sure |
| 15:13 | kmlussier | dbs: Ok, I'll look there too. Thanks! |
| 15:13 | eeevil | paxed: gotcha, fair enough. so, you were looking for the 007/01 on a particular record type originally, what was that type? |
| 15:14 | dbs | kmlussier: IIRC, autosuggest is a massive pain for accessibility; at least in our implementation, where Dojo dijits don't even make ARIA a viable option |
| 15:14 | fparks joined #evergreen | |
| 15:15 | eeevil | paxed: ok, so, where 007/00 = c, correct? |
| 15:15 | paxed | eeevil: so what filter gets the 007/01? yes |
| 15:16 | dbs | kmlussier: http://www-test.concat.ca/ is closer to stock than our LU skin |
| 15:16 | kmlussier | Yes, that's what I'm finding. C/W MARS modified their searchbar.tt2 based on your changes, but it still seems to be problematic in IE and Chrome. I'm not sure if was the problem with the way we patched it or if further work is needed. |
| 15:17 | * kmlussier | hasn't even looked at advanced search yet. :P |
| 15:17 | dbs | kmlussier: I couldn't easily fix the problem that autosuggest introduces, so I didn't |
| 15:21 | kmlussier | dbs: This morning, I used Chrome's accessibility add-on and had no trouble. It may just be a JAWS issue, but, then again, JAWS has a big share of the market. |
| 15:21 | dbs | kmlussier: yeah, understood. I can't recall if I checked the recent Dojo version to see if that issue had been addressed |
| 15:23 | paxed | eeevil: ok, now how do i do a filter for any type of record, or do i have to make a different filter name for each type of record? |
| 15:23 | kmlussier | dbs: Thanks for the info. So it sounds like disabling java or using Firefox are some workarounds for the time being. I'll test try some tests with java disabled. |
| 15:23 | eeevil | dbs: I believe ARIA is surfaced much better in modern dojo's |
| 15:25 | eeevil | paxed: the values in 007/01 overlap across record types ("a" means different things based on 007/00), so the short answer is "yes, a filter per type". that being said, what you've been trying to do /should/ work, so figuring out why it's not would be good, because then you could do it with a single filter on 007/00 with a length of 2 |
| 15:26 | paxed | eeevil: com_smd should show in metabib.record_attr attrs, right? |
| 10:59 | _zerick_ joined #evergreen | |
| 11:00 | tspindler joined #evergreen | |
| 11:04 | Dyrcona | dbs: mens health doesn't match men's health on my catalog, either. |
| 11:04 | bshum | Well, I just tested that search on MVLC and SCLEND's catalogs and neither returned expected results |
| 11:05 | bshum | Oh, heh |
| 11:05 | dbs | Looks like your thinking that new QP might be playing a role might be a reasonable theory. I'm seeing the same difference on our 2.4 test server vs our 2.3 production server |
| 11:06 | dbs | Is SCLENDs on 2.4? |
| 11:06 | dbs | I assume MVLC is. |
| 11:06 | gmcharlt | dbs: yes |
| 11:08 | * bshum | goes off to file a bug |
| 11:08 | paxed | is it enough to insert into config.record_attr_definition and reingest, or do i have to do something else to get a new filter working? |
| 11:33 | paxed | huh. okay, that works. it just didn't work like i expected it to. |
| 11:34 | paxed | adding that filter, it seems to consider the whole 007 field, not the 007/1 |
| 11:46 | Ruth joined #evergreen | |
| 11:57 | jeff_ | drat. the perils of comparing json as strings? |
| 11:57 | jeff_ | # Failed test at t/09-Utils-JSON.t line 105. |
| 11:57 | jeff_ | # got: '{"__p":{"foo":"bar"},"__c":"osrfException"}' |
| 11:57 | jeff_ | # expected: '{"__c":"osrfException","__p":{"foo":"bar"}}' |
| 11:57 | jeff_ | (of course, run the test again and all's well) |
| 11:59 | Ruth | I had the same problem with roofing nails this morning. |
| 12:02 | mcooper joined #evergreen | |
| 12:05 | pinesol_green | [evergreen|Simon Hieu Mai] LP#1053074: Editimg MARC Fixed Fields jumps cursor to marc record - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=717a126> |
| 12:25 | ldwhalen joined #evergreen | |
| 12:35 | paxed | yeah, figured |
| 12:39 | mjingle joined #evergreen | |
| 12:55 | jeff_ | tests+- |
| 13:09 | mcarlson joined #evergreen | |
| 13:11 | mtcarlson joined #evergreen | |
| 13:13 | dbs | jeff_: maybe set $json->canonical(true) to ensure the keys are ordered |
| 13:14 | dbs | assuming that json::xs is in play |
| 13:15 | * dbs | hasn't been able to get that test to fail |
| 13:15 | jeff_ | yeah. it might be a perl 5.18 thing. i'm seeing similar with some XML tests for RPC::XML |
| 13:16 | jeff_ | or, might be that i've fallen back to the pure perl json backend. i should check. |
| 13:16 | dbs | mmm, yeah, perl 5.16 here |
| 13:16 | jeff_ | and dbs++ for $json->canonical(true) -- i thought there was an option for that but had not gone looking. |
| 13:17 | StephenGWills joined #evergreen | |
| 17:05 | mjingle joined #evergreen | |
| 20:20 | serflog joined #evergreen | |
| 20:20 | Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org | |
| 20:21 | bshum | awitter++ mrpeters++ |
| 20:36 | b_bonner joined #evergreen | |
| 20:43 | mtcarlson joined #evergreen | |
| 20:46 | mcarlson joined #evergreen | |
| 22:03 | ktomita-mac joined #evergreen | |
| 22:16 | ldwhalen joined #evergreen | |
| 22:17 | kmlussier joined #evergreen | |
| 22:20 | * bshum | sighs loudly at acquisitions and EDI testing :( |
| 23:00 | pinesol_green | [evergreen|Pranjal Prabhash] Standalone Mode Staff Client Shortcuts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b55da92> |
| 23:00 | pinesol_green | [evergreen|Ben Shum] Added release note for standalone mode shortcuts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2060027> |
| 23:04 | bshum | Calling 0794 |
| 11:51 | dboyle joined #evergreen | |
| 11:53 | tsbere | b_bonner: Dunno if it has anything to do with your error.....but why the subselect? The where and limit clauses should, in theory, work on the update statement directly |
| 11:53 | jdouma joined #evergreen | |
| 11:56 | b_bonner | tsbere: subselect was just wanting to limit the query to the bib id's that actually have this 856 condition and the limit was just a remnant of me doing smaller scale tests. |
| 11:57 | jeff_ | b_bonner: sounds like your error is related to an existing issue with one or more bibs. doing a straight-up reingest of the bib without changing a thing in the marc record would likely trigger the same error. |
| 11:57 | tsbere | b_bonner: The where clause checking position would work on the update statement itself to do the same limit, though |
| 11:58 | jeff_ | b_bonner: you could add RAISE DEBUG statements (or their perl equiv) to the relevant functions in the db to surface the ID of the record(s) causing the issue. |
| 12:16 | paxed | yeah, just noticed that |
| 12:16 | phasefx | gathered at login time |
| 12:18 | b_bonner | jeff_ tsbere: sorry for delay getting back to this. I'll attempt to figure out which ID's are throwing the errors. Does this mean that these ids probably aren't indexed properly now? |
| 12:19 | jeff_ | eeevil: thanks. in that case, it would be good to test the effective client_min_messages for DBI, and ensure that whatever chosen could be logged without tripping up dbd::pg. |
| 12:19 | eeevil | b_bonner: it might mean that your update isn't doing what you expect. or it might mean that you've changed settings on some index defs |
| 12:20 | eeevil | jeff_: of course, it might be fine today. I ran into that long ago |
| 12:20 | jeff_ | eeevil: good to know that it might be an issue, even if it turns out not to be. |
| 12:32 | jeff_ | b_bonner: but you can use full_rec to find the records to change. |
| 12:32 | * jeff_ | nods |
| 12:32 | b_bonner | jeff_ eeevil: oh, sure. position wasn't that bad actually. |
| 12:34 | bshum | Testing logger: i’m |
| 12:40 | jeff_ | @later tell berick i'm interested in your thoughts on bug 1187035 removing OpenILS::Utils::Editor -- you're the usual author on Editor/CStoreEditor |
| 12:40 | pinesol_green | jeff_: The operation succeeded. |
| 12:40 | jeff_ | bug 1187035 |
Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139