Evergreen ILS Website

IRC log for #evergreen, 2014-12-01

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:31 wsmoak joined #evergreen
06:31 wsmoak joined #evergreen
06:33 phasefx joined #evergreen
07:34 rjackson-isl joined #evergreen
07:41 sarabee joined #evergreen
07:53 jboyer-isl joined #evergreen
08:13 collum joined #evergreen
08:21 akilsdonk joined #evergreen
08:30 Shae joined #evergreen
08:30 graced joined #evergreen
08:32 sbrylander joined #evergreen
08:39 maryj joined #evergreen
08:44 mmorgan joined #evergreen
08:47 mrpeters1 joined #evergreen
09:11 ericar joined #evergreen
09:18 kmlussier joined #evergreen
09:20 Stompro joined #evergreen
09:21 wsmoak joined #evergreen
09:29 yboston joined #evergreen
10:33 TaraC joined #evergreen
10:45 mrpeters1 has anyone else encountered missing DVD format icons in 2.7.1?
10:45 mrpeters1 they are OK in master, but only VHS seems to work in 2.7.1
10:46 mrpeters1 ah, and blu-ray as well
10:47 mrpeters1 007$vd cvaizu for example --- no DVD format icon in 2.7.1 -- same record in master has the DVD icon
10:48 bshum And you're sure the bib was reingested properly?
10:51 dreuther joined #evergreen
10:52 mllewellyn joined #evergreen
10:52 mrpeters i know a reingest was performed...though i could try and reingest just this one record for kicks
10:55 mrpeters now i can say for certain, yes, it has been reingested
10:58 bshum Just checking. :)
10:58 bshum I'm not sure why it would behave differently.
10:58 bshum And I'm not a cataloger enough to read that 007 tag properly
10:59 mrpeters i learned all about it with the new helper in 2.6
10:59 bshum To know whether it fits the definition.
10:59 mrpeters position 4 (the second "v") indicates that it is a DVD
10:59 mrpeters s = bluray
11:00 mrpeters b = VHS
11:00 bshum And what is your icon definition?
11:00 bshum For dvd
11:00 mrpeters there is a nice dropdown menu in the marc edit
11:01 mrpeters where is that configured?  coded value maps has v,g code for DVD Videorecording format
11:06 bshum mrpeters: I think it's related to config.composite_attr_entry_definition
11:07 bshum mrpeters: http://pastie.org/9754326
11:07 bshum For example, would get you those two tables connected to each other
11:07 mrpeters ok, yeah, i was just looking at config.coded_value_map
11:07 bshum Our DVD definition is like: [{"_attr":"vr_format","_val":"g"},​{"_attr":"vr_format","_val":"v"}]
11:07 bshum So I think that fits what you said, v and g
11:08 mrpeters same here
11:09 mrpeters http://pastie.org/9754329
11:09 mrpeters i wonder why that val:g is playing in
11:10 bshum Ours is adjusted I think
11:11 mrpeters i need to see what master has
11:11 bshum Ah, yeah
11:11 bshum laserdisc
11:11 bshum That's local to us
11:12 mrpeters yeah master shows the same as I have in 2.7.1
11:12 bshum Most of our database's so-called laserdisc bibs are actually DVDs
11:13 bshum For the bib record you're testing, what do the record_attr show up with?
11:13 bshum Like uh...
11:13 bshum SELECT * FROM metabib.record_attr_flat WHERE id = XXXXX
11:14 bshum Is there anything in there for icon_format, vr_format, etc.?
11:15 mrpeters interesting, nothing
11:15 bshum Nothing at all?
11:15 RoganH joined #evergreen
11:15 bshum Was the bib deleted and then undeleted maybe
11:16 * bshum looks in launchpad for something, this is sounding familiar...
11:16 mrpeters id= the record id right?
11:16 bshum Right
11:16 bshum https://bugs.launchpad.net/evergreen/+bug/1091885
11:16 pinesol_green Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed]
11:17 bshum Maybe
11:17 mrpeters weird so this bib is 5556118
11:17 mrpeters no rows in that table for anything > 5556118 either
11:17 bshum mrpeters: That is a view
11:17 mrpeters ah.
11:18 bshum And you should have many entries if the bib was reingested properly.
11:18 bshum But it might be borked
11:18 bshum Check the bug I linked to, where reingest fails due to the bib having been deleted, then undeleted.
11:18 mrpeters wow, only 3,113
11:18 mrpeters in that view
11:18 bshum Uh
11:18 mrpeters and this is for PINES
11:19 bshum That's not normal sounding at all.
11:19 berick concerto has 3709 in that view
11:19 mrpeters yeah....this is a test system, but i need to go check production too
11:19 bshum For me, a given bib gets like 15 entries or so at least, if not more.
11:19 mrpeters yeah, number is obsurdly low
11:19 bshum So multiply that times 1.5 bibs and that's unviewable
11:20 bshum So it sounds like something isn't ingesting right on your database.
11:20 mrpeters yep
11:20 mrpeters csharp: you following?
11:21 mrpeters is that a fairly new view?
11:21 mrpeters (not in 2.5)
11:21 kmlussier It's new in 2.6
11:21 mrpeters thanks kmlussier -- that explains why its not in production
11:21 mrpeters and probably why it didnt get populated properly during upgrade
11:21 bshum Right, this is MVF/CRA changes that came about in 2.6
11:22 mrpeters need to go back and look at the 2.6 upgrade scripts and see if something was missed
11:22 bshum mrpeters: How much stuff is in your metabib.record_attr_vector_list  table?
11:22 bshum (that's the real table, the other views are just making that stuff more readable to things)
11:23 mrpeters evergreen=# SELECT count(*) FROM metabib.record_attr_vector_list;
11:23 mrpeters -[ RECORD 1 ]--
11:23 mrpeters count | 1827179
11:23 bshum Hmm
11:23 mrpeters maybe the view just needs to be rebuilt
11:24 bshum Does that bib ID have an entry in metabib.record_attr_vector_list ?
11:25 bshum source on that table references the bib ID
11:25 bshum So, SELECT * FROM metabib.record_attr_vector_list WHERE source = bib_id;
11:25 mrpeters indeed it does
11:25 mrpeters evergreen=# SELECT *  FROM metabib.record_attr_vector_list WHERE source=5556118;
11:25 mrpeters -[ RECORD 1 ]-------------------------​--------------------------
11:25 mrpeters source | 5556118
11:25 mrpeters vlist  | {192,-2956,-558,-252,106,-15​17,-1060,181,-17,-1376,472}
11:28 bshum Then that's super strange then
11:28 bshum I would double check the view definitions
11:29 bshum metabib.record_attr for example, used to be a table, but it's now a view.
11:31 mrpeters http://pastie.org/9754372
11:31 mrpeters looks good compared to my master box
11:32 csharp mrpeters: I'll have to catch up with this later - my head's down on something time sensitive
11:32 csharp bshum: thanks for assisting!
11:32 mrpeters ok
11:32 mrpeters sounds like we just have a messed up view
11:33 mrpeters to make it short and sweet
11:33 mrpeters records are fine
11:33 dbwells mrpeters: what does the def for metabib.record_attr_flat look like for you?
11:33 csharp does anyone recall where the mapping table for group penalty thresholds is?
11:33 csharp doesn't appear to be in config. or in actor., so I'm at a loss :-/
11:33 bshum csharp: For users or the penalties themselves?
11:33 mrpeters dbwells: http://pastie.org/9754372
11:34 csharp bshum: not for each user - just the threshold definitions
11:34 bshum csharp: I think it's in permission
11:34 bshum permission.grp_penalty_threshold
11:34 csharp bshum++ # that's it!  thanks
11:39 bshum Yeah I'm confused.  I can't see why if there is an entry for the bib in the full vector_list table, why the view doesn't show that bib's information when selecting from it.  It should put together things from the vector_list with the corresponding coded value maps and uncontrolled list by IDs and spit back out information.
11:41 * bshum has to wander off to another project first, but will revisit this again later...
11:41 mrpeters yeah ill keep digging
11:46 dbwells mrpeters: Does this return anything for you?  http://pastie.org/9754392
11:48 mrpeters it does not
11:48 mrpeters wait, wrong tab
11:48 mrpeters yeah, 4 rows
11:48 mrpeters audience, bib_level, item_lang, item_type
11:49 dbwells mrpeters: And this still returns nothing? : SELECT * from metabib.record_attr_flat where id = 5556118;
11:53 mrpeters no, wth now it does
11:54 mrpeters but still no i con
11:54 mrpeters *icon
11:54 mrpeters http://next.gapines.org/eg/opac/results?query=bl​uray+item_type%28g%29&qtype=keyword&fi%3​Asearch_format=&locg=1&_adv=1&page=0
11:54 mrpeters Lady and the Tramp
11:54 dbwells mrpeters: Well, I guess the good news is your problem just got less interesting :)
11:55 mrpeters haha
11:55 dbwells I am guessing the last query you did didn't have a line for 'icon_format'
11:55 dwn joined #evergreen
11:57 mrpeters perhaps - this is so weird though
11:58 wjr joined #evergreen
11:59 buzzy joined #evergreen
11:59 mrpeters so, metabib.record_attr_flat should have a row for attr=icon_format?
11:59 dbwells could you pastie the output for SELECT * from metabib.record_attr_flat where id = 5556118;   ?
11:59 mrpeters yeah
12:00 mrpeters http://pastie.org/9754409
12:03 dbwells mrpeters: It's hard to say for sure what is going on, but you don't have 'vr_format' (you should), and the icon is based on that.  So I'd start with trying to determine why vr_format isn't getting a value, and go from there.
12:04 mrpeters interesting.  ok, thanks for the insight
12:09 jihpringle joined #evergreen
12:12 dbwells mrpeters: I gotta run in a minute or two.  Does this return a row for you?  :   select * from config.coded_value_map where ctype = 'vr_format' and code = 'v';
12:12 mrpeters it doesnt
12:12 mrpeters clearly, something missed in an upgrade
12:12 mrpeters im going to go digging through the 2.6 upgrade, especially
12:12 dbwells What about this?  select * from config.coded_value_map where ctype = 'vr_format';
12:13 mrpeters ah, here is why that returned nothing
12:13 mrpeters its vr_format = 'v,g'
12:13 dbwells Ah.  That looks like some local hackery.
12:14 mrpeters but g is also found in "Other Formats"
12:14 mrpeters so that may be causing the confusion too
12:14 dbwells Some folks (I think us included), mangled that table to make the OPAC work a certain way when filtering.
12:15 mrpeters could be, im going to flip it back to just V and see what happens
12:15 dbwells Or maybe it was a different, related table.
12:15 dbwells Yes, if you set it back to 'v' and reingest that record, you should at least get a vr_format, and that might fix the others.
12:18 mrpeters score!
12:21 mrpeters same thing bshum mentioned, g is laserdisc, so i bet they tried to combine at one time
12:22 mrpeters and since laserdisc is not opac visible, they probably coudlnt find their laserdisc items
12:23 mrpeters but i'd like to see someone stuff a laserdisc into their dvd player :P
12:24 jeff we circulated laserdisc for a very long time.
12:24 jeff then when we finally stopped, we had a big sale.
12:24 mrpeters they are like gold for music videos
12:24 jeff even had a few CEDs in the sale
12:24 mrpeters if labels didn't send out U-matics (I collect them for certain artists) laser disc was an even better score
12:25 jeff (i almost suspect that those came in as donations and were never added to the collection)
12:25 mrpeters what i think has happened, is that some older items are cataloged as "videodiscs" but are actually dvds
12:25 mrpeters 007vd cgaizu
12:26 mrpeters but it is actually a very early DVD
12:27 dbwells mrpeters: You could probably follow on with what bshum did, i.e. [{"_attr":"vr_format","_val":"g"},​{"_attr":"vr_format","_val":"v"}] for the various 'DVD' defs.
12:29 mrpeters indeed
12:30 mrpeters but should probably determine if people still have laserdiscs or not
12:30 mrpeters dont want a laserdisc showing up as a dvd, and vice versa
12:50 bshum dbwells++ # finding the problem
12:55 mrpeters yes, thank you bshum++ dbwells++
13:01 nhilton joined #evergreen
13:09 tspindler joined #evergreen
13:11 tspindler I am wonderg if someone can tell me what this global flag does precisely "Historical Circulations are kept for global retention age at a minimum, regardless of user preferences" when set to True
13:19 berick tspindler: for example, if you have a history.circ.retention_age of "1 year", then this setting ensures you will never delete (anonymize) circs younger than one year old, regardless of any conflicting user preferences.
13:22 tspindler berick: thanks, I am not aware of user preferences that can affect retention other than retaining checkout history
13:27 berick the settings are a more fine-grained in the DB.  retaining history is really a start-date, instead of just begin on or off.
13:27 berick similarly, there's a keep age (e.g. keep the last 6 months), which may not  be accessible in the catalog
13:27 berick but either could, theoritically, conflict with the global keep age
13:31 tspindler berick: thanks, that makes sense
13:54 csharp tsbere: around?  I have a hold policy question :-)
13:55 tsbere csharp: I am around-ish.
13:56 csharp tsbere: ok - I have a hold policy that from my analysis of the weights/exponents calculations should be "winning" but isn't
13:56 * csharp prepares a paste
13:57 bshum Holds, lawl
13:57 nhilton_ joined #evergreen
14:02 sandbergja joined #evergreen
14:06 csharp tsbere: nevermind - I think I found the problem
14:10 berick dbwells++ # cstore fine gen
14:10 kmlussier dbwells++
14:12 nhilton joined #evergreen
14:18 csharp tsbere: is there any already developed way to "see in" to the calculated score for each hold rule?
14:18 tsbere csharp: Given that the score can depend on a lot more than just the hold rule itself....not really.
14:18 csharp from my manual calculations, my new, more specific rule should be winning over the older one
14:19 * csharp will look into adding debugging statements
14:38 csharp tsbere++ # holds help
15:14 jboyer-isl csharp, I won't profess to know it inside or out, but if you're still in need of assistance or a rubber duck for hold policy settings I'll volunteer.
15:15 jboyer-isl I *almost* enjoyed setting them up for us.
15:20 dario joined #evergreen
15:22 csharp jboyer-isl: thanks - I figured it out.  In our case disabling circ.holds.usr_not_requestor in config.global_flag allowed my hold policy to work
15:22 csharp s/I figured it out/tsbere figured it out for me/
15:23 csharp however, in the process of troubleshooting, I have a much better idea of how the scores are calculated
15:24 jboyer-isl So does that mean you were trying to get holds placed by staff to act differently than holds placed by patrons?
15:24 dreuther_ joined #evergreen
15:24 csharp I was trying to have a rule be true for the user whether or not that user was also the requestor
15:25 jboyer-isl I see.
15:36 nhilton_ joined #evergreen
15:49 nhilton joined #evergreen
16:01 nhilton_ joined #evergreen
16:12 kmlussier remingtron: In preparation for Friday, I was thinking we might add the section titles that need to be documented to http://evergreen-ils.org/dokuwiki/d​oku.php?id=evergreen-docs:webclient and have people sign up for a particular section. Is that what you were thinking?
16:16 tspindler left #evergreen
16:20 nhilton joined #evergreen
16:22 phasefx__ joined #evergreen
16:35 nhilton_ joined #evergreen
16:39 nhilton joined #evergreen
16:39 dario left #evergreen
16:47 remingtron kmlussier: sure, sounds great!
16:47 kmlussier remingtron: OK, I'm working on it now.
16:47 edoceo joined #evergreen
16:48 remingtron kmlussier++
16:48 kmlussier I spent a lot of time in the web client a month ago, so I'm also adding notes as I go along on things that are not yet ready to document or ideas for adapting some of the docs.
16:55 jeff (only half joking) desired new feature: prompt for confirmation any time a money/currency input field contains 14 digits with a valid checksum.
16:56 kmlussier +1
16:57 mmorgan also when setting number of copies of a receipt to print ;-)
16:57 tsbere jeff: How about more than 5 digits period? I don't want to think about the number of partial scans we get. :P
16:59 jeff yeah, "require confirmation on values > X" where X defaults to 100 is more what I was actually thinking, humor aside. :-)
17:00 jeff I'd like to avoid adding another click/hurdle for every transaction, since many times ther's no confirmation desired/needed.
17:00 kmlussier left #evergreen
17:04 jeff but that one time when someone hands over fourteen trillion dollars in change, man... ;-)
17:09 mmorgan left #evergreen
17:20 nhilton_ joined #evergreen
17:43 bshum joined #evergreen
18:03 sarabee joined #evergreen
18:11 nhilton joined #evergreen
19:11 dreuther joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat