| Time |
Nick |
Message |
| 04:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 05:49 |
|
b_bonner joined #evergreen |
| 05:49 |
|
mnsri_away joined #evergreen |
| 05:50 |
|
ericar joined #evergreen |
| 06:13 |
|
jonadab joined #evergreen |
| 06:13 |
|
tsbere joined #evergreen |
| 06:13 |
|
berick joined #evergreen |
| 06:13 |
|
Bmagic joined #evergreen |
| 06:13 |
|
pinesol_green joined #evergreen |
| 06:13 |
|
fbeaudry joined #evergreen |
| 06:40 |
|
JBoyer joined #evergreen |
| 07:13 |
|
rjackson_isl joined #evergreen |
| 07:24 |
|
agoben joined #evergreen |
| 07:58 |
|
rlefaive_ joined #evergreen |
| 08:16 |
|
agoben joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:48 |
|
bos20k joined #evergreen |
| 09:09 |
|
rlefaive joined #evergreen |
| 09:15 |
|
Dyrcona joined #evergreen |
| 09:19 |
|
jvwoolf joined #evergreen |
| 09:19 |
|
jvwoolf left #evergreen |
| 09:22 |
|
yboston joined #evergreen |
| 09:24 |
|
jvwoolf joined #evergreen |
| 09:25 |
Bmagic |
Wow! Lots of conversation late May28th |
| 09:25 |
Bmagic |
@coffee |
| 09:25 |
* pinesol_green |
brews and pours a cup of Ibonia Kenya Peaberry, and sends it sliding down the bar to Bmagic |
| 09:26 |
Bmagic |
Thanks @pinesol_green - my hero |
| 09:27 |
Bmagic |
I played Tyrants of the Underdark this weekend. A very fun game! |
| 09:28 |
Dyrcona |
I wish someone would program a ticket system so that a vacation/out of the office email will not reopen a ticket. |
| 09:28 |
Bmagic |
And in the Resistance category, I might have found a new one for us, Decpetion (https://boardgamegeek.com/boardgame/156129/deception-murder-hong-kong) |
| 09:29 |
Bmagic |
/Decpetion/Deception |
| 09:29 |
|
kmlussier joined #evergreen |
| 09:32 |
Dyrcona |
The other side of that coin is configuring your vacation/autoreply to not reply to bulk emails. |
| 09:32 |
|
maryj joined #evergreen |
| 09:32 |
|
Freddy_Enrique joined #evergreen |
| 09:39 |
Dyrcona |
Can I complain about Launchpad search while I'm at it? |
| 09:40 |
Freddy_Enrique |
Good Morinig Dyrcona |
| 09:40 |
Freddy_Enrique |
Hi guys |
| 09:41 |
Dyrcona |
Good morning! |
| 09:45 |
Freddy_Enrique |
Yesterday at night something happened. I couldn´t enter this chat. What I could see is that I was banned, well. My IP I guess |
| 09:45 |
Freddy_Enrique |
Any reasons why? |
| 09:46 |
Dyrcona |
Dunno. We don't control the chat servers. |
| 09:47 |
|
rlefaive joined #evergreen |
| 09:47 |
Dyrcona |
Connecting from certain, dynamic IP ranges, requires a different kind of authentication on the Freenode network. |
| 09:48 |
Dyrcona |
That would make more sense if I put my commas in the right places. :) |
| 09:48 |
Freddy_Enrique |
Now I can, but from my work |
| 09:48 |
Freddy_Enrique |
At home is a different matter |
| 09:48 |
Freddy_Enrique |
jajaja |
| 09:49 |
Dyrcona |
https://freenode.net/kb/answer/chat |
| 09:49 |
Dyrcona |
You probably need to configure SASL in your client. |
| 09:49 |
Dyrcona |
I have to do that when tethered from my cell phone, for instance. |
| 09:50 |
Freddy_Enrique |
Can I install weechat on my Windows OS? |
| 09:51 |
Freddy_Enrique |
I was told it is very popular |
| 09:51 |
csharp |
Bmagic: Deception looks fun ;-) |
| 09:55 |
Dyrcona |
Freddy_Enrique: I can't answer that question for you. |
| 09:57 |
Freddy_Enrique |
No problem Dyrcona :) |
| 09:58 |
Dyrcona |
:) |
| 10:00 |
pinesol_green |
[evergreen|Jason Boyer] LP1312824 open-ils.circ.hold.change_title fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=78620f6> |
| 10:00 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1312824: Change success message for transferred holds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9605ec5> |
| 10:00 |
pinesol_green |
[evergreen|Galen Charlton] LP#1312824: follow-up to fix whitespace - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7d2ca7> |
| 10:03 |
|
rlefaive_ joined #evergreen |
| 10:03 |
Freddy_Enrique |
Now to evergreen itself. Yesterday I finally entered the database via client and there are too many things to watch. Any tips where I should begin? |
| 10:05 |
kmlussier |
Freddy_Enrique: Did you load the Concerto test dataset into the database? |
| 10:07 |
kmlussier |
Freddy_Enrique: If not, you should probably start by cataloging records. It's difficult to do anything without some bibliographic records in the system. |
| 10:07 |
Freddy_Enrique |
Concerto test dataset? Not so sure what you mean. |
| 10:07 |
Freddy_Enrique |
So, first I should catalog some records |
| 10:08 |
csharp |
Bmagic: any further issues for A/T stuff? our utility server choked (apparently on "too many events") over the weekend killing pretty much everything else |
| 10:10 |
kmlussier |
Freddy_Enrique: It's a set of sample bibliographic and patron records that can be loaded on to a test system. http://evergreen-ils.org/documentation/install/README_2_12.html#_loading_sample_data |
| 10:11 |
Freddy_Enrique |
OMG |
| 10:12 |
Freddy_Enrique |
can I do this step after I started Evergreen? |
| 10:13 |
csharp |
(doesn't appear to have been cstore process proliferation causing our issue, btw) |
| 10:13 |
Bmagic |
csharp: Thanks for reminding me, I am going to run some queries and find out! |
| 10:15 |
Bmagic |
csharp: no more issues! |
| 10:15 |
csharp |
Bmagic: awesome |
| 10:15 |
berick |
Freddy_Enrique: yes, you should be able to add the concerto data while EG is running. |
| 10:16 |
berick |
Freddy_Enrique: something like: cd Open-ILS/tests/datasets/sql && psql -U evergreen -f load_all.sql |
| 10:16 |
Dyrcona |
Freddy_Enrique: I'd still shut it down, load the data, and then start Evergreen again. |
| 10:16 |
Bmagic |
Breaking them up helped, but I also disabled two "long running" offenders. Custom triggers that I have been playing with LP1496522 |
| 10:17 |
Freddy_Enrique |
Terrific! Thanks Berick and D. |
| 10:17 |
Bmagic |
Freddy_enrique: probably need autogen.sh ran after the data is loaded |
| 10:17 |
* Dyrcona |
is trying to figure out why 1 record still has an asset.uri entry when the 856 was removed. |
| 10:18 |
Bmagic |
Dyrcona: that sounds fun! |
| 10:18 |
Dyrcona |
It's only 1 out of several thousand. |
| 10:18 |
Bmagic |
csharp: ^^ (forgot to ping your name) |
| 10:18 |
Bmagic |
Dyrcona: delete it! |
| 10:18 |
Bmagic |
and move on with life |
| 10:19 |
Dyrcona |
I might, but I'm checking in the main production database. It could also be something with replication. |
| 10:19 |
csharp |
Bmagic: saw it - thanks! |
| 10:21 |
kmlussier |
Freddy_Enrique: When you have loaded the data, you can find barcodes and logins for patrons at https://wiki.evergreen-ils.org/doku.php?id=qa:concerto_logins |
| 10:22 |
Dyrcona |
Twenty deleted call numbers. |
| 10:24 |
Dyrcona |
Yeah, the asset.uri is still there, but the 856 is gone from the record. |
| 10:25 |
Dyrcona |
The call_number is deleted, which suggests I could make a change in my view. |
| 10:25 |
Dyrcona |
Have to delete it in a transaction. |
| 10:33 |
Dyrcona |
Dunnon why the asset.uri entry wasn't removed. One of the 856s has two $9, but not for the library that shows up. |
| 10:34 |
|
jvwoolf1 joined #evergreen |
| 10:35 |
Dyrcona |
If I was any good with the MARC Editor, I'd remove that extra $9. |
| 10:35 |
Dyrcona |
It's also not in my job description, so I don't want to get in any trouble. :) |
| 10:39 |
csharp |
Dyrcona: my advice: back away slowly! |
| 10:39 |
Dyrcona |
I'll just delete the asset.uri entry from the database tonight. |
| 10:40 |
Dyrcona |
We do "scheduled" updates on Tuesday and Thursday nights. |
| 10:40 |
Dyrcona |
When there are any. |
| 10:42 |
Dyrcona |
The other batch didn't leave any strays, so I'll assume it is not a bug in my process. |
| 10:56 |
* Dyrcona |
has a meeting/training. BBL! |
| 11:00 |
JBoyer |
berick++ |
| 11:00 |
|
collum joined #evergreen |
| 11:00 |
JBoyer |
gmcharlt++ |
| 11:00 |
JBoyer |
I now have workstation-system specific links on our web client splash page. Woo. |
| 11:00 |
berick |
JBoyer: nice! |
| 11:03 |
kmlussier |
It would be nice to have documentation for that. |
| 11:03 |
JBoyer |
I do have one other thing I'm curious about. The two links using this are behind a OpenILS::WWW::Proxy so you have to have permission to view them. In the xul client I just stuck ?ses=(sessionid) on the end to skip the auth coming from the client. |
| 11:03 |
|
Jillianne joined #evergreen |
| 11:04 |
JBoyer |
Is there a better way to do that, one that doesn't involve session keys in the URL? |
| 11:07 |
JBoyer |
kmlussier, since I usually only run into this when doing things that are fairly localized, I never know how much interest there would be in it. |
| 11:08 |
JBoyer |
It is fairly simple though, so I don't have anything against just throwing it into core (or signing off on a branch from berick or gmcharlt) |
| 11:08 |
berick |
JBoyer: i would expect a 'ses' cookie in a appropriate path to do it |
| 11:08 |
berick |
*an |
| 11:09 |
JBoyer |
berick, that's what confuses me. It should already be in the right place, the source and destination links are on the same server. |
| 11:09 |
JBoyer |
Unless I'm missing something |
| 11:09 |
JBoyer |
misunderstanding, rather, |
| 11:10 |
berick |
JBoyer: webbby uses a different auth cookie name |
| 11:10 |
JBoyer |
Well, that would certainly do it. ;) I'll start looking around. |
| 11:11 |
berick |
and really isn't a cookie, but behaves like one |
| 11:11 |
JBoyer |
Hmm. |
| 11:12 |
berick |
wait, no, it's a cookie. still different name. |
| 11:13 |
JBoyer |
I was about to say, if eg.auth.token isn't a cookie, it's fooled Chrome. That's more realistic than Coke Zero. :D |
| 11:14 |
JBoyer |
Oh, and the path is different also. (/eg/staff/ specifically vs /) Might be time to investigate .tt2-ing these things. |
| 11:14 |
JBoyer |
That would simplify a lot of things down the line. |
| 11:16 |
berick |
JBoyer: are staff using webby? |
| 11:16 |
JBoyer |
Just barely beginning to. I'm hoping to have these things in place before use is common. |
| 11:17 |
berick |
cool |
| 11:23 |
|
auvajs joined #evergreen |
| 11:26 |
|
agoben joined #evergreen |
| 11:38 |
|
rlefaive joined #evergreen |
| 11:51 |
|
Christineb joined #evergreen |
| 11:52 |
|
sandbergja joined #evergreen |
| 11:55 |
|
khuckins joined #evergreen |
| 11:55 |
|
jihpringle joined #evergreen |
| 11:58 |
|
_adb joined #evergreen |
| 12:02 |
|
rlefaive_ joined #evergreen |
| 12:28 |
dbwells |
We upgraded to 2.12.2 over the weekend, and are hitting a bug where record links do not work after the first page of search results when "Group Formats" is on. It all seems vaguely familiar, but a quick search didn't turn up anything. We will start digging in earnest after lunch, so any tips are appreciated. |
| 12:28 |
* dbwells |
heads out for a bit |
| 12:35 |
kmlussier |
dbwells: I hadn't come across that bug yet, but I was able to replicate it. Looks like it happens for non-grouped records? |
| 12:40 |
JBoyer |
kmlussier, dbwells, I'm seeing it on all page 2+ results. (grouped and single) |
| 12:40 |
JBoyer |
:( |
| 12:41 |
kmlussier |
I'm not having any trouble with the grouped ones. |
| 12:43 |
|
rlefaive joined #evergreen |
| 12:45 |
* mmorgan |
is not seeing a problem with the grouped records either, just the ungrouped ones. |
| 12:45 |
kmlussier |
mmorgan and I are probably testing on the same server. :) |
| 12:45 |
mmorgan |
maybe! Or two very similar servers :) |
| 12:49 |
jeffdavis |
I can't replicate on 2.12.1. |
| 12:57 |
mmorgan |
I am seeing the problem on a 2.12.0 server with concerto. The grouped records work, the ungrouped ones take me to the my account login page. |
| 13:00 |
Dyrcona |
I think I figured out my dangling asset.uri from earlier. |
| 13:01 |
Dyrcona |
Before I removed this library's 856 tag it had 2 $9 for the same library. |
| 13:01 |
Dyrcona |
Looks like that might have lead to there being 2 asset.uri entries and only 1 was deleted. |
| 13:01 |
jeff |
a pox on duplicate NCIP messages |
| 13:01 |
mmorgan |
Dyrcona: That would do it. |
| 13:02 |
Dyrcona |
jeff: Indeed, and there's a response for that. |
| 13:02 |
Dyrcona |
mmorgan: Is there already a Lp bug? |
| 13:03 |
kmlussier |
I'm having a difficult time finding a search where a grouped Concerto record would end up on the 2+ page of results in a metarecord search. |
| 13:03 |
mmorgan |
Dyrcona: lp 1482757 |
| 13:03 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] https://launchpad.net/bugs/1482757 |
| 13:03 |
mmorgan |
I need to spend a little quality time with miker's latest branch. |
| 13:03 |
Dyrcona |
mmorgan: I'll read that in more detail, but I was thinking specifically about multiple $9 leading to multiple asset uri entries. |
| 13:04 |
mmorgan |
Dyrcona: This comment describes the multiple issue we've seen: https://bugs.launchpad.net/evergreen/+bug/1482757/comments/6 |
| 13:04 |
pinesol_green |
Launchpad bug 1482757 in Evergreen "Loading records with located URIs should not delete and recreate call_numbers" [Undecided,Confirmed] |
| 13:05 |
Dyrcona |
mmorgan: Thanks! I'll read that in a bit. I've only read the bug description and that was some time ago. |
| 13:05 |
mmorgan |
kmlussier: I did a keyword search on piano, and found a grouped result on page 2, #16 |
| 13:05 |
kmlussier |
When Bmagic was working on bug 1629108, I know one change he made is that the direct record link from a grouped search results page was no longer based on the master record. It is supposed to link to the one record that matched the search terms. |
| 13:05 |
pinesol_green |
Launchpad bug 1629108 in Evergreen "Metarecord constituents search result page should use standard search code" [Wishlist,Fix released] https://launchpad.net/bugs/1629108 |
| 13:05 |
kmlussier |
I wonder if that's the cause of the problem. |
| 13:06 |
kmlussier |
Previously, when you weren't able to limit your metarecord search by format, the master record was a fairly reliable link to use because it really meant that the record wasn't part of a larger group. |
| 13:10 |
kmlussier |
Now that you can limit by format, it's possible for a record that is part of the larger group to be the only valid hit in the result set. We needed to change the link so that it went to the actual record that was retrieved in the search. I wonder if adding paging to that query messes up the logic somehow. |
| 13:12 |
Bmagic |
I can't recreate the issue |
| 13:17 |
Bmagic |
Do you have a link to an example search result on non-page-one? https://mlnc2.noblenet.org/eg/opac/results?query=Piano;qtype=keyword;locg=1;detail_record_view=0;modifier=metabib;page=1 |
| 13:17 |
kmlussier |
Bmagic: It happens to me using that link. Click the top result? |
| 13:17 |
kmlussier |
hmmmm |
| 13:19 |
kmlussier |
Bmagic: The record number isn't part of the URL |
| 13:19 |
Bmagic |
I see it! the record number is omitted in the hyperlink . I was clicking on the grouped result #16. |
| 13:19 |
kmlussier |
Bmagic: Yeah, the grouped results are working fine for me, but not for JBoyer . |
| 13:20 |
Bmagic |
Is it on LP yet?> |
| 13:21 |
kmlussier |
Bmagic: Not that I know of. dbwells just mentioned it at 12:28:01 |
| 13:23 |
* kmlussier |
needs to disappear for a while. |
| 13:23 |
|
jwoodard joined #evergreen |
| 13:32 |
dbwells |
kmlussier, mmorgan, JBoyer, Bmagic: thanks for testing and confirming. For the record, we are also seeing that metarecord/grouped results do link correctly, as a few of you noted. |
| 13:33 |
Bmagic |
dbwells: bug 1694497 |
| 13:33 |
pinesol_green |
Launchpad bug 1694497 in Evergreen "Grouped formats page 2+ results omit the record number in hyperlink" [Undecided,New] https://launchpad.net/bugs/1694497 |
| 13:34 |
JBoyer |
Yeah, that's my mistake. groups do work because they're links to new searches basically. When I saw the URL point to /results/?query... I assumed they were broken, just like records. |
| 13:34 |
JBoyer |
Assumptions and so on... |
| 13:35 |
dbwells |
jeffdavis: you mentioned it was working for you on 2.12.1. Do you have a link to the catalog where you are testing that? |
| 13:38 |
dbwells |
Bmagic++ # thanks for the LP bug |
| 13:40 |
JBoyer |
Oh, another wrinkle. I have a result on page 1 that has a busted /record/?blahblah URL. Maybe that record will show us something. |
| 13:41 |
jeffdavis |
dbwells: https://bna.bc.catalogue.libraries.coop/eg/opac/results?query=charles%20dickens;qtype=keyword;locg=24;detail_record_view=1;modifier=metabib;page=1 |
| 13:42 |
jeffdavis |
we have lots of TPAC customizations there which may be why we're not seeing it |
| 13:43 |
Bmagic |
jeffdavis: interesting, you have grouped results for a single record |
| 13:43 |
dbwells |
I was just noting the same thing. Hmmmm. |
| 13:45 |
miker |
that certainly bypasses the problem, though :) |
| 13:45 |
dbwells |
indeed :) |
| 13:46 |
gmcharlt |
I think I have a fix |
| 13:46 |
gmcharlt |
one moment |
| 13:47 |
jeffdavis |
Seems we were finding situations where the master record was not the one constituent record with holdings within scope. http://git.sitka.bclibraries.ca/gitweb/?p=sitka/evergreen.git;a=commitdiff;h=6da51d82 if anyone is interested. |
| 13:47 |
gmcharlt |
yep |
| 13:47 |
pastebot |
"gmcharlt" at 64.57.241.14 pasted "potential fix" (16 lines) at http://paste.evergreen-ils.org/165 |
| 13:51 |
Bmagic |
gmcharlt++ |
| 13:58 |
dbwells |
gmcharlt++ # that fixed it |
| 14:00 |
dbwells |
In testing, noticed another "page 2" bug. The "Return to Grouped Search Results" always takes you back to page one of your search, even if the result you clicked on was on a later page. This isn't what I would expect. I tested with and without gmcharlt's patch, and this doesn't appear related either way. |
| 14:03 |
Bmagic |
dbwells: I believe that is a pre-existing bug, reported a long time ago |
| 14:05 |
dbwells |
Bmagic: Thanks, good to know. It is certainly not as serious as the other. |
| 14:05 |
Bmagic |
I'm hunting for it now |
| 14:07 |
|
plux joined #evergreen |
| 14:10 |
Bmagic |
dbwells: ah yes, this was it, bug 1659892 |
| 14:10 |
pinesol_green |
Launchpad bug 1659892 in Evergreen 2.11 "OPAC: Return to search results link retains page value" [Undecided,Fix released] https://launchpad.net/bugs/1659892 |
| 14:12 |
Bmagic |
I think you might have encountered something slightly different which merits two different paging systems. One page system for constituent grouped results and another paging system for the grouped results. Where each can be kept track of. |
| 14:12 |
|
rlefaive joined #evergreen |
| 14:14 |
Bmagic |
dbwells: the video link on that bug is informative. Fixing that bug might have this unattended effect. Scrubbing the page in the URI in other contexts |
| 14:20 |
dbwells |
Bmagic: I think you are right, that fix probably caused the bug I am seeing. Two different paging vars sounds like the right idea. |
| 14:21 |
Bmagic |
dbwells: it would mean the search code would need to know about those as well, a bit of a deeper issue |
| 14:32 |
plux |
hitting the white screen for web client on a fresh Xenial EG 2.12.2 install…installed from the tarball from openils.org…known issues ? |
| 14:34 |
JBoyer |
plux, everything OK on the websockets connection? I've seen that when there's a problem there |
| 14:35 |
plux |
seems to be….just one angular.js injector error - Failed to instantiate module egHome |
| 14:39 |
|
kmlussier joined #evergreen |
| 14:40 |
JBoyer |
That's not a good sign, egHome is the controller for the splash page, so if it's not working, you won't get anything there. The only error I get when things are working well is a 404 for the woff2 version of the glyphicons font. |
| 14:40 |
JBoyer |
are you using letsencrypt for real certs or do you have self-signed ones in place? |
| 14:40 |
plux |
letsencrypt |
| 14:41 |
plux |
with valid domain |
| 14:42 |
JBoyer |
You might double check that the websockets instance is also using them correctly (and it may just need kicked with a sudo apache2ctl-ws restart) |
| 14:44 |
|
jvwoolf joined #evergreen |
| 14:44 |
kmlussier |
gmcharlt++ |
| 14:49 |
plux |
triple checked and flushed memcache - restarted websockets…no errors and page resolves in all browsers except for that injector module error |
| 14:49 |
plux |
so …white screen but underlying source looks fine and console shows only that exception…. |
| 14:50 |
gmcharlt |
plux: is system available on open net? |
| 14:51 |
plux |
https://evergreen.islandarchives.ca/eg/staff/login |
| 14:51 |
plux |
just the concerto db so no worries with anything |
| 14:59 |
gmcharlt |
plux: so after following down the errors a bit, https://docs.angularjs.org/error/$injector/modulerr?p0=ngCookies&p1=Error:%20%5B$injector:nomod%5D%20http:%2F%2Ferrors.angularjs.org%2F1.5.11%2F$injector%2Fnomod%3Fp0%3DngCookies%0A%20%20%20%20at%20https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:6:426%0A%20%20%20%20at%20https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff% |
| 14:59 |
gmcharlt |
2Fbuild%2Fjs%2Fangular.min.js:25:235%0A%20%20%20%20at%20b%20(https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:24:282)%0A%20%20%20%20at%20https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:25:20%0A%20%20%20%20at%20https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:40:17%0A%20%20%20%20at%20q%20( |
| 14:59 |
gmcharlt |
https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:7:371)%0A%20%20%20%20at%20g%20(https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:39:382)%0A%20%20%20%20at%20https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:40:34%0A%20%20%20%20at%20q%20(https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault |
| 14:59 |
gmcharlt |
%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:7:371)%0A%20%20%20%20at%20g%20(https:%2F%2Fevergreen.islandarchives.ca%2Fjs%2Fui%2Fdefault%2Fstaff%2Fbuild%2Fjs%2Fangular.min.js:39:382)%0A%20%20%20%20at%20https:%2F%2Fevergreen.islandarchives |
| 15:00 |
gmcharlt |
er, whoops; apologies for not using a shortener there |
| 15:00 |
gmcharlt |
but upshot it that it's looking for ngCookies |
| 15:01 |
|
mmorgan1 joined #evergreen |
| 15:11 |
gmcharlt |
plux: could you double-check that /openils/var/templates/staff/base_js.tt2 includes a reference to angular-cookies? |
| 15:12 |
gmcharlt |
and was this install fresh on a brand new VM, or did it overlay an older installation? |
| 15:14 |
plux |
fresh install on new VM - and base_js.tt2 has the reference to angular-cookies |
| 15:15 |
gmcharlt |
next, please check /openils/var/templates/staff/config.tt2 |
| 15:15 |
gmcharlt |
and see if EXPAND_WEB_IMPORTS is set to 1 |
| 15:16 |
plux |
yep |
| 15:17 |
plux |
paths seem correct and files e.g. angular-cookies are there…permissions look good |
| 15:20 |
gmcharlt |
grasping at straws, here, but there isn't a local template customization directory in play? |
| 15:21 |
plux |
got it….templates….I had a custom template set and for some reason it wasn’t falling back to the default for the staff client |
| 15:21 |
plux |
I disabled the call to the custom template…..so my bad…I can work with that |
| 15:22 |
gmcharlt |
did the custom template set inadvertently include an older copy of templates/staff ? |
| 15:22 |
plux |
it did….should have caught that |
| 15:23 |
gmcharlt |
ok |
| 15:23 |
gmcharlt |
the other thing I noticed is that opensrf_ws.js is expecting to talk to port 7682 for WSS, but that port's not open |
| 15:23 |
gmcharlt |
(or well, not open to me) |
| 15:23 |
plux |
thanks…..I was bashing at the js end and wasn’t considering the templates |
| 15:24 |
plux |
yeah…. campus firewall …over which I don’t have control |
| 15:25 |
plux |
considering it’s just campus staff we usually leave it closed as they can access on campus or via vpn |
| 15:26 |
gmcharlt |
gotcha |
| 15:50 |
|
mmorgan joined #evergreen |
| 16:08 |
kmlussier |
@quote random |
| 16:08 |
pinesol_green |
kmlussier: Quote #100: "< RoganH> It's not bad data, it's legacy opportunities for improvement." (added by csharp at 11:31 AM, December 08, 2014) |
| 16:12 |
|
sandbergja joined #evergreen |
| 16:17 |
|
maryj joined #evergreen |
| 16:20 |
Dyrcona |
I know there's nothing in it, but a config.upgrade_log update, but it looks like the 2.12.1 to 2.12.2 upgrade script did not make it into origin/rel_2_12. |
| 16:22 |
Dyrcona |
Or, wait. Maybe there should be something in it. |
| 16:25 |
Dyrcona |
Yeah. There should be something in it and it is missing from the rel_2_12 branch. |
| 16:31 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
| 16:44 |
gmcharlt |
Dyrcona: thanks for catching that; I've corrected this |
| 16:45 |
Dyrcona |
gmcharlt++ |
| 16:45 |
Dyrcona |
I was going to open a Lp bug later. |
| 16:45 |
Dyrcona |
I noticed because I have a test branch based on rel_2_12 and I was looking for the upgrade script to run. :) |
| 16:46 |
gmcharlt |
indeed |
| 16:46 |
gmcharlt |
also, that one's not a no-op |
| 16:47 |
|
Jillianne joined #evergreen |
| 16:55 |
kmlussier |
So where are offline transactions stored? |
| 16:56 |
kmlussier |
Sorry, I'm being unclear. I'm talking about web client offline transactions. |
| 16:56 |
|
StomproJ joined #evergreen |
| 16:58 |
kmlussier |
Oh, I see. The IndexdDB storage |
| 17:12 |
|
mmorgan left #evergreen |
| 18:59 |
|
jihpringle joined #evergreen |
| 21:27 |
|
khuckins joined #evergreen |
| 21:38 |
|
Freddy_Enrique joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
