| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:44 |
|
tlittle joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:49 |
|
rlefaive joined #evergreen |
| 08:17 |
|
collum joined #evergreen |
| 08:20 |
|
kmlussier joined #evergreen |
| 08:42 |
rhamby |
good morning green people |
| 08:42 |
|
_adb joined #evergreen |
| 08:43 |
kmlussier |
rhamby: Good morning! |
| 08:43 |
* kmlussier |
isn't feeling particularly green today. |
| 08:44 |
_adb |
kmlussier: would a cat help? https://i.imgur.com/ydmUht6.gifv it isn't very green, but it is fuzzy. |
| 08:44 |
|
rlefaive joined #evergreen |
| 08:45 |
kmlussier |
_adb: A cat always helps! |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:45 |
_adb |
:-) |
| 08:50 |
kmlussier |
Or a dog, even. https://imgur.com/yXHLZeb |
| 08:54 |
collum |
How about a baby hippo? https://imgur.com/gallery/04r0jSK |
| 08:56 |
* _adb |
likes this game |
| 08:58 |
_adb |
hedgehog: https://i.imgur.com/rxOuun6.gifv |
| 09:01 |
kmlussier |
sea otter: https://imgur.com/gallery/PVOXWfq |
| 09:04 |
|
Dyrcona joined #evergreen |
| 09:32 |
|
yboston joined #evergreen |
| 10:09 |
|
jvwoolf joined #evergreen |
| 10:20 |
|
jvwoolf left #evergreen |
| 10:23 |
|
jvwoolf joined #evergreen |
| 10:23 |
|
rlefaive joined #evergreen |
| 11:23 |
Dyrcona |
So, the point releases are on for today? |
| 11:24 |
* Dyrcona |
asks because he's planning to upgrade to 2.12.8 from 2.12.6 next week and would like to test it tomorrow. :) |
| 11:24 |
Dyrcona |
If it speeds things up, I could help build a tarball. |
| 11:42 |
Dyrcona |
Hmm... 2.12.6 to 3.0.0 db upgrade threw this: |
| 11:42 |
Dyrcona |
psql:Open-ILS/src/sql/Pg/version-upgrade/2.12.6-3.0.0-upgrade-db.sql:6803: ERROR: column "display_field" does not exist LINE 2: ...AY_AGG(id)::INT[] FROM config.metabib_field WHERE display_fi... |
| 11:43 |
* Dyrcona |
thinks something earlier blew up.... |
| 11:44 |
|
dwgreen joined #evergreen |
| 11:45 |
* kmlussier |
totally forgot it was a release day. |
| 11:45 |
jeff |
seems likely. |
| 11:46 |
* Dyrcona |
is restoring from a dump again and will retry later. |
| 11:47 |
Dyrcona |
I did kinda run it twice, cause some query outputs stuff to the pager, so I canceled and started again. |
| 11:47 |
Dyrcona |
So, probably my fault. |
| 11:48 |
Dyrcona |
I think we should either avoid queries that will activate the pager or set the pager to off in db upgrade scripts. |
| 11:49 |
* Dyrcona |
goes to get some lunch. |
| 11:56 |
jeff |
adjusted milestone/etc on bug 1734963 for 3.0.2 (it was targeting 3.1 beta) |
| 11:56 |
pinesol_green |
Launchpad bug 1734963 in Evergreen "web client: copy template converter doesn't work for older templates" [Medium,Confirmed] https://launchpad.net/bugs/1734963 |
| 12:03 |
pinesol_green |
[evergreen|Chris Sharp] LP#1734963: Teach copy template converter about older templates. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=124f0ff> |
| 12:03 |
jeff |
and now i'm wondering if i should have paired that with a test. :P |
| 12:08 |
* kmlussier |
adds https://bugs.launchpad.net/evergreen/+bug/1671856 to the next dev meeting agenda. |
| 12:08 |
pinesol_green |
Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New] |
| 12:08 |
kmlussier |
I hate seeing code sit just because we haven't reached a consensus. |
| 12:22 |
* jeff |
trolls bugs looking for examples/use cases |
| 12:22 |
jeff |
s/bugs/billing bugs/ |
| 12:34 |
ejk |
Hi all, I've got an OpenSRF question: Any way to retrieve a biblio record through an OpenSRF API call that includes the MARC record? |
| 12:34 |
ejk |
I've found open-ils.search.biblio.record_entry.slim.retrieve but that strips the MARC, and there's some data I'm trying to look at that appears to only be stored in the MARC record. |
| 12:34 |
kmlussier |
jeff: That may be the only example. :) |
| 12:37 |
|
jihpringle joined #evergreen |
| 12:38 |
Dyrcona |
ejk: open-ils.pcrud.retrieve.bre <authtoken> <bibilio.record_entry.id> |
| 12:38 |
jeff |
ejk: you can get the MARC record via HTTP through a URL like: https://catalog.example.org/opac/extras/supercat/retrieve/marcxml/record/12345 |
| 12:38 |
Dyrcona |
or that. ;) |
| 12:38 |
jeff |
or what Dyrcona suggested, which will give you a JSON payload containing the biblio.record_entry object |
| 12:39 |
jeff |
(including a "marc" field with the marcxml of the record. |
| 12:39 |
jeff |
) |
| 12:39 |
Dyrcona |
And the marc is in the marc field. |
| 12:39 |
Dyrcona |
:) |
| 12:39 |
ejk |
Thanks! I'll try the pcrud call. |
| 12:40 |
Dyrcona |
I think there are other ways, but pcrud came to mind first. |
| 12:40 |
ejk |
I'l going through the HTTP gateway, but I'm hoping that will work |
| 12:40 |
jeff |
it also appears that bre is enabled for anonymous pcrud retrieval. |
| 12:40 |
Dyrcona |
pcrud should work through the http gateway. |
| 12:41 |
jeff |
if you are updating a MARC record via the gateway, you may run into issues depending on how your user agent handles encoding of spaces. |
| 12:41 |
jeff |
old APR issue, iirc. |
| 12:43 |
jeff |
anonymous pcrud for object classes that support it is performed by passing "ANONYMOUS" as the auth token. |
| 12:43 |
ejk |
Boom! Worked. Already have an auth token from other calls that I'm making so should be good. |
| 12:44 |
jeff |
figured that might be the case, but keep it in mind for the future :-) |
| 12:44 |
ejk |
Just need to parse this XML schema but that shouldn't be hard. |
| 12:44 |
ejk |
We'll have some cool stuff to show off in a month if all goes right... |
| 12:44 |
jeff |
fun! |
| 12:44 |
ejk |
Thanks so much! Dyrcona++ jeff++ |
| 12:45 |
Dyrcona |
ejk: Is this written in Perl? |
| 12:45 |
ejk |
*cough* PHP *cough* |
| 12:45 |
Dyrcona |
OK. Never mind. I don't know any MARC frameworks in PHP. ;) |
| 12:45 |
Dyrcona |
If you want to switch to Perl, Python, or Java, though..... |
| 12:46 |
ejk |
jeff: I think I actually started this library based on your Opensrf PHP library from way back when; but it's been expanded quite a bit from there. |
| 12:47 |
jeff |
good. mine was incomplete garbage. ;-) |
| 12:49 |
Dyrcona |
Speaking of MARC.....We have a record that shows nothing in the View MARC window, but shows up OK if you click the display MARC link in the OPAC. |
| 12:50 |
* Dyrcona |
wonders what is wrong... To the Batlogs! |
| 12:50 |
Dyrcona |
Oh. Now it works.... |
| 12:58 |
|
khuckins joined #evergreen |
| 13:13 |
|
rlefaive joined #evergreen |
| 13:33 |
|
hbrennan joined #evergreen |
| 13:45 |
|
tlittle joined #evergreen |
| 13:58 |
dbs |
ejk: Nothing wrong with PHP. File_MARC? |
| 14:00 |
ejk |
Was able to load the string into SimpleXMLElement for initial pass. Just need to look up which codes correspond to which fields |
| 14:03 |
ejk |
https://www.loc.gov/marc/bibliographic/bdsummary.html looks pretty comprehensive, just need to build a lookup for code => field name |
| 14:13 |
|
sandbergja joined #evergreen |
| 14:13 |
Dyrcona |
ejk: What fields are you looking for? Some have mappings stored in the Evergreen database. |
| 14:14 |
Dyrcona |
So, I'm having "fun" with the redirect from http to https for the web staff client. |
| 14:14 |
ejk |
Material Type code and Additional Authors were the two that I could only find in the MARC record |
| 14:14 |
Dyrcona |
It works fine on my Ubuntu 16.04 test vm, but I can't get it to work on training server with Debian 7. |
| 14:15 |
|
jvwoolf left #evergreen |
| 14:15 |
Dyrcona |
ejk: There are tables with mappings to get values from MARC, material type is one of them. |
| 14:17 |
Dyrcona |
You want to look at config.marc21_ff_pos_map. |
| 14:17 |
Dyrcona |
Here's an example in Perl of how it might be used: https://github.com/Dyrcona/evergreen_utilities/blob/master/perl/loaderecords.pl#L359 |
| 14:18 |
Dyrcona |
Added authors, you'll have to pull from the appropriate fields. |
| 14:18 |
Dyrcona |
@marc 700 |
| 14:18 |
pinesol_green |
Dyrcona: An added entry in which the entry element 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,x,3,4,5,6,8] |
| 14:18 |
Dyrcona |
And so on... |
| 14:21 |
ejk |
Any way I can get that table through an OpenSRF call? |
| 14:21 |
Dyrcona |
material type /might/ be in config.marc21_rec_type_map. I never can keep straight what material type is. |
| 14:21 |
ejk |
It's the 7th character of the leader |
| 14:21 |
pinesol_green |
[evergreen|Jason Boyer] LP1714390:Remove acp Editor Formatting Frustration - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=410dce9> |
| 14:21 |
ejk |
$leader[6] |
| 14:21 |
Dyrcona |
Oh, right, then, you don't need the table. |
| 14:21 |
ejk |
But might be helpful for the other fields |
| 14:21 |
Dyrcona |
I usually see that referred to as item type. :) |
| 14:22 |
Dyrcona |
ejk: What you could do is write some code to build a static look up table from the database and pop that into your code. |
| 14:23 |
jeff |
ejk: for some purposes, i extract that kind of thing by transforming the MARCXML to MODS -- the MODS XSLT from LoC is what many parts of the Evergreen ingest/index process use -- with some modifications in a few places. |
| 14:23 |
Dyrcona |
Those entries are based on the LoC MARC docs and almost never change. |
| 14:23 |
Dyrcona |
MODS would be handy for the authors, for instance. |
| 14:24 |
jeff |
ejk: some messy python is here that might give you a sense of how that works -- see the various XPATH bits in the indexes{} hash: https://github.com/tadl/marc-indexing-for-es |
| 14:24 |
jeff |
specifically, https://github.com/tadl/marc-indexing-for-es/blob/master/index.py#L70 |
| 14:25 |
jeff |
some of that data is stored in Evergreen in a way that you may be able to fetch without direct DB access, but in some cases only the normalized form is stored, not suitable for display. |
| 14:25 |
jeff |
some of that changes with the new display fields work in 3.x -- i don't have a firm grasp on the status of that right now. |
| 14:25 |
ejk |
Heh, that's funny I'm getting records ready to index in Elasticsearch |
| 14:26 |
jeff |
there's also logic in the TPAC templates for extracting (for display, not search) some of those fields from the MARCXML data itself. |
| 14:26 |
jeff |
hah! |
| 14:27 |
jeff |
well, that repo's what we're currently using for indexing to Elasticsearch. I don't like how much things are repeated in index.py, but... slow but steady. |
| 14:28 |
jeff |
I just finished going over some of the logic with wjr, as I'm making a few adjustments to it today -- making abstract and contents array values instead of just storing the first one, for example. |
| 14:28 |
jeff |
We're also using a relatively ancient version of Elasticsearch. Upgrading that is soon. |
| 14:29 |
jeff |
one place where you might want to pull the values from Evergreen is record attributes. let me see if that's exposed via pcrud. |
| 14:31 |
jeff |
yes, looks like it. mra and mraf. |
| 14:39 |
jeff |
open-ils.pcrud.retrieve.mra will give you item_type, icon_format, search_format, etc. |
| 14:39 |
jeff |
lit_form if applicable, all that. |
| 14:40 |
miker |
ejk: http://docs.evergreen-ils.org/reorg/3.0/integrations/_url_format.html may be relevant to your interests |
| 14:40 |
jeff |
oh, right -- another way to get things like mra. |
| 14:41 |
miker |
records directly in XML, in various formats (mods, etc) with holdings and attributes attached |
| 14:41 |
ejk |
Ah, cool. Been trying to do everything through OpenSRF but for strict reads might be easier to get another format |
| 14:46 |
miker |
there's a supercat app you can get to via opensrf, but for plain retrieval when you have XML tools, unapi may be simpler to maintain. less likely to change, since it's meant for external integration, too |
| 14:54 |
jeff |
yeah, don't feel like you're doing it "the wrong way" by making use of unapi over http. |
| 15:13 |
ejk |
miker: holy cow that's everything that I've been grabbing from multiple OpenSRF calls. Might take a bit to rewrite but certainly faster to grab with one call. Thanks |
| 15:23 |
miker |
ejk: :) ... relevant to your interests |
| 15:35 |
pinesol_green |
[evergreen|Dan Scott] 2nd level of bullets requires '**' - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a9667a> |
| 15:37 |
pinesol_green |
[evergreen|Alex Cautley] lp1705133 view holds patron info redaction - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44726c6> |
| 16:02 |
Dyrcona |
Back to what I said almost two hours ago about the HTTPS rewrite rule not working for /eg/staff/ on my training and production servers.... |
| 16:03 |
Dyrcona |
If I enable the global rule at the bottom of eg_vhost.conf, it works on training. (I've not tried on production.) |
| 16:03 |
Dyrcona |
However, the rewritecond and rewriterule for location /eg/staff/ do not work. I get a 403 Forbidden error. |
| 16:04 |
Dyrcona |
If I remove the SSLRequireSSL in that block, I get a nice, non-encrypted connection to the web staff client that doesn't really work because no port 7680.... |
| 16:04 |
jeff |
Dyrcona: symptoms are slightly different, but you don't have "staff" in your hostname anywhere, do you? |
| 16:05 |
Dyrcona |
jeff: No, I don't. |
| 16:05 |
Dyrcona |
Nor, eg. |
| 16:05 |
Dyrcona |
training.cwmars.org |
| 16:06 |
Dyrcona |
As I mentioned earlier, everything works just fine on a test vm..... :( |
| 16:06 |
Dyrcona |
I did find some mess in the apache2-websockets directory on training, but the behavior is not improved after cleaning that up. |
| 16:10 |
Dyrcona |
I get the same results on production as I do on training, but I've not experimented with configuration there. |
| 16:17 |
Dyrcona |
So, are releases happening today? |
| 16:18 |
dbwells |
Dyrcona: wheels are turning, at least |
| 16:18 |
Dyrcona |
dbwells: Cool! |
| 16:41 |
pinesol_green |
[evergreen|Ben Shum] Docs: fix list item index in basic_holds.adoc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=99e7c52> |
| 17:03 |
|
mmorgan left #evergreen |
| 17:11 |
|
jvwoolf joined #evergreen |
| 17:18 |
|
jvwoolf1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 18:52 |
|
rlefaive joined #evergreen |
| 22:19 |
ejk |
@marc 880 |
| 22:19 |
pinesol_green |
ejk: The fully content-designated representation, in a different script, of another field in the same record. Field 880 is linked to the associated regular field by subfield $6 (Linkage). The first and second indicator positions in field 880 have the same definition and values as the indicators in the associated field. The subfield codes in field 880 are the same as those defined in the associated (1 more message) |
| 22:19 |
ejk |
@more |
| 22:19 |
pinesol_green |
ejk: field except for subfield $6. The data in field 880 may be in more than one script. (Repeatable) [6] |
