| Time |
Nick |
Message |
| 03:00 |
|
beanjammin joined #evergreen |
| 03:02 |
|
rlefaive joined #evergreen |
| 03:07 |
|
rlefaive joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:59 |
|
agoben joined #evergreen |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:55 |
|
bdljohn joined #evergreen |
| 07:56 |
|
Dyrcona joined #evergreen |
| 08:03 |
|
kmlussier joined #evergreen |
| 08:05 |
kmlussier |
@later tell bshum You can customize the color of the YAOUS mug when you order it. You can even change the text so that it says YAOUS++ or something like that. |
| 08:05 |
pinesol_green |
kmlussier: The operation succeeded. |
| 08:05 |
* kmlussier |
wishes she had changed it to say YAOUS++ |
| 08:07 |
Dyrcona |
:) |
| 08:07 |
Dyrcona |
Sometimes, I think we have too many. |
| 08:07 |
* kmlussier |
disappears to the French Quarter. |
| 08:08 |
Dyrcona |
Well, OK. Most of the time I think we have too many settings, so no incr from me. :) |
| 08:26 |
|
lsach joined #evergreen |
| 08:37 |
rhamby |
kmlussier: just order another |
| 08:41 |
|
collum joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:48 |
|
idjit joined #evergreen |
| 09:09 |
|
terran joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 09:41 |
|
stephengwills joined #evergreen |
| 10:54 |
|
stephengwills left #evergreen |
| 11:10 |
|
beanjammin joined #evergreen |
| 11:16 |
|
Christineb joined #evergreen |
| 11:21 |
|
stephengwills joined #evergreen |
| 11:40 |
|
khuckins joined #evergreen |
| 11:49 |
|
krvmga joined #evergreen |
| 12:31 |
|
jihpringle joined #evergreen |
| 12:45 |
Dyrcona |
typos-- |
| 12:45 |
Dyrcona |
@karma typos |
| 12:45 |
pinesol_green |
Dyrcona: Karma for "typos" has been increased 0 times and decreased 1 time for a total karma of -1. |
| 12:45 |
Dyrcona |
@karma typoes |
| 12:45 |
pinesol_green |
Dyrcona: typoes has neutral karma. |
| 13:36 |
|
bdljohn joined #evergreen |
| 14:09 |
|
rsulejmani joined #evergreen |
| 14:09 |
rsulejmani |
help can I install EvergreenILS on Ubuntu Bionic |
| 14:09 |
rsulejmani |
I have already installed OpenSRF |
| 14:11 |
Dyrcona |
rsulejmani: It doesn't work on Bionic Beaver, yet. There are problems with OpenSRF and ejabberd. Were you able to successfully test OpenSRF on Bionic? |
| 14:11 |
rsulejmani |
Yes |
| 14:11 |
Dyrcona |
Really? Because I've not been able to make it run successfully. |
| 14:12 |
rsulejmani |
I have installed it and it works. May I ask how do you test it? |
| 14:12 |
Dyrcona |
You were able to start the OpenSRF services, connect with srfsh, and run the opensrf.math add test? |
| 14:12 |
Dyrcona |
It's in the README. |
| 14:12 |
Dyrcona |
There are also some tests you can run. |
| 14:14 |
Dyrcona |
If you cd ~/OpenSRF/src/perl && make check |
| 14:15 |
Dyrcona |
In all honesty, I've not tried to get it working on bionic more than once because I've not had the time. |
| 14:16 |
rsulejmani |
Yeah its not working |
| 14:16 |
|
yboston joined #evergreen |
| 14:16 |
Dyrcona |
I recommend using xenial for now. |
| 14:16 |
rsulejmani |
Ok |
| 14:17 |
Dyrcona |
If you want to figure out how to get it working on bionic, by all means, go ahead and submit patches. :) |
| 14:17 |
Dyrcona |
But, I don't think it's going to be easy this time. |
| 14:17 |
Dyrcona |
I think we need to add SASL authentication for xmpp to OpenSRF. |
| 14:17 |
rsulejmani |
ok |
| 15:02 |
jeffdavis |
The fix for bug 1743801 modifies fm_IDL.xml to change the circ_as_type field from text to link for asset.copy. I wonder if we should be making the same change for other classes that use the circ_as_type field, like serial.unit ? |
| 15:02 |
pinesol_green |
Launchpad bug 1743801 in Evergreen 3.0 "web client: item status list view display issues" [High,Confirmed] https://launchpad.net/bugs/1743801 |
| 15:03 |
Dyrcona |
Well, I wonder if that was the right move in the first place. |
| 15:05 |
Dyrcona |
circ_as_type has no FK relationship as far as I can tell. I know that's not technically necessary to make a link in the IDL, but.... |
| 15:05 |
idjit |
asset.copy_template circ_as_type is a link (type citm). also on config.hold_matrix_matchpoint marc_type. |
| 15:07 |
Dyrcona |
Right, but not in the database. |
| 15:07 |
Dyrcona |
So, the question is, should the IDL reflect the database and/or vice versa? |
| 15:09 |
Dyrcona |
FK = foreign key. So, I'm saying there are no foreign key constraints on the circ_as_type in the database, and so if there are links in the IDL, then the IDL and database would seem to disagree. |
| 15:09 |
jeffdavis |
I would guess there's no FK relationship because the field can be null. |
| 15:09 |
Dyrcona |
No, it's an open question in my mind whether the database and IDL should agree. |
| 15:09 |
idjit |
it's not established as a foreign key, but the possible values are in select * from config.coded_value_map where ctype='item_type'; |
| 15:10 |
idjit |
i thought i saw it elsewhere, too, but can't remember where... |
| 15:10 |
Dyrcona |
jeffdavis: You can make a FK relationship that allows nulls on either side. |
| 15:10 |
* mmorgan |
has often wondered why something like circ_as_type would not have a foreign key constraint in the database ... |
| 15:10 |
* Dyrcona |
wonders how much it is actually used. |
| 15:11 |
Dyrcona |
Doesn't *everyone* use circ modifiers? :) |
| 15:11 |
idjit |
select * from config.item_type_map -- they have their own table |
| 15:11 |
jeffdavis |
circ_modifier is another great example of a field that should have an FK relationship but doesn't |
| 15:12 |
jeffdavis |
nope, sorry, I'm wrong about that |
| 15:12 |
Dyrcona |
I wonder how useful the other fields in the config.circ_modifier table actually are. |
| 15:12 |
mmorgan |
age_protect seems like it should. |
| 15:13 |
miker |
idjit: well, citm entries have a view atop ccvm, which is why there's no fkey |
| 15:13 |
Dyrcona |
BTW, I've configure circ_as_type in another life so that documentary DVDs (g) could circ as books (a). |
| 15:14 |
Dyrcona |
But, other than past me, doesn't everyone just use circ mods? :P |
| 15:16 |
Dyrcona |
jeffdavis: To answer your first question: Probably. Maybe you should fly a Lp bug and see who salutes it? |
| 15:17 |
Dyrcona |
Or ask on the dev list. |
| 15:17 |
idjit |
miker: do you mean the foreign key can't be defined because the 'join' from asset.copy to config.coded_value_map involves two fields (code and c_type) instead of just one? |
| 15:17 |
miker |
Dyrcona: for the vast majority of copies, circ mod is a direct replacement for marc item type. it's unfortunate that we have all these standards and folks end up using /only/ the escape hatch (modifier) in the end :P |
| 15:18 |
Dyrcona |
miker: Yes, that's true in most installations. At MVLC that wasn't true, and I think it lead to some confusion on the part of library staff. |
| 15:19 |
miker |
idjit: right, there's no c_type equiv on the copy end. code by itself is not unique, so can't be the target of an fkey. this is a historical thing, citm (and others) used to be its own table before coded value maps existed |
| 15:19 |
idjit |
what about fkey-ing to config.item_type_map instead? |
| 15:19 |
miker |
idjit: that's a view, not a table |
| 15:19 |
idjit |
i see |
| 15:19 |
Dyrcona |
I think that's a legacy issue, too. Most sites coming to evergreen migrate from a system that has some kind of "item type" field that controls circ rules, so circ modifier seems like the natural equivalent. |
| 15:20 |
miker |
Dyrcona: indeed. "previous system syndrome" ;) |
| 15:21 |
* miker |
turns away from the path of ranting |
| 15:21 |
Dyrcona |
:) |
| 15:21 |
Dyrcona |
Yeah, I think we agree on something. :) |
| 15:22 |
idjit |
no ranting? how about a nice cat, then? https://i.imgur.com/RTsvI4M.gifv |
| 15:22 |
miker |
idjit: however, we don't have those distinctions in the idl (which is not responsible for referencial integrity, etc) so we can ad what you did in the patch |
| 15:24 |
idjit |
\o/ |
| 15:26 |
idjit |
but if we wanted, it could be done with an angular filter instead, similar to the fine level and loan duration. then the IDL and database schema agree, like Dyrcona was saying. |
| 15:27 |
Dyrcona |
Well, the IDL and db schema don't have to agree and I'm sure there are already places where they don't, so. |
| 15:27 |
miker |
we could, but I think it would be useful to be able to load the backing citm in the middle layer, too. and it could simply things like print templates |
| 15:28 |
Dyrcona |
I was just thinking out loud to provoke ideas from othres. |
| 15:28 |
miker |
and reports |
| 15:29 |
Dyrcona |
I tend to prefer consistency in such things, but it's not always a good thing. |
| 15:29 |
idjit |
if fleshable values are preferred for reports and receipts, would it be possible to add a couple "fake" classes so we can flesh the fine level and loan duration? get rid of the filter? |
| 15:30 |
Dyrcona |
idjit: Fake classes are called virtual classes and that can be done. |
| 15:31 |
idjit |
s/possible/preferable/ |
| 15:31 |
Dyrcona |
You can even embed SQL in the class definition. |
| 15:32 |
Dyrcona |
I would probably prefer the IDL changes over Angular filters, but I'm not fully informed of the trade offs in one versus the other. |
| 15:32 |
miker |
well, the angular filter gets existing i18n treatment |
| 15:33 |
miker |
IDL views (virtual classes in the IDL) don't, today |
| 15:33 |
idjit |
i18n treatment? |
| 15:33 |
miker |
but a (set of) tiny value tables could be marked for translation via the IDL |
| 15:34 |
Dyrcona |
idjit: i18n = internationalization, i.e. translations |
| 15:34 |
miker |
idjit: the l() calls you're using. that marks the short/normal/extended strings as translatable, and translates them when loading the TT2 where appropriate |
| 15:35 |
miker |
ah, sorry, I assumed acronym transparency :) |
| 15:35 |
idjit |
gotcha. didn't know the abbreviation |
| 15:35 |
Dyrcona |
l10n = localization |
| 15:35 |
Dyrcona |
Similar idea. |
| 15:46 |
idjit |
jihpringle: you around? regarding bug 1731272 (thank you for testing!), i'm having trouble replicating the problem with "View Holds". |
| 15:46 |
pinesol_green |
Launchpad bug 1731272 in Evergreen "web client: "Set default view" breaks record page loading" [High,Confirmed] https://launchpad.net/bugs/1731272 - Assigned to Galen Charlton (gmc) |
| 15:49 |
jihpringle |
hi idjit |
| 15:49 |
idjit |
did you try refreshing the page? did the problem continue? |
| 15:49 |
idjit |
hello! |
| 15:50 |
idjit |
and did you have the branch for 1743801 in place when you were testing 1731282? |
| 15:53 |
jihpringle |
idjit - I'd have to double check but I think I had 1743801 on my test server |
| 15:53 |
jihpringle |
I definitely had 1724348 applied as well |
| 15:54 |
idjit |
oh, sorry, that was a copy error on my part. i meant 1724348 |
| 15:55 |
jihpringle |
today when I test the progress bar appears briefly and then the page loads as expected |
| 15:55 |
jihpringle |
but the progress bar was definitely hanging around yesterday |
| 15:55 |
idjit |
did it make any difference how you got to the record? cataloging->"bib by record id" vs clicking title from copy status, for example? |
| 15:56 |
jihpringle |
it worked as expected consistently if I was opening the record from search results |
| 15:56 |
jihpringle |
I got the hung progress bar consistently if I middle clicked on the title in Item Status |
| 15:57 |
Dyrcona |
Why would you middle click on the title in Item Status? |
| 15:58 |
idjit |
good, thorough testing :-P |
| 15:58 |
idjit |
but that works for me... |
| 15:59 |
jihpringle |
Drycona: habit from the check in screen where if I left click (rather than middle click) the record opens in the same tab rather than a new tab |
| 16:01 |
jihpringle |
idjit: I just tried from Z39.50 Actions -> Show in Catalogue and I was able to reproduce the hanging progress bar |
| 16:02 |
|
khuckins joined #evergreen |
| 16:02 |
idjit |
bear with me here... what's a Z39.50 and how do i get one? |
| 16:03 |
jihpringle |
From the Cataloging menu you go to Import Record from Z39.50 |
| 16:03 |
Dyrcona |
Z39.50 is a standard for searching other library catalogs and retrieving records. |
| 16:04 |
|
yboston joined #evergreen |
| 16:05 |
jihpringle |
idjit: now that I've been able to replicate it, in answer to your earlier question clicking Refresh just reloads the page with the progress bar hung again |
| 16:09 |
idjit |
URL it is it trying? i haven't quite figured out this search form yet |
| 16:10 |
jihpringle |
the URL looks the same whether it work or not |
| 16:10 |
idjit |
hey, i got one! ok, i'll look into it |
| 16:11 |
jihpringle |
yay! |
| 16:11 |
idjit |
so far it looks like it's specific records that are unhappy. i'll see if i can find a pattern and get back to you. thanks! |
| 16:12 |
jihpringle |
idjit: thanks for these fixes! we're planning to go ahead and apply this one as is for now since the View Holds issue is so minor compared the original bug |
| 16:12 |
jihpringle |
idjit++ |
| 16:13 |
idjit |
and it doesn't matter how i load the record, but bib id 972 in concerto is repeatable for me. |
| 16:13 |
idjit |
jihpringle++ # good find. |
| 16:13 |
jihpringle |
the record that worked for me to today is the same one that didn't work yesterday |
| 16:13 |
idjit |
O_o |
| 16:14 |
idjit |
heisenbugs-- |
| 16:21 |
idjit |
looks like it's bib records that don't have any holds. |
| 16:22 |
idjit |
did a hold happen to get placed on your test record since yesterday? if not, might be some timing issues involved as well. |
| 16:22 |
|
stephengwills joined #evergreen |
| 16:24 |
|
bwicksall_ joined #evergreen |
| 16:27 |
jihpringle |
idjit: that's very possible |
| 16:33 |
jihpringle |
idjit: I can replicate this, if there are holds View Holds displays as expected, if there are no holds the progress bar hangs |
| 16:36 |
idjit |
jihpringle++ # excellent, thank you! i updated the bug to make a note of that. i'm looking into it, but not especially confident it'll be fixed today. will post on the bug if i figure anything out |
| 16:38 |
jihpringle |
idjit: awesome, thanks :) |
| 16:45 |
|
bwicksall_ joined #evergreen |
| 16:54 |
|
bwicksall_ joined #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:23 |
|
rlefaive joined #evergreen |
