| 11:18 |
Dyrcona |
phasefx: What version of Pg is installed? |
| 11:18 |
berick |
building test server on ub 18? |
| 11:18 |
phasefx |
Dyrcona: PostgreSQL 9.6.10 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit |
| 11:19 |
Dyrcona |
OK. I don't recall if I've ever run the tests on Pg 9.6. |
| 11:19 |
phasefx |
berick: debian stretch, but we have or are close to having multi-server support |
| 11:20 |
phasefx |
http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.xml;h=6e3952d0b1f47e2a1898d3048ebe6153ce4da547;hb=refs/heads/collab/phasefx/eg_live_tests |
| 11:20 |
berick |
nice! |
| 11:21 |
Dyrcona |
Looks like we'll have to modify the test to accommodate 9.6 also.... |
| 11:31 |
phasefx |
right now testing.evergreen-ils.org is still running test.sh (http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test.sh;h=11d96d5b42eb05d513e6bea63d75a29983175246;hb=refs/heads/collab/phasefx/eg_live_tests), but we can eventually switch it over to and smoke test test_runner.pl http://git.evergreen-ils.org/?p=working/random.git;a=blob;f=qa/test_runner.pl;h=4fc672529021ec2b74bcf83d69dc22bf74ff3c73;hb=refs/heads/collab/phasefx/eg_live_test |
| 11:32 |
phasefx |
then folks with commit access to the branch can just add their servers (there's an ssh pubkey for testin.evergreen-ils.org in the branch) |
| 11:33 |
Dyrcona |
phasefx: Sound interesting/useful. I'll take a look some day. |
| 11:38 |
jeff |
what keeps us using the random repository for all manner of things? would gitlab and/or something else help us get away from that practice, because it would potentially reduce the burden of creating a repo? |
| 11:38 |
jeff |
(tangent, i know) |
| 12:25 |
|
bdljohn1 joined #evergreen |
| 12:36 |
|
beanjammin joined #evergreen |
| 12:39 |
Dyrcona |
jeff: Gitlab will let you create your own repositories just by pushing to them be default. It can be done with gitolite using a wildcard repo configuration. |
| 12:42 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,428726255-0500 -0> |
| 12:42 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,450827934-0500 -2> |
| 12:42 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live#2018-12-12T12:12:09,472980231-0500 -4> |
| 12:47 |
dickreckard |
uhm, is there a way to list the last records added to the catalog in the staff client? |
| 13:01 |
miker |
dickreckard: in the staff client directly? hrm, probably not. but in another tab: http://sandbox-32.evergreencatalog.com/opac/extras/feed/freshmeat/opac/biblio/import/10/ |
| 13:05 |
* jeff |
notes the Apache "Found" 3xx body appended to the end of that document |
| 13:12 |
jeff |
also, if you're not logged in to the staff client in that browser when you fetch that url, if the most recent 10 bibs aren't otherwise visible in searches, you may get zero results, or more likely less than the number requested. |
| 13:14 |
jeff |
but if there are zero results you'll get an error that references record IDs, which you can then individually retrieve. |
| 13:16 |
Dyrcona |
dickreckard: What problem are you trying to solve? Do you want to see X of the most recent records you've added or just the previous one? This sounds like a potentially useful feature request. |
| 13:16 |
dickreckard |
no it's for the staff indeed |
| 13:17 |
dickreckard |
just wanted to check how the staff is doing in the test installation, and export the records that were added |
| 13:17 |
dickreckard |
so maybe make a csv with the IDs and use the batch export |
| 13:18 |
dickreckard |
cos I will need to merge the old database with the recods that were added in the test installation, into a new installation |
| 13:20 |
dickreckard |
I think a record query " * sort(create_date) #descending " solve my needs.. but indeed the last x records instead of just the 'retriev last bib record' button could be nice |
| 13:26 |
dickreckard |
also I finally solved the problem I had with vandelay batch imports.. I found the issue was that systemd creates a private /tmp folder nested inside an apache2 private folder, so it couldn't find the uploaded temporary .mrc file as it was inside the private tmp instead of /tmp. I wanted to somehow add that note somewhere, cos it would be useful to add in the documentation as from debian stretch it's the |
| 13:26 |
dickreckard |
default behavior. |
| 13:27 |
dickreckard |
I looked on launchpad and couldn't find mentions about it. so let me know if I can add notify this somewhere. |
| 13:29 |
jeff |
It might be reasonable to review changing the default value of <importer>/tmp</importer> in openils.xml.example |
| 13:31 |
Dyrcona |
dickreckard: You should be able to get marc records out of the URL that miker shared earlier. |
| 13:31 |
|
sandbergja joined #evergreen |
| 15:12 |
gmcharlt |
request chunking will /not/ make it into 3.1-beta for lack of code |
| 15:12 |
gmcharlt |
any questions? |
| 15:12 |
* miker |
hangs head in shame |
| 15:13 |
JBoyer |
Looks good, since I'm hoping to use websocketd in production soon I'll try to test those two branches too. |
| 15:14 |
|
bdljohn1 joined #evergreen |
| 15:14 |
* Dyrcona |
is using websocketd in production and it is very reliable. |
| 15:14 |
berick |
just noticed I need a better commit message on the websocketd patch... |
| 15:25 |
gmcharlt |
ok, moving on |
| 15:25 |
gmcharlt |
#topic Hatch |
| 15:25 |
|
Topic for #evergreen is now Hatch (Meeting topic: Evergreen Development Meeting, 2018-12-12) |
| 15:26 |
berick |
I am planning to help w/ the Dymo LP, at minimum code reivew and non-Dymo testing. |
| 15:26 |
gmcharlt |
berick++ |
| 15:26 |
berick |
I don't have a Dymoe printer, alas |
| 15:27 |
berick |
so kind of like the other Hatch issue, more help testing would be appreciated |
| 15:27 |
gmcharlt |
I have one comment so far ... I dislike calling it "compatibility mode" as a printing setting |
| 15:27 |
dbwells |
We've got a million Dymos and can help with testing. |
| 15:27 |
Bmagic |
I solicited my libraries and was able to borrow one more long term. |
| 14:49 |
jeff |
similarly, History (bib_source(1)) does not restrict to bib source 1 |
| 14:51 |
miker |
jeff: that's both interesting and annoying... I'll see if there's something obvious |
| 14:52 |
jeff |
thanks. in the meantime, i'm learning new things. :-) |
| 14:52 |
miker |
jeff: the one common thing there is that locations and bib source are part of the new int_array-based attribute vector visibility tests, and audience is not -- it's a standard coded value map thing |
| 14:53 |
jeff |
problem came to light because we have some search filter groups that use locations() |
| 14:55 |
jeff |
and locations(123) and bib_source(1) seem to do the expected thing with regard to the SQL using search.calculate_visibility_attribute_test |
| 14:56 |
jeff |
but (locations(123)) and (bib_source(1)) eventually lose the filter before it gets to the sql. |
| 15:01 |
|
bdljohn joined #evergreen |
| 15:02 |
|
yboston joined #evergreen |
| 15:05 |
Dyrcona |
So, if someone has a bad url on a provider and activates a PO and pushing the edi fails, does fixing the url automagically fix it all, or do I need to update some other fields? |
| 15:14 |
pinesol |
News from qatests: Failed cloning git repositories <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 5. <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 15:14 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 15:14 |
* berick |
chuckles |
| 15:15 |
berick |
as if millions of QA tests suddenly cried out in terror |
| 15:16 |
Dyrcona |
:) |
| 15:16 |
Dyrcona |
Well, if you can't clone the repo.... |
| 15:19 |
|
jvwoolf1 joined #evergreen |
| 16:42 |
|
dkyle2 left #evergreen |
| 16:42 |
Dyrcona |
Yeah, that PO definitely causes some kind of problem. |
| 16:42 |
* Dyrcona |
will look into it more tomorrow. |
| 17:06 |
jeff |
miker: the patch supplied above doesn't seem to improve the issue. testing with opac and with Open-ILS/src/support-scripts/test-scripts/query_parser.pl |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
|
jvwoolf1 left #evergreen |
| 17:18 |
pinesol |
News from qatests: Failed cloning git repositories <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen database pre-requisites <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Building OpenSRF <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing OpenSRF <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Building Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Running Evergreen browser client build/test - Expected 6 errors but encountered 5. <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed Installing Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:18 |
pinesol |
News from qatests: Failed configure database <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Running settings-tester.pl <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 17:19 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 17:24 |
dbwells |
:( |
| 17:36 |
|
khuckins joined #evergreen |
| 17:54 |
Bmagic |
Grrrr, xpath yall |
| 17:54 |
Bmagic |
oils_xpath('//datafield[@tag="856"]/subfield[@code="u"]/text()',marc) doesn't seem to work |
| 17:57 |
Bmagic |
ha! //*[@tag="856"]/*[@code="u"] worked |
| 18:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed setting ld.so.conf and rsyslog and /etc/hosts and ejabberd <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running OpenSRF build tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running Evergreen build tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed configure apache <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Starting Evergreen <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 171. <http://testing.evergreen-ils.org/~live> |
| 19:31 |
pinesol |
News from qatests: Failed <http://testing.evergreen-ils.org/~live> |
| 10:08 |
|
jvwoolf joined #evergreen |
| 10:10 |
|
yboston joined #evergreen |
| 10:39 |
|
khuckins joined #evergreen |
| 10:40 |
Dyrcona |
remingtron | mmorgan: I've made the branches and pushed them to the working repo. I'm going to test them on MassLNC VMs before updating the bug and adding the pullrequest tag. |
| 10:44 |
remingtron |
Dyrcona++ |
| 10:45 |
|
abneiman joined #evergreen |
| 10:46 |
Dyrcona |
@blame [band] |
| 10:46 |
* Dyrcona |
waits on the installation script.... |
| 10:51 |
Dyrcona |
It takes about 20 to 25 minutes from start to finish, if anyone cares. :) |
| 11:40 |
Dyrcona |
After some fun with clearing the cache and cookies, the 3.1 branch works for me. |
| 11:41 |
Dyrcona |
bshum suggested using incognito mode windows for testing, which I think is a good idea. I'll try that next time. |
| 11:42 |
mmorgan |
Dyrcona: I would second the use of incognito mode |
| 11:43 |
Dyrcona |
And, hey! There's a developers' meeting scheduled for this afternoon. |
| 11:44 |
Dyrcona |
mmorgan: You would be interested to know that I have updated the build scripts for the MassLNC VMs and fixed most of the issues. I will send an email to the interested parties later. This branch testing also constitutes testing of the scripts. |
| 11:45 |
mmorgan |
Dyrcona++ |
| 11:49 |
|
sandbergja joined #evergreen |
| 12:12 |
|
jihpringle joined #evergreen |
| 13:12 |
|
beanjammin joined #evergreen |
| 13:17 |
|
stlink joined #evergreen |
| 13:21 |
stlink |
Problem solved: they had blocked cookies from being accepted from the PINES server. |
| 13:28 |
remingtron |
Seems like the qatests haven't run in a while |
| 13:28 |
remingtron |
According to IRC logs, looks like this is the last day it ran (or logged to IRC anyway): http://irc.evergreen-ils.org/openils-evergreen/2018-08-27 |
| 13:29 |
remingtron |
er, I guess the test output says Sept 10, but that's still a while ago |
| 13:30 |
remingtron |
phasefx: what's the state of the test server? |
| 13:45 |
remingtron |
sandbergja: Seems like we need to remove old docs files, like "circulating_items.adoc |
| 13:45 |
remingtron |
", which has been replaced by "circulating_items_web_client.adoc". Keeps causing confusion. |
| 13:46 |
remingtron |
sandbergja: if you have any thoughts on how to approach that process, I'd love to hear them! |
| 13:47 |
* miker |
will not be able to make it to the dev meeting today :( |
| 13:57 |
phasefx |
remingtron: re: test server, on my plate for next Tuesday |
| 13:57 |
remingtron |
phasefx: awesome |
| 13:57 |
* dbwells |
will also miss the dev meeting today |
| 14:02 |
berick |
in light of the above, and given there's no agenda or email reminder, perhaps we should push the dev meeting back a week. |
| 10:06 |
Dyrcona |
Anyone using the Hold Expires from Shelf Soon email notice care to discuss how you run it? |
| 10:07 |
Dyrcona |
We're running it daily with a delay of -2 days and finding that they usually go out for the next day, not two days ahead. |
| 10:08 |
Dyrcona |
I think that's because the shelf expire time is not 23:59:59 but the actual time the item went on the shelf + our 7 day interval. |
| 10:08 |
Dyrcona |
If I run it later in the day on a test VM, I get more that are 2 days out but still get some that are for 1 day. |
| 10:12 |
* Dyrcona |
is considering changing the delay to -3 days, but wonders if running it hourly would make a difference. |
| 10:15 |
JBoyer |
We don't use it here (probably should consider it) but if there's a preference for 2 days it might help to add an additional 12 hours, so 60 hours rather than 2 days? Depending on how things line up that should fairly well cover the second day without creeping into the third or leaving many behine. |
| 10:17 |
|
kmlussier joined #evergreen |
| 13:33 |
sandbergja |
That makes sense. I'm not sure how we came to the decision to use suffixes for volume indications; it was before my time |
| 13:36 |
Dyrcona |
I think added the volume to the end of call numbers is a fairly common thing in libraryland. |
| 13:50 |
Dyrcona |
Back to my hold expires from shelf soon thing: I just noticed that the 2 day courtesy notice that we use has a delay of -3 days and a max delay of -2 days. I'm going to use those settings. |
| 13:56 |
* Dyrcona |
tests it, first. |
| 14:58 |
|
yboston joined #evergreen |
| 15:04 |
mmorgan |
Dyrcona: FWIW, our 2 day courtesy notices have those same settings. |
| 15:04 |
Dyrcona |
mmorgan: -3 days, -2 days, daily granularity? |
| 15:05 |
Dyrcona |
It's looking like that would work, but I'm testing -2 days, -1 days, hourly granularity. |
| 15:05 |
mmorgan |
Dyrcona: Yes, daily |
| 15:12 |
JBoyer |
A late in the day thought re: acp.alert_message in a post 3.1/3.2 world, is there any reason for it to even be in the IDL at all? After running the upgrade script and updating the copy editor there's really no way to use it anymore, and it's displayed by default in a few grids... |
| 15:13 |
JBoyer |
I don't think it's worth altering the db tables just yet, but if it can't be set and can't be changed, maybe it's time it can't be seen. |
| 15:47 |
mmorgan |
I had caramel apple bullseyes once. They were surprisingly not bad. |
| 15:51 |
kmlussier |
I don't think I would like that. |
| 16:20 |
Dyrcona |
Jabber disconnects.... |
| 16:21 |
Dyrcona |
On a test server but sure is making testing rather difficult. |
| 16:23 |
|
khuckins_ joined #evergreen |
| 16:34 |
|
nfburton joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 16:40 |
Dyrcona |
And, G+ is dying for real. |
| 16:41 |
kmlussier |
phasefx: I see you are assigned to bug 1714070. It's quite possibly the last branch I'll have an opportunity to merge to EG. Would you object if I end up hijacking it away from you? |
| 16:41 |
pinesol |
Launchpad bug 1714070 in Evergreen "Web Client: Parent/Guardian Field vs Secondary Identification" [Wishlist,Confirmed] https://launchpad.net/bugs/1714070 - Assigned to Jason Etheridge (phasefx) |
| 16:42 |
* kmlussier |
still has to test the latest update to the branch. |
| 17:05 |
|
mmorgan left #evergreen |
| 18:41 |
|
beanjammin joined #evergreen |
| 20:31 |
|
kmlussier joined #evergreen |
| 20:51 |
kmlussier |
@later tell gmcharlt The automatic feed from evergreen-ils.org to FB and GooglePlus is done through my wordpress.com account, which is authorized to post via my FB and GooglePlus logins. We should probably transfer that to somebody else's account. |
| 20:51 |
pinesol |
kmlussier: The operation succeeded. |
| 20:53 |
kmlussier |
@later tell gmcharlt There are many people with admin rights to the EG FB page, but I think dbs may be the only person with admin rights to the G+ page. If we want to continue the EG G+ page, we should probably add another admin or two. |
| 20:53 |
pinesol |
kmlussier: The operation succeeded. |
| 12:03 |
stephengwills |
I assume it’s a better practice to have one copy of a funtion and have it living in the schema my target version expects? |
| 12:03 |
stephengwills |
function* |
| 12:06 |
blongwel |
jeff:after getting a help ticket from one of our libraries I looked up some emails in patron records and tried a search on them. |
| 12:11 |
jeff |
blongwel: auditor.actor_usr_lifecycle could help determine if the email address value changed in any way, but if you're confident that the value before and after save was identical, it's possible that you have a corrupt index on that column. have you tested at the database level with something like SELECT id, email FROM actor.usr WHERE deleted = false AND lowercase(email) = |
| 12:11 |
jeff |
lowercase('someaddress example.org');? |
| 12:11 |
jeff |
(sorry, that split across messages) |
| 12:11 |
jeff |
a corrupt index would be worrisome unless you know what led to the corruption, but a REINDEX can fix it. |
| 12:11 |
jeff |
but I'd suggest confirming the symptoms before trying that. |
| 12:13 |
blongwel |
jeff: I will give that a try. Thanks for the assist |
| 12:13 |
jeff |
What does the index look like currently in the psql output of \d+ actor.usr |
| 12:14 |
jeff |
mine looks like: "actor_usr_email_idx" btree (lowercase(email)) |
| 12:43 |
kmlussier |
stephengwills: What release were you on previously? |
| 12:43 |
* kmlussier |
can't back pies until tonight or maybe tomorrow morning. |
| 12:44 |
kmlussier |
s/back/bake |
| 12:44 |
stephengwills |
I’m moving from 2.8.3 to 3.1.7 on my test bed. |
| 12:44 |
jeff |
impressive. beats our 2.10 -> 3.1 jump back in September. |
| 12:44 |
kmlussier |
Wow! That's a lot of fun new features packaged in there. |
| 12:45 |
bshum |
stephengwills: When you go through the motions |
| 15:18 |
pinesol |
Launchpad bug 1529969 in Evergreen "double-scan during check-in still troublesome" [Undecided,New] |
| 15:33 |
|
stephengwills left #evergreen |
| 15:57 |
kmlussier |
mmorgan: I'm confused. I thought the Retarget All Statuses modifier covered those non-holdable statuses. Am I misremembering? |
| 16:00 |
mmorgan |
It's been a while since I tested this, but for an item in a non-holdable status, the first checkin would clear the status, possibly the retargeting would happen in the background, but the item was non-holdable, so it wouldn't capture. The second checkin would capture. |
| 16:01 |
* mmorgan |
should re-confirm that with a current test |
| 16:04 |
kmlussier |
OK, if that's the case, then that bug can probably be set to Incomplete. I'll add a comment. |
| 16:05 |
kmlussier |
I don't think I understand what the use case is for retargeting all statuses if it's not there to capture those items that were not in the hold copy map. |
| 16:07 |
jeff |
without "retarget all statuses", it only attempts to retarget copies that had a pre-checkin status of "In Process". |
| 09:10 |
bshum |
I guess I did do placeholder upgrade scripts for continuity back in bug 925776. Once upon a time. |
| 09:10 |
pinesol |
Launchpad bug 925776 in Evergreen "located URIs appear in staff client OPAC searches regardless of $9's" [Medium,Fix released] https://launchpad.net/bugs/925776 |
| 09:10 |
bshum |
Calling 1137 and 1138 |
| 09:28 |
pinesol |
[evergreen|Rogan Hamby] LP#1643709 purge users on merge instead of flag deleted - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6ded488> |
| 09:28 |
pinesol |
[evergreen|Rogan Hamby] LP#1643709 User merge + purge pgtap test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f4791ce> |
| 09:28 |
pinesol |
[evergreen|Ben Shum] LP#1643709: Stamping upgrade scripts - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=71f5ed7> |
| 09:40 |
|
yboston joined #evergreen |
| 10:02 |
|
sandbergja joined #evergreen |
| 11:08 |
|
khuckins joined #evergreen |
| 11:13 |
|
khuckins_ joined #evergreen |
| 11:23 |
pinesol |
[evergreen|Jane Sandberg] Docs: adding release notes for 3.1.8 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a19990c> |
| 11:29 |
pinesol |
[evergreen|Jane Sandberg] Docs: release notes for 3.2.2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2867043> |
| 11:43 |
dbwells |
FYI: Cutoff for 3.1.8 and 3.2.2 will be today at 12:30 EDT. If anyone needs a little more time than that, please let me know. Thanks! |
| 11:53 |
pinesol |
[evergreen|Jane Sandberg] Docs: documenting multiple emails in patron editor (LP1755625) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5ebb67d> |
| 11:55 |
* jeff |
digs to see why dojo fieldmapper-related things are broken on a new web client setup on a 3.1 system |
| 11:57 |
|
mdriscoll joined #evergreen |
| 12:04 |
|
khuckins joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:06 |
JBoyer |
re: dbwells's comment above: lp 1793154 should be a super simple test. Bug 1772062 might not take much effort either. |
| 12:06 |
pinesol |
Launchpad bug 1793154 in Evergreen "Web client: Can't Cancel Hold from Title Records" [Undecided,Confirmed] https://launchpad.net/bugs/1793154 |
| 12:06 |
pinesol |
Launchpad bug 1772062 in Evergreen 3.1 "Copy Template Missing Values When Applied" [High,Confirmed] https://launchpad.net/bugs/1772062 |
| 12:07 |
JBoyer |
Uh oh. That's not the right bug number at all. (1772062 will in fact, not be easy to test, but the bug it actually addresses would be.) |
| 12:09 |
JBoyer |
It's bug 1804038 that should be ready to go. |
| 12:09 |
pinesol |
Launchpad bug 1804038 in Evergreen "Password Reset results in Internal Server Error" [High,Confirmed] https://launchpad.net/bugs/1804038 |
| 12:10 |
JBoyer |
I apparently copypasta'd the wrong number into muy branch name... |
| 12:16 |
* mmorgan |
will grab lp 1793154 |
| 12:16 |
pinesol |
Launchpad bug 1793154 in Evergreen "Web client: Can't Cancel Hold from Title Records" [Undecided,Confirmed] https://launchpad.net/bugs/1793154 |
| 12:17 |
dbwells |
JBoyer: about that bug, 'clense' was a misspelling which was meant to be eradicated long ago, but some stragglers remained. I think a better fix would be to move the fixed spelling, which in general will not need to be namespaced (provided we are importing :datetime). |
| 12:17 |
dbwells |
JBoyer: I can create such a branch if you want to test and signoff, or we could do it the other way if that works better for you. |
| 12:20 |
dbwells |
Actually, I am not sure why the misspelling wasn't working, since that should be exported, too. Hmmmm. |
| 12:22 |
|
kmlussier joined #evergreen |
| 12:24 |
dbwells |
Ah, I see, the function has been moved/renamed again :) |
| 12:33 |
dbwells |
ok, branch incoming shortly |
| 12:35 |
|
nfburton joined #evergreen |
| 12:37 |
mmorgan |
JBoyer++ |
| 12:37 |
mmorgan |
lp 1793154 was an annoying one! |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:52 |
|
JBoyer joined #evergreen |
| 08:57 |
|
mdriscoll joined #evergreen |
| 09:02 |
bshum |
dbs: csharp: Well the prereqs haven't been updated for Fedora since 16, so there's alot of tweaking we still have to do to make sure all the packages are up-to-date |
| 09:02 |
bshum |
But just having a working OpenSRF with ejabberd is a good first sign. |
| 09:03 |
bshum |
I got stumped on the httpd configs, because of the different installation paths between apache on Debian/Ubuntu vs. Fedora |
| 09:03 |
bshum |
And the fact that I guess we've never made a Fedora httpd config for Apache 2.4 either. |
| 09:03 |
bshum |
So lots more tweaking to go |
| 09:04 |
bshum |
But it'd be an amusing little pet project. |
| 09:04 |
bshum |
I keep meaning to sign up and get a copy of RHEL to experiment on. |
| 09:04 |
bshum |
Baby stpes |
| 09:04 |
bshum |
*steps |
| 09:05 |
bshum |
csharp: Poor build servers :( But clearly we need to look at rebuilding all our test infrastructure for the community at large all the same |
| 09:08 |
csharp |
yeppers |
| 09:08 |
csharp |
it shouldn't be a problem to host build testing VMs in our new cloud-ish environment |
| 09:09 |
csharp |
but that all depends on whether we move to a git solution with built-in CI |
| 09:24 |
|
nfburton joined #evergreen |
| 09:29 |
|
jonadab joined #evergreen |
| 09:35 |
|
yboston joined #evergreen |
| 13:04 |
|
jvwoolf left #evergreen |
| 13:21 |
kmlussier |
JBoyer++ # Bug 1804038 |
| 13:21 |
pinesol |
Launchpad bug 1804038 in Evergreen "Password Reset results in Internal Server Error" [High,Confirmed] https://launchpad.net/bugs/1804038 |
| 13:21 |
kmlussier |
I was trying to enable password reset on a test VM recently and kept coming across that bug. Since I never enable password resets, I thought the problem was me. |
| 13:24 |
JBoyer |
a basic grep of that function name shows that most calls are fully specified but Booking may have another potential issue. Since I'm still waiting for things to install for a proper test I'll probably go ahead and cover that one too. |
| 13:51 |
csharp |
seeing some acq failures to create volumes/copies and wanted to rule that out - thanks, JBoyer |
| 13:52 |
csharp |
the angular acq rewrite can't come quickly enough :-/ |
| 13:52 |
csharp |
current situation: press activate and pray |
| 12:34 |
csharp |
LINE 13: ...visibility_attribute_test('circ_lib','{7}',FALSE),search.cal... |
| 12:35 |
miker |
csharp: yeah, the fix in 3.0 will be different in detail |
| 12:35 |
csharp |
oh - so it's a known bug? |
| 12:36 |
miker |
I don't know about 3.0 re that bug |
| 12:36 |
miker |
but I know the 3.0 vis tests are different than 3.1+ |
| 12:37 |
csharp |
I'm trying to nail down the parameters of search that cause the bug - most searches appear to work fine |
| 12:37 |
miker |
csharp: you mean LP#1773479? that's specifically about browse, fwiw |
| 12:38 |
jeff |
oh, that reminds me that i need to turn up some logs and look into the case where locations()-style search limiting in a filter group entry was seeming to be ignored. |
| 12:47 |
csharp |
yeah, each of the errors so far include filters for copy locations |
| 12:54 |
csharp |
...and, more tickets about this coming in |
| 12:54 |
csharp |
fun! |
| 13:01 |
miker |
csharp: you have the top 2 commits from http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1723977-staff-visibility-test-squash-upgrade right? |
| 13:01 |
|
beanjammin joined #evergreen |
| 13:05 |
csharp |
select * from search.calculate_visibility_attribute_test('location',3391,FALSE); is what's eliciting the error |
| 13:05 |
csharp |
apparently it's not seeing 'location' as text |
| 08:57 |
|
stephengwills joined #evergreen |
| 09:04 |
stephengwills |
I’ve upgraded db schema to 3.1 and srfsh allows me to log in but my search reveals no items. I tried reingesting and still no joy. suggestions? |
| 09:06 |
|
ningalls__ joined #evergreen |
| 09:12 |
pinesol |
[evergreen|Dan Wells] LP#1635737 Add optional context to interval_to_seconds - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac48931> |
| 09:12 |
pinesol |
[evergreen|Mike Rylander] LP#1635737: Unit tests for DST and date math - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a659357> |
| 09:12 |
pinesol |
[evergreen|Dan Wells] LP#1635737 Use new OpenSRF interval_to_seconds() context - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bd047ba> |
| 09:12 |
pinesol |
[evergreen|Mike Rylander] LP#1635737 Apply DST-aware timezone to context dates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=319f82d> |
| 09:12 |
pinesol |
[evergreen|Bill Erickson] LP#1635737 Due date DST-aware thinko fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e067e00> |
| 09:22 |
|
yboston joined #evergreen |
| 09:27 |
berick |
dbwells: working/user/berick/lp1635737-syntax-fix |
| 09:29 |
|
abowling joined #evergreen |
| 12:27 |
jeff |
heh. |
| 12:29 |
jeff |
that's a slightly more complicated answer, and requires delving into the "novel data structure" |
| 12:31 |
Bmagic |
hmmm, that is one number and not several numbers concatenated (grasping at straws)... I do notice that the same bib has a source id |
| 12:31 |
mmorgan |
Bmagic: I have a concerto test system that shows 2 biblio.record_entry rows with that value in vis_attr_vector |
| 12:32 |
Bmagic |
interesting, with that value, which search scopes will it result the bib? |
| 12:32 |
mmorgan |
and one record that has {268435457} |
| 12:33 |
jeff |
268435458 indicates "bib source 2" |
| 14:47 |
|
Dyrcona joined #evergreen |
| 14:48 |
* Dyrcona |
got bumped in DTW (Detroit) not leaving until 10:00 PM tonight. |
| 14:48 |
JBoyer |
D: |
| 14:49 |
* Dyrcona |
will also have questions about action_trigger_runner.pl because it is not working on my test vm, but it was a couple of weeks ago. (I know that's vague, but I have to start looking at it again.) |
| 14:49 |
|
kmlussier joined #evergreen |
| 14:58 |
csharp |
has anyone out there done a batch forgive of bills that I might crib from? starting from scratch is... not fun |
| 14:59 |
mmorgan |
csharp: I asked a similar question a week or two ago without response :-( |
| 15:34 |
mmorgan |
Bmagic++ |
| 15:34 |
mmorgan |
Dyrcona++ |
| 15:42 |
|
plux left #evergreen |
| 15:42 |
Dyrcona |
So, I'm trying to figure out why action_trigger_runner.pl appears to do nothing on my test VM. It was working a week or so ago. |
| 15:42 |
Dyrcona |
It runs but says there's nothing to do, basically. |
| 15:42 |
Bmagic |
what are all of the arguments, granularity? |
| 15:43 |
Dyrcona |
Specifically, I'm trying to get the hold expires from shelf soon to run for a test. |
| 15:43 |
Dyrcona |
I have it set up with -2 days delay and a granularity of daily. |
| 15:43 |
Dyrcona |
I have other daily granularity events that ought to fire, too. |
| 15:43 |
mmorgan |
Dyrcona: Is the event definition enabled? |
| 14:46 |
aabbee |
yes, sorry. |
| 14:47 |
aabbee |
well, it's an angular6 question. not much of an evergreen question. |
| 14:47 |
rhamby |
aabbee: I think the first part is really specific but I'll pass on the question about debugging |
| 14:48 |
sandbergja |
I just threw a question into the livestream, but I'll repeat it here: How much have y'all been using the ng generate command in the ang6 cli? More broadly, what is the best way to get started with a new module, component, etc.? |
| 14:50 |
sandbergja |
Thanks! |
| 14:50 |
|
abowling1 joined #evergreen |
| 14:50 |
sandbergja |
I have another one: what about the e2e tests? |
| 14:51 |
rhamby |
sandbergja: ah, we shut down, but they might see it here in channel |
| 14:51 |
sandbergja |
berick++ |
| 14:51 |
Bmagic |
berick++ |
| 14:51 |
rhamby |
berick: gmcharlt: any objections to posting the archived video on the channel later? |
| 14:52 |
gmcharlt |
no objection from me |
| 14:52 |
berick |
rhamby: no objection |
| 14:52 |
sandbergja |
gmcharlt: berick: I'm curious about the e2e folder in the ang6 code. Is there a plan to write e2e tests for the ang6 app? |
| 14:53 |
sandbergja |
or is it ng cli boilerplate? :-) |
| 14:53 |
berick |
sandbergja: it's cli boilerplate :) |
| 14:53 |
berick |
we do have unit tests |
| 14:53 |
berick |
'npm run test' |
| 14:53 |
sandbergja |
oh cool! where do the unit tests live? |
| 14:54 |
berick |
sandbergja: along with the code, it's very handy. e.g. eg2/src/app/core/idl.spec.ts |
| 14:56 |
sandbergja |
Cool! I will take a look |
| 14:58 |
aabbee |
clarification on my question earlier: "ERROR Error: "[object Object]" core.js:1673" is a very specific error message, you're right. but i've seen that exact message (same line number and everything) for wildly different mistakes. |
| 16:16 |
ejk |
eby: csharp says "yes" |
| 16:16 |
eby |
thanks ejk |
| 16:18 |
ejk |
(too many /e.{2}/ nicks from aadl) |
| 16:24 |
kmlussier |
If anyone is looking for easy branches to test at the hack-a-way (or for those following along from home), I'm really hoping all of my pullrequests can be reviewed before I leave. It looks like I only have two at the moment. |
| 16:24 |
kmlussier |
bug 1755543 |
| 16:24 |
pinesol |
Launchpad bug 1755543 in Evergreen 3.1 "web client: Replace spine label settings descriptions with help tips" [Low,Confirmed] https://launchpad.net/bugs/1755543 |
| 16:25 |
kmlussier |
bug 1783602 |
| 16:25 |
pinesol |
Launchpad bug 1783602 in Evergreen "Copy counts should be removed from metarecord search results page" [Medium,New] https://launchpad.net/bugs/1783602 |
| 16:26 |
kmlussier |
remingtron++ |
| 16:26 |
remingtron |
I'll start looking at the first one, 1755543 |
| 16:43 |
remingtron |
kmlussier: how do you get to the "print spine labels" screen? |
| 16:43 |
kmlussier |
If you pull up an item on the item status screen, there is a Print Labels options under Show in the actions menu. |
| 16:44 |
kmlussier |
It's also available from copy buckets and holdings view, but I usually use item status in my testing. |
| 16:44 |
remingtron |
kmlussier: thanks |
| 16:46 |
pinesol |
[evergreen|Bill Erickson] LP#1789747 SharedWorker sanity checks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe6bd46> |
| 16:46 |
pinesol |
[evergreen|Bill Erickson] LP#1789747 More SharedWorker sanity checks for egLovefield - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=66f3d11> |
| 08:31 |
pinesol |
[evergreen|Jason Boyer] LP1796988: Fix Saving Last Copy Template - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f709f27> |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:34 |
Dyrcona |
JBoyer++ # timing |
| 08:35 |
JBoyer |
Dyrcona++ # testing |
| 08:35 |
Dyrcona |
Well, Janet Schrader did the actual testing, I just installed it. |
| 08:36 |
JBoyer |
So long as it gets in, ++'s all around. |
| 08:36 |
Dyrcona |
:) |
| 08:37 |
Dyrcona |
We're backporting it to production, 3.0.13. |
| 13:25 |
Dyrcona |
pingest.pl will reingest all record attributes. It calls metabib.reingest_record_attributes with just the id and prmarc arguments. |
| 13:26 |
plux |
great…I must say I’m really appreciating that script |
| 13:26 |
Dyrcona |
Are you upgrading to 3.2? |
| 13:27 |
plux |
third run at it….upgrading on a test system with an eye to going production |
| 13:27 |
plux |
mostly all well but hit some issues so redoing the db updates on a fresh db dump |
| 13:30 |
Dyrcona |
Took me a few tries to get our db upgrade just right, too. I've upgraded training. We anticipate going to 3.2 in the spring. |
| 13:32 |
plux |
overall, it looked pretty good but the few issues I did have had to fixed. I’d like to start with a fresh schema. This one is upgraded many times - |
| 13:35 |
Dyrcona |
Everyone's schema has been upgraded a few times. |
| 14:43 |
* berick |
needs to figure out the package-lock.json stuff |
| 14:44 |
berick |
i thought it would magically do stuff, but so far it's just in the way |
| 14:44 |
miker |
heh |
| 14:46 |
Dyrcona |
I've not been committing from a built Evergreen, so it only bothers me when I try to rebase on one of my test vms to pick up the latest code. |
| 14:47 |
|
hbrennan joined #evergreen |
| 14:49 |
miker |
I was having problems that were solved by adding ngx-device-detector, so I think that's the only actual addition to package.json. the rest was just version stuff |
| 15:04 |
pinesol |
[evergreen|Remington Steed] Docs: Update old command osrf_ctl.sh to osrf_control - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9bb271b> |
| 13:29 |
|
Ryan_LGPL joined #evergreen |
| 13:30 |
Ryan_LGPL |
Hi! I have a question about automatic opening cash drawers, and Evergreen! |
| 13:31 |
Ryan_LGPL |
We just got a new cash drawer at my library, because the old one's latch was broken, and wouldn't stay closed anymore, without extreme effort. |
| 13:32 |
Ryan_LGPL |
The replacement drawer does not (Though it didn't state this in the advertisement) have a manual open button...it only opens with the key. It's an EOM-POS cash drawer. It does plug into our printer, and DOES respond to the test button in the printer settings for testing whether our printer can trigger the latch. |
| 13:33 |
Ryan_LGPL |
How can I get Evergreen to send the signal to the printer to trigger the cash drawer? Also, is it possible to get it to only do so when printing receipts for actual financial transactions, and NOT when printing due date slips? |
| 13:33 |
jeff |
A few options here. |
| 13:34 |
jeff |
Depending on the printer and the print driver, you should be able to configure it so that it does a "drawer kick" after every print job. |
| 13:34 |
Ryan_LGPL |
Printer is a TSP100u. I can't find any settings in it's settings for the printer/cashdrawer interaction, aside from the test button that confirms that it CAN send the code to open the drawer |
| 13:36 |
jeff |
If you'd like to only "kick" the drawer open for certain kinds of receipts, you might be able to do this by creating a second windows printer object for the same device, and configuring only that printer to send the drawer kick at the end of jobs, and then using Evergreen printer contexts to send certain receipt templates to that printer that kicks. |
| 13:37 |
jeff |
Some printers support a "control font" and certain characters printed with that control font do certain things. Older (much older) printers only supported escape codes, which required certain hex values to make their way from the app to the printer without being transformed along the way. That's not likely to work these days. |
| 13:37 |
jeff |
But if the printer supports a control font you might be able to configure a "drawer kick" command in a receipt template that way. |
| 14:07 |
pinesol |
csharp: vacuum full; strong opinions; data; Data from TNG; simple fixes to scary-looking problems; and all the things |
| 14:08 |
|
jihpringle joined #evergreen |
| 14:08 |
csharp |
@hates |
| 14:08 |
pinesol |
csharp hates dojo_hold_policies_interface; SIP; when libraries purchase third party products without testing and blame Evergreen for it not working; reports; the fact that the Base Filters is unnecessarily greyed out when applying an Aggregate Filter and vice versa; evil; reports more; reports even moar; details; reports even more; the fact that the Base Filters is unnecessarily greyed out when (2 more messages) |
| 14:08 |
csharp |
@more |
| 14:08 |
pinesol |
csharp: applying an Aggregate Filter and vice versa even more; having to teach SIP2 client vendors about the SIP2 specification; troubleshooting reports; money reports; marc; reports even more than before; the EDI ruby bits; acquisitions; <quote>fun<unquote>; edi; sip2; sip too; sip two; acq; acq more; acq way more than before; omg I hate acq; omg I love acq; hate hate hate; comcast; action_triggers; (1 more message) |
| 14:08 |
csharp |
@more |
| 16:11 |
Bmagic |
probably more like 4 years ago... geez |
| 16:11 |
bshum |
I'm reading off old emails from 2014/15 era |
| 16:12 |
bshum |
So yeah |
| 16:15 |
Bmagic |
thanks yall, off to the test server for many hours |
| 16:46 |
Bmagic |
I just printed to a Dymo printer from the web client using Hatch |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
jeff |
Bmagic++ |
| 17:17 |
Bmagic |
Anyone here have a Dymo printer? |
| 17:18 |
rhamby |
heh, probably in a box somewhere in the garage |
| 17:19 |
sandbergja |
Bmagic: we've got one! We don't use Hatch, though |
| 17:19 |
Bmagic |
Looking for someone to test drive this code with Webby/Hatch/Dymo |
| 17:19 |
Bmagic |
It might be a matter of adjusting the template to get the label to print in the upper left corner or something like that |
| 17:20 |
Bmagic |
(I don't have the physical printer, just the driver installed. Not getting errors now. Had a library on the phone and got it to print out a blank label but they had to go) |
| 17:27 |
alynn26 |
I have a dymo let me try, which server do you want me to use? |
| 17:55 |
alynn26 |
Ok |
| 17:57 |
alynn26 |
set it as the default, same thing. I have a Dymo LabeWriter 450 Duo. |
| 17:58 |
Bmagic |
alynn26: thanks for trying! I am hacking more on it next week. |
| 17:58 |
alynn26 |
Ok, if you want me to do some testing, let me know. Just email me. |
| 17:58 |
Bmagic |
right on! Thanks |
| 17:58 |
alynn26 |
good night. |
| 18:08 |
|
jvwoolf joined #evergreen |
| 11:04 |
Dyrcona |
Only thing you can do is setup a proxy and drop duplicate requests. |
| 11:05 |
* Dyrcona |
has looked into the general problem of double form submissions. |
| 11:05 |
Dyrcona |
I should say, the proxy is the only thing you can do that would be 100% effective. |
| 11:07 |
JBoyer |
Sure, it can't really stop anyone determined, or multiple people actually submitting the same search, I don't mind that. But I just did a simple test where I held down enter until I it looked like the screen was about to change and got 108 identical searches. |
| 11:08 |
Dyrcona |
JBoyer: Sounds about right. |
| 11:10 |
JBoyer |
Interesting thing about doing that though, you can get a rough idea of how well your load balancer spreads things around. ;) |
| 11:10 |
Dyrcona |
Or doesn't spread things around. :) |
| 11:46 |
rhamby |
kmlussier: ok, I might as well cancel the karoake rental then.... |
| 11:46 |
kmlussier |
rhamby: There's no reason you can't do karoake! I'm sure somebody will post the video so that I can enjoy it. |
| 11:50 |
Dyrcona |
:) |
| 11:51 |
kmlussier |
If anyone is looking for a quick and easy patch to test, there's bug 1783602 |
| 11:51 |
pinesol |
Launchpad bug 1783602 in Evergreen "Copy counts should be removed from metarecord search results page" [Medium,New] https://launchpad.net/bugs/1783602 |
| 11:56 |
plux |
cqqqqq |
| 11:58 |
|
mmorgan1 joined #evergreen |
| 12:26 |
JBoyer |
We remove age protection the day it "expires" and also automatically roll some 'blah blah new' circ mods to regular old 'blah blah' |
| 12:27 |
JBoyer |
An automated script is really the only way to do it. It could be made into a srfsh script, or something that uses the CronScript perl modules, but the end result is the same. |
| 12:27 |
jwoodard |
We remove ours monthly from new items |
| 12:27 |
mmorgan |
Also, I have not tested this, but I remember discussion about the ability to set up a hold policy that consults an age hold protection rule based on other selections in the hold policy. |
| 12:29 |
jwoodard |
as we have grown we are encountering more special cases where age protection would be nice |
| 12:29 |
jwoodard |
but we do not want to increase the workload |
| 12:30 |
jwoodard |
how does the "item age<" field function? |
| 14:01 |
jeffdavis |
cool, thanks |
| 14:16 |
gmcharlt |
kmlussier: ping |
| 14:16 |
kmlussier |
gmcharlt: Yes? |
| 14:17 |
gmcharlt |
kmlussier: I'm wrapping up testing of the branch for bug 1746536 |
| 14:17 |
pinesol |
Launchpad bug 1746536 in Evergreen "web client: cannot edit vol/call number in item status" [Medium,Confirmed] https://launchpad.net/bugs/1746536 - Assigned to Galen Charlton (gmc) |
| 14:17 |
gmcharlt |
I've verified that Janet's testing in commit 27 also works for me in the current branch |
| 14:17 |
gmcharlt |
and I"m no longer seeing the issues reported in comments 23 and 24 |
| 14:18 |
gmcharlt |
before I merge, was there anything else you're aware of holding up that one? |
| 14:18 |
kmlussier |
gmcharlt: I'm confident that the previous bug fix has addressed the issues I found. Those were the only two issues. |
| 14:18 |
gmcharlt |
ok, great |
| 14:18 |
gmcharlt |
merging now |
| 14:24 |
pinesol |
[evergreen|Mike Rylander] LP#1746536: Restrict CN addition but allow CN edits... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cd17f1> |
| 14:24 |
pinesol |
[evergreen|Kathy Lussier] LP#1746536: Remove input-group-addon class from Add Call Number button - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f6d7999> |
| 14:25 |
|
khuckins joined #evergreen |
| 14:25 |
berick |
if anyone's feeling adventurous, I've found the patch for bug #1797923 to be helpful in my webstaff testing |
| 14:25 |
pinesol |
Launchpad bug 1797923 in Evergreen 3.1 "Browser client iframe (catalog, etc.) loading page" [Undecided,New] https://launchpad.net/bugs/1797923 |
| 14:25 |
berick |
before tomrrow's release cut, i mean |
| 14:26 |
|
yboston joined #evergreen |
| 17:31 |
|
khuckins joined #evergreen |
| 17:35 |
dbwells |
berick: I think it is mentioned in the tangle of bugs listed on #1731272, but I might be mistaken. It seems your branch fixes some things on that bug, so maybe it deserves to be separated out to a new bug for clarity anyway. |
| 17:36 |
berick |
dbwells: ok, just making sure the patch didn't introduce a bug |
| 17:37 |
dbwells |
berick: No, sorry if I implied that. In my testing your branch made 'default view' go from majorly broken to considerably less broken. |
| 17:38 |
dbwells |
in my experience |
| 17:39 |
jihpringle |
default view is fixed in the patches on LP 1724348 and LP 1731272 but neither have made it into a release yet |
| 17:39 |
pinesol |
Launchpad bug 1724348 in Evergreen 3.1 "Web client: set default view not sticky" [Undecided,Confirmed] https://launchpad.net/bugs/1724348 |
| 17:39 |
pinesol |
Launchpad bug 1731272 in Evergreen 3.1 "web client: "Set default view" breaks record page loading" [High,Confirmed] https://launchpad.net/bugs/1731272 |
| 09:01 |
* pinesol |
grabs some Shamrock Shakes for _bott_ |
| 09:03 |
_bott_ |
I do like the Shamrock Shake |
| 09:03 |
* kmlussier |
has never had a Shamrock Shake. :( |
| 09:04 |
Dyrcona |
Ah ha! That test that fails on 3.0.13 but succeded on master last night is broken on 3.0.13. It's looking for the wrong number. I guess I'll fix that. |
| 09:07 |
Bmagic |
Wrong number, please hang up and try again. If you feel that you have reached this recording in error...... |
| 09:13 |
Dyrcona |
tests+- |
| 09:14 |
JBoyer |
berick, kmlussier, re: copy notes post-3.1, in addition to skipping the migration script I went as far as putting the field back in the copy editor since we have so many libraries on both sides of the xul/web line. There are a large number of local commits I'm looking forward to throwing away once we upgrade next month... |
| 09:14 |
cesardv |
Bmagic: https://www.youtube.com/watch?v=NI_wyiY4vyk |
| 09:14 |
cesardv |
lol |
| 09:16 |
Bmagic |
cesardv: this is the one I was thinking of: https://www.youtube.com/watch?v=37aHq3WDe-w |
| 09:17 |
cesardv |
Bmagic: ah yeah, I've heard that variation before... |
| 09:17 |
Bmagic |
It's a bygone era |
| 09:29 |
JBoyer |
sooo, who has a test install of the latest 3.2? I'm getting failures to load item status with this error: vendor.bundle.js:6 TypeError: Cannot read property 'filter' of null at item.js 162 |
| 09:30 |
pinesol |
[evergreen|Dan Wells] LP#1796971 Wait for call number and copy before loading locations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=193f06d> |
| 09:30 |
pinesol |
[evergreen|Dan Wells] LP#1796978 Realign working copy refresh with proper condition - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f64ec2e> |
| 09:30 |
JBoyer |
That line is filtering on copy alerts to only display the count of non-ack'd alerts attached to the item and it's failing for copies with and without alerts. |
| 14:09 |
pinesol |
Launchpad bug 1795906 in Evergreen "Bring parity to the estimated queue position in OPAC and Record -> View Holds UIs" [Medium,New] https://launchpad.net/bugs/1795906 |
| 14:51 |
|
abowling joined #evergreen |
| 14:53 |
Dyrcona |
jeffdavis: Just run master. It isn't as scary as it sounds. :) |
| 14:53 |
jeffdavis |
heh |
| 14:56 |
|
khuckins_ joined #evergreen |
| 15:01 |
jeffdavis |
Dyrcona: the amount of testing we do before an upgrade means we usually only do one big upgrade per year - usually shortly after a major version release, at which point there's not much difference from master. Then we backport fixes as required. |
| 15:02 |
Dyrcona |
jeffdavis: Perfect candidate for running master in that case. |
| 15:02 |
jeffdavis |
This year with the switch to the web client we have more backports than usual. We did a minor upgrade from 3.1.0 to 3.1.4 and will probably do another minor release upgrade next month. |
| 15:02 |
Dyrcona |
We just upgraded from 3.0.8 to 3.0.12 and I installed the patches for 3.0.13 last night. |
| 15:14 |
JBoyer |
berick++ |
| 15:14 |
JBoyer |
berick++ |
| 15:15 |
JBoyer |
I've been looking at things on and off; very glad you had time to knock it out. |
| 15:18 |
JBoyer |
I'll test that branch out, but something that occured to me when I was looking earlier is that applyControlFunctions will always only look at the default columns since it's called before the columns are loaded. |
| 15:19 |
JBoyer |
Not really knowing where those are used I'm not sure how to even verify that at the moment. |
| 15:20 |
berick |
JBoyer: that should be OK |
| 15:20 |
berick |
that's most setup for future actions |
| 15:20 |
berick |
*mostly |
| 15:21 |
JBoyer |
Sounds good then. I didn't figure it would affect this, but wondered if it would matter later. |
| 15:30 |
|
khuckins joined #evergreen |
| 16:15 |
JBoyer |
bug 1798170 is tested, signed, etc. and all around happier with the order of operations. |
| 16:15 |
pinesol |
Launchpad bug 1798170 in Evergreen "Custom grid columns fail to display on initial load" [Undecided,New] https://launchpad.net/bugs/1798170 |
| 16:31 |
* kmlussier |
shakes her head at JBoyer's Carly Rae Jepsen impersonation on bug 1798170. |
| 16:31 |
pinesol |
Launchpad bug 1798170 in Evergreen "Custom grid columns fail to display on initial load" [Undecided,New] https://launchpad.net/bugs/1798170 |
| 17:03 |
Bmagic |
yeah, I am starting to learn that |
| 17:03 |
Bmagic |
It seems possible that xul users could make the old style alert though |
| 17:03 |
Bmagic |
will the web client respect the old alert? |
| 17:04 |
jeff |
and it isn't sufficient to just hold off on using the feature in new ways. the upgrade script migrated legacy copy alerts in a way that made them at least no longer visible / editable by the xul client, even if they continued to fire. |
| 17:05 |
jeff |
i do not think we've yet tested if the code supports the legacy copy alert message in the web client, or if we need to revert/change some things there until we're off xul. |
| 17:05 |
|
mmorgan left #evergreen |
| 17:05 |
jeff |
it was a late discovery in pre-upgrade planning process for us when we jumped from 2.10 to 3.1. |
| 17:06 |
Dyrcona |
The test server isn't testing, or is it just not posting to the channel? |
| 17:06 |
berick |
jeff: are you just using the browser client for all copy-alert related stuff? |
| 17:07 |
jeff |
berick: no, we skipped the migration of copy alerts in the relevant upgrade script, so our legacy alerts remain in-table. |
| 17:07 |
|
stephengwills left #evergreen |
| 17:22 |
jeff |
I have a local todo to look into it. I have a suspicion that it might be messy. The web client probably sees the alerts at checkin/checkout but probably can't successfully modify them, at least not in a way that doesn't lead to alert message bifurcation. :-) |
| 17:31 |
|
cesardv joined #evergreen |
| 17:43 |
|
khuckins_ joined #evergreen |
| 17:57 |
bshum |
Dyrcona: I'm pretty sure the test server isn't posting to channel because phasefx has to rebuild it out of Wheezy and into Stretch or some other supported distro |
| 17:57 |
bshum |
So yeah, no telling how long it's been since the last successful test run :\ |
| 17:58 |
bshum |
I haven't run one in awhile myself. |
| 18:00 |
|
khuckins joined #evergreen |
| 18:36 |
|
nfburton joined #evergreen |
| 18:47 |
Dyrcona |
bshum: I'm just curious if it is having failures. On rel_3_0, I'm getting live_t/20-hold-targeter.t failing, on master on Ubuntu 18, live_t/09-lp1198465_neg_balances.t fails for me. |
| 18:48 |
Dyrcona |
tests+- |
| 19:15 |
Dyrcona |
OK. Tests are working for me on master after reloading concerto. |
| 21:51 |
Bmagic |
What does it mean when OpenSRF::Transport /usr/local/share/perl/5.22.1/OpenSRF/Transport.pm:83 Session Error: router private.localhost/open-ils.serial IS NOT CONNECTED TO THE NETWORK!!! ? Ejabberd is messed up? Which config should I tweak do you think? |
| 22:14 |
|
beanjammin joined #evergreen |
| 11:52 |
Bmagic |
Right now, I am favoring fedora with KDE (if someone made me switch today) |
| 11:53 |
bshum |
berick: Oooo pretty :D |
| 11:53 |
* Dyrcona |
used to work on KDE and wouldn't recommend it. They broke everything in KDE 4 and decided to release it half-finished. |
| 11:53 |
Bmagic |
I've heard that too but in testing, everything seems to work for me |
| 11:53 |
Dyrcona |
Well, they've had time to finish more stuff since then. :) |
| 11:54 |
Bmagic |
Starcraft 2 doesn't work so well in wine on my GPU on Gnome or KDE... so there's that |
| 11:54 |
Dyrcona |
I left about the time 2.0 was done because my daughter was born and no more time. |
| 12:32 |
mmorgan |
s/bit/but |
| 12:36 |
Dyrcona |
mmorgan: Thanks. All of our print notices are sort on usr. |
| 12:37 |
Dyrcona |
Our lost print notice has an extra loop to sort by target_copy.call_number.owning_lib, and before I started running these in parallel it worked. |
| 12:38 |
Dyrcona |
The other od print notices work, so I assume the failure is related to this second sort, but I'm still waiting on test results. |
| 12:56 |
* Dyrcona |
thinks we're going back to the old settings... |
| 13:22 |
|
jvwoolf joined #evergreen |
| 13:58 |
jeff |
Just a few short days after the LoC MARC site outage, and I'm getting bibs from OCLC with no 245. |