| Time |
Nick |
Message |
| 04:09 |
|
beanjammin joined #evergreen |
| 06:08 |
|
rlefaive joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:28 |
|
rjackson_isl joined #evergreen |
| 07:29 |
|
Dyrcona joined #evergreen |
| 07:53 |
|
krvmga_ joined #evergreen |
| 08:06 |
|
rlefaive_ joined #evergreen |
| 08:23 |
JBoyer |
Hey, it's everyone's favorite game, let's run a random query! I'm curious what kind of numbers people get back from this: select count(id) from actor.usr where not deleted and id not in (select usr from actor.usr_setting where name ='opac.hold_notify'); |
| 08:24 |
JBoyer |
Ours is... rather high. (and we're getting complaints about not getting notifications, etc.) |
| 08:29 |
Dyrcona |
Well, you won't get notified if you don't ask to be notified. |
| 08:31 |
JBoyer |
No, but there appears to have been a change in "something" recently. it looks like for a while if you didn't change the default settings from phone:email that didn't get stored, and if you didn't have an opac.hold_notify entry in aus they were checked by default when placing a hold. |
| 08:31 |
JBoyer |
And now they're not. :/ |
| 08:32 |
Dyrcona |
IDK. I'm trying to figure out some tricky stuff in git. |
| 08:33 |
JBoyer |
Is there anything else *in* git? ;) |
| 08:34 |
JBoyer |
I've been pointed toward a couple of bugs that imply that we're not suddenly missing a ton of aus entries, so now I've got some leads to start following. |
| 08:34 |
Dyrcona |
And no matter what I do, I end fixing conflicts, either between 3.0 and master, or with files that only exist in my customization branch! |
| 08:35 |
Dyrcona |
Or, I use an option that avoids the conflicts between 3.0 and master, I lose my local commits. :( |
| 08:37 |
JBoyer |
I assume it's too hairy to just format-patch your local commits and reapply after choosing the latter? |
| 08:37 |
Dyrcona |
And, I don't know what to do with these... I think I should just interactive rebase a copy of the custom branch to get rid of redundant commits to files. |
| 08:37 |
Dyrcona |
I never use format-patch. I could try. |
| 08:38 |
JBoyer |
It will still probably run into either a conflict or a lot of fuzz, but it would be only 1 potential conflict to resolve vs up to 3. |
| 08:38 |
Dyrcona |
Trouble is the branch has a crazy history of cherry-picks mixed with merges, because I got lazy resolving all the conflicts caused by cherry-picking from krvmga's branch. |
| 08:40 |
Dyrcona |
This is what you run into when you base your customizations on a rel_* branch and not on master. |
| 08:40 |
JBoyer |
Ah. I suppose that's why I've seen multiple references to not cherry picking (doesn't help, obviously, but I've not encountered whatever problems they were warning against) |
| 08:40 |
Dyrcona |
You name it, I've encountered it. :) |
| 08:40 |
Dyrcona |
I'm generally opposed to cherry-picking, now. |
| 08:41 |
Dyrcona |
And my quikpick script doesn't. |
| 08:41 |
Dyrcona |
When I cherry-pick, I get conflicts with changes in our own files. |
| 08:42 |
Dyrcona |
And, well, that shouldn't happen, but I think It's because merging messed with the history vs. the cherry-picks. |
| 08:42 |
Dyrcona |
So, I suppose the lesson here is: cherry-pick xor merge. |
| 08:42 |
Dyrcona |
I.E. don't do both. |
| 08:43 |
JBoyer |
I've got a 10+ entry series of blog posts about not cherry-picking I was planning to read when I've got time to think about it, maybe if it's something that can be condensed into a conversation it might be worth discussing alternatives in May. |
| 08:55 |
|
bos20k joined #evergreen |
| 08:56 |
Dyrcona |
Hm... Looks like I have the same commit twice in the history.... |
| 08:58 |
Dyrcona |
More than 1. |
| 08:58 |
Dyrcona |
I think that other branch is kind of hosed. |
| 08:59 |
|
mmorgan joined #evergreen |
| 09:01 |
|
kmlussier joined #evergreen |
| 09:04 |
mmorgan |
JBoyer: Regarding your random query - did you mean "id in (select usr from actor.usr_setting ...)"? |
| 09:04 |
mmorgan |
looking for folks with notification prefs? |
| 09:06 |
JBoyer |
Looking for those without them. |
| 09:07 |
Dyrcona |
JBoyer++ # fomat-patch mostly worked. |
| 09:07 |
JBoyer |
It seems that no setting == 'phone:email' but that's not the case everywhere anymore. |
| 09:07 |
JBoyer |
Glad to hear it helped! I just hoped it wouldn't make things much worse. |
| 09:07 |
Dyrcona |
I had to delete 7 redundant patches, including 2 where the 1st was later reverted and a 3rd where some files were deleted from one of the 3 branches that the source branch was based on. |
| 09:08 |
|
rlefaive joined #evergreen |
| 09:08 |
JBoyer |
That does sound like it would have been awful to do any other way. |
| 09:08 |
kmlussier |
JBoyer: Is this related to bug 1361258. Notification preferences weren't saving correctly in some cases in the web client. |
| 09:08 |
pinesol_green |
Launchpad bug 1361258 in Evergreen 3.0 "Patron accounts losing notification preferences" [High,Fix released] https://launchpad.net/bugs/1361258 |
| 09:08 |
Dyrcona |
I forgot to mention that the other branch started out as 2 separate branches, where krvmga and I had our own versions of each, so four, really. |
| 09:09 |
Dyrcona |
And somehow 4 commits were doubled. |
| 09:11 |
mmorgan |
JBoyer: 604304 without notification prefs |
| 09:12 |
dbs |
JBoyer: 121047 without notification prefs (2.12 system fwiw) |
| 09:13 |
JBoyer |
kmlussier, it's similar. I think that some users may have had their prefs wiped out (as in not in aus at all) and while those accounts still have phone and email checked in the XUL editor, they don't in the web editor. (And also not when placing holds as staff...) |
| 09:14 |
|
rlefaive joined #evergreen |
| 09:18 |
kmlussier |
JBoyer: Looking at the original description on that bug, which is from the 2.5 days, it sounds like, even when the checkboxes were selected in the xul editor, it didn't actually set the preferences. |
| 09:19 |
* kmlussier |
is now looking at really old LP bugs to remember previous behavior. |
| 09:20 |
kmlussier |
For placing holds, it looks like the previous behavior was to automatically select email and phone if there were no preferences in the patron record. Is it not doing that anymore? |
| 09:20 |
* kmlussier |
is looking at bug 980988 |
| 09:20 |
pinesol_green |
Launchpad bug 980988 in Evergreen "Tpac - default notifications during hold placement" [Medium,Fix released] https://launchpad.net/bugs/980988 |
| 09:21 |
JBoyer |
We're hearing no. The web editor is also not checking them when loading an account without an aus entry |
| 09:22 |
JBoyer |
I haven't double-checked the OPAC, but the difference in editors is definitely there. |
| 09:26 |
JBoyer |
And yes, placing a hold for a user in the web client opac with no opac.hold_notify aus means no notifications. :/ |
| 09:26 |
kmlussier |
Personally, I found it confusing that the checkmarks appeared in the xul editor when there were no notification preferences set. |
| 09:28 |
kmlussier |
But I agree it is a problem that there is no default on the place hold page when a user hasn't taken the time to set notification preferences. |
| 09:29 |
JBoyer |
Since the default for missing is phone:email, I kind of like that the editor shows that. There's no way for staff to tell the difference between "they never set anything" and "they turned everything off" |
| 09:30 |
JBoyer |
No way aside from asking us to look in the database, that is. |
| 09:33 |
JBoyer |
Although, if the fix for bug 1361258 just makes sure that something is always saved for that setting, I suppose there's no reason we can't just add all of the missing entries and stop worrying about it... |
| 09:33 |
pinesol_green |
Launchpad bug 1361258 in Evergreen 3.0 "Patron accounts losing notification preferences" [High,Fix released] https://launchpad.net/bugs/1361258 |
| 09:34 |
kmlussier |
Well, I still think having no defaults on the place hold screen in the absence of a setting is a bug. |
| 09:34 |
* kmlussier |
is checking to see if the fix really does what JBoyer just described. |
| 09:35 |
* JBoyer |
was also about to register a new throwaway patron, but now will wait. ;) |
| 09:36 |
|
mmorgan1 joined #evergreen |
| 09:36 |
kmlussier |
JBoyer: Yes, that's what it does. I just created a new user, didn't touch the notification preferences, and there is now a user setting for that patron. |
| 09:37 |
JBoyer |
Boom! I agree that no setting should set the defaults in the opac, but as for helping our staff here, in go a half-million "defaults" |
| 09:37 |
kmlussier |
That actually may have been the behavior before that fix was put into place. The fix was to address those times when the checkboxes became deselected by navigating to different tabs. |
| 09:39 |
|
rlefaive joined #evergreen |
| 09:47 |
|
collum joined #evergreen |
| 09:47 |
|
yboston joined #evergreen |
| 09:52 |
kmlussier |
JBoyer: I logged into the web client on the community demo server. I placed a hold for Concerto user Joseph Barnes, who does not have any opac preferences set yet. It is defaulting to phone notification. |
| 09:53 |
kmlussier |
I suspect it isn't defaulting to email because the user doesn't have an email address. |
| 09:53 |
kmlussier |
I wonder if something else is going on with those patrons with no defaults. Hmmm...I have a theory. |
| 09:54 |
JBoyer |
Well, the patron in question didn't have an email, but there was a phone, and still nothing. |
| 09:55 |
kmlussier |
JBoyer: I know what's going on. Yes, this is a problem. |
| 09:56 |
kmlussier |
I edit patron Joseph Barnes to add an email address. Because he has no notification settings set, the notification checkboxes aren't selected. I save the updates, the notification preferences are saved as "". |
| 09:56 |
rhamby |
kmlussier: there are no problems, only opprotunities (sometimes for more opprotunities |
| 09:56 |
kmlussier |
rhamby: Great! Turns out I have many opportunities in my life. |
| 09:57 |
rhamby |
kmlussier: yay! |
| 09:57 |
JBoyer |
paraphrased ancient chinese proverb: May you have many opportunities. |
| 09:58 |
JBoyer |
And we do have about 10K users with hold_notify == "". I know some of those are accurate (folks that are in nearly every day don't need us to tell them to come back) but I don't know how many. :/ |
| 10:10 |
kmlussier |
And the longer this bug is in Evergreen, the worse the problem becomes. |
| 10:13 |
JBoyer |
kmlussier, is it as simple as just changing the "empty" hold_notify value from { phone: null, email: null, sms: null } to { phone: true, email: true, sms: null } in web/js/ui/default/staff/circ/patron/regctl.js? |
| 10:15 |
kmlussier |
JBoyer: But if a patron has chosen not to receive notifications, wouldn't it negate that choice the next time you edit their record? |
| 10:16 |
kmlussier |
I was thinking it might be better if, when you edit a patron who does not have a user setting for notification, the phone and email boxes are preselected the way we currently do in the xul client. |
| 10:17 |
kmlussier |
When you save the record, the phone and email would save as the setting, which is what's currently happening with new patrons. |
| 10:17 |
kmlussier |
Or, we could consider returning to the xul behavior of not saving the setting unless the user makes an actual change. |
| 10:18 |
JBoyer |
Oh, you're right. Values are only changed *to* true, they're not set to true or false. So yeah, it has to just be smarter about missing values. |
| 10:18 |
|
tlittle joined #evergreen |
| 10:19 |
JBoyer |
I do like just setting it period though, beats having to keep track of defaults in multiple places. (my account, editor, placing holds, etc.) |
| 10:20 |
JBoyer |
And one of the 3.2 upgrade scripts could just throw them in there for every patron as part of XUL's going away party. |
| 10:36 |
|
Christineb joined #evergreen |
| 10:46 |
miker |
+1 to checking the appropriate boxen if the user setting doesn't exist, and then saving a value |
| 10:56 |
|
jwoodard joined #evergreen |
| 11:03 |
|
stephengwills joined #evergreen |
| 11:07 |
mmorgan1 |
+1 from me, too, for checking the boxes. |
| 11:08 |
|
jihpringle joined #evergreen |
| 11:10 |
|
terran joined #evergreen |
| 11:20 |
|
jvwoolf joined #evergreen |
| 11:36 |
|
beanjammin joined #evergreen |
| 12:22 |
|
khuckins joined #evergreen |
| 12:22 |
|
jihpringle joined #evergreen |
| 12:36 |
stephengwills |
I’m searching markmail and docs but not seeing quite what I need. A library has dropped out of our consortium and I’m being asked to purge thier data from our evergreen. not just mark their rows as deleted. Is there a documented procedure for doing this anywhere or should I stop looking and write it? ;-) |
| 12:38 |
jeff |
stephengwills: you should proceed carefully and with some advance planning, and not blindly run any commands recommended to you, and you should consider writing up a document, but you may want to start with some of the bits in the ESI/EOLI migration tools repo: http://git.esilibrary.com/?p=migration-tools.git;a=summary |
| 12:38 |
jeff |
stephengwills: http://git.esilibrary.com/?p=migration-tools.git;a=blob;f=remove_ou_data/README;hb=HEAD |
| 12:39 |
stephengwills |
thanks. will take a look. |
| 12:40 |
jeff |
and if it wasn't clearly implied from my "proceed carefully", i'll be explicit: do your testing on a test copy of the data. :-) |
| 12:40 |
Dyrcona |
stephengwills: A quick perusal suggestions that will do what you want. |
| 12:41 |
Dyrcona |
s/suggestions/suggests/ |
| 12:41 |
Dyrcona |
And, yeah, proceed with caution. |
| 12:41 |
rhamby |
stephengwills: I do that periodically for customers and use that repo (it has a few commits from me in it) but I'd recommend running it against a test system first |
| 12:41 |
Dyrcona |
It might be a good idea to shut down everything else that talks to the database when you do it for real. |
| 12:42 |
rhamby |
stephengwills: there are situations that can come up that don't necessarily have a good universal answer so those aren't necessarily addressed in there |
| 12:42 |
rhamby |
stephengwills: also you may want to time it, some steps can be pretty slow. I work around that in various ways depending on the situation but again, they aren't in there because they are decisions for local admins to make |
| 12:43 |
stephengwills |
yeay migration tools :). I’ll def play on a copy ffirst. |
| 12:43 |
rhamby |
stephengwills: and check your db version, if you're on 3.0+ there may be some additional steps needed that I haven't done commits for yet because I'm still testing them |
| 12:43 |
stephengwills |
I already suggested that we delete everything at once and everyone open pizza shops around the state but that didn’t fly. |
| 12:44 |
rhamby |
stephengwills: how about thai? |
| 12:44 |
Dyrcona |
drop database .... |
| 12:44 |
stephengwills |
see? that’s why I check in here. good idea Rogan |
| 12:44 |
stephengwills |
et. al. |
| 12:44 |
Dyrcona |
There's lots of neat stuff in that migration-tools repo. It's definitely worth giving the rest of it a look. |
| 12:45 |
* Dyrcona |
goes back to puzzling over how custom code is "working" when it is not installed. :) |
| 12:45 |
* rhamby |
plays the Outer Limits theme music for Dyrcona |
| 12:46 |
|
ngf42 joined #evergreen |
| 12:46 |
Dyrcona |
"The Girl I Knew Somewhere" by The Monkees is good enough. :) |
| 12:46 |
Dyrcona |
Yeah, yeah, I am listening to The Monkees at the moment. |
| 12:47 |
|
jihpringle joined #evergreen |
| 12:47 |
|
abowling joined #evergreen |
| 12:49 |
berick |
Dyrcona: just because they were on Scooby Doo doesn't mean they don't have great songs. |
| 12:50 |
Dyrcona |
heh |
| 12:50 |
Dyrcona |
Well, my conclusion is the feature is implemented entirely in the database. |
| 12:50 |
Dyrcona |
And, the branches that I'm looking at are irrelevant. |
| 13:21 |
|
yboston joined #evergreen |
| 13:55 |
|
beanjammin joined #evergreen |
| 13:59 |
|
abowling1 joined #evergreen |
| 14:04 |
JBoyer |
Sanity check for anyone with some acq experience: You can't add a bib to a PO after it's activated, right? |
| 14:04 |
berick |
JBoyer: right |
| 14:04 |
JBoyer |
berick++ |
| 14:05 |
JBoyer |
About to reply to a ticket and really didn't want to hear "but I do this all the time!" |
| 14:05 |
berick |
it's possible you could add it, but it won't do what you want it to do. |
| 14:05 |
|
jvwoolf joined #evergreen |
| 14:06 |
JBoyer |
They're not using EDI, so I'm guessing "what they want to do" is make the number on their PO match the number on their paper invoice. I'd suggest making a note instead. |
| 14:06 |
miker |
berick: you were threatening to ask about index normalizers yesterday(?), are you still preparing for that discussion? |
| 14:07 |
berick |
miker: oh, turns out my issues were related to a local customization i was not aware of. nothing to see here. |
| 14:07 |
miker |
ah! moving along |
| 14:08 |
* kmlussier |
shudders at the thought of adding anything to an activated PO in an EDI environment. |
| 14:13 |
berick |
JBoyer: could also add a misc. charge on the invoice to track the money. there's room for notes in the charges. |
| 14:13 |
berick |
maybe even add an invoice charge type of "got some extra stuff" |
| 14:14 |
JBoyer |
Ah, yeah. I'll mention it. The next question will likely be how to get the record in (cataloger apparently just retired...) so I'm sure it'll be a multi-step resolution. |
| 14:38 |
|
rlefaive_ joined #evergreen |
| 14:39 |
|
mmorgan1 joined #evergreen |
| 14:39 |
JBoyer |
anyone using SIPServer in a mixed timezone setup? It looks like there must be some edge cases that need smoothing |
| 14:40 |
|
jeff_ joined #evergreen |
| 14:43 |
|
tsadok joined #evergreen |
| 14:45 |
|
abowling joined #evergreen |
| 15:15 |
miker |
JBoyer: you mean clients in different timezones talking to one sipserver instance? |
| 15:17 |
JBoyer |
Yeah. We have some Central time users talking to a server in Eastern. OUS are set up appropriately, things are fine when everything's done in-client, but SIP xacts are either wrong one way (without workstation) or wrong the other (with workstation) |
| 15:17 |
miker |
JBoyer: if so, I'd recommend running two instances, perhaps just on different ports, with the environment suitably adjusted for each |
| 15:17 |
miker |
s/if so//, then |
| 15:18 |
JBoyer |
Ah. Not so easy to address without tearing SIPServer down to the studs and starting again? |
| 15:19 |
miker |
well, it can deal when it has some context, as you say, but there'll usually be a mix of with and without workstation |
| 15:20 |
JBoyer |
Not when they talk to me there isn't. ;) |
| 15:20 |
miker |
heh |
| 15:20 |
miker |
well |
| 15:20 |
miker |
in any case, running more than one instance is trivial. just point at an alternate config and stick TZ='America/Chicago' in front of the central timezone instance :) |
| 15:20 |
JBoyer |
The issue is that while the circs are actually fine, the checkout reply has the dates in Eastern again. (the next morning at 00:59:59) so their users think they have another day |
| 15:22 |
JBoyer |
I'll look into it then. Just have to convince them it's worth editing their 3M configs to change the location code. That's when it will become a lot of fun. |
| 15:23 |
miker |
you could make it transparent with an IP-based redirect, if you know where they're coming from |
| 15:23 |
miker |
LET ME GIVE YOU MORE WORK, JBOYER |
| 15:23 |
JBoyer |
Hmm. true. |
| 15:24 |
JBoyer |
One more thing to research after DKIM, DMARC, and all the rest of the things I've taken a sudden interest in recently, heh. |
| 15:25 |
JBoyer |
miker++ # WERK |
| 15:42 |
|
frank__ joined #evergreen |
| 15:47 |
Dyrcona |
Werk? Werkzeug? Metrowerks? Now, that last one takes me back. |
| 15:47 |
frank__ |
Hi all, I am trying to enable the web staff client, I ran the corresponding scripts according the EG oficial documentantion, but I cannot access, In the chrome console I am getting the following error, I already checked the ports in the wide firewal and it is open, what else could I test? |
| 15:47 |
frank__ |
WebSocket connection to 'wss://bilblos.ipicyt.edu.mx:7682/osrf-websocket-translator' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED WrappedWebSocket @ VM386:164 OpenSRF.WebSocket.send @ opensrf_ws.js:62 OpenSRF.Session.send_ws @ opensrf.js:350 OpenSRF.Session.send @ opensrf.js:294 OpenSRF.Request.send @ opensrf.js:588 net.request @ net.js:123 service.login_api @ auth.js:244 service.login @ auth.js:171 $sc |
| 15:48 |
Dyrcona |
frank__: Is the apache2-websockets instance running on the server? |
| 15:48 |
Dyrcona |
you can do "ps ax | grep apache2-websockets" to check. |
| 15:49 |
frank__ |
Dyrcona: sure, this is the output: ps ax | grep apache2-websockets 4032 pts/0 S+ 0:00 grep apache2-websockets |
| 15:49 |
Dyrcona |
So, it's not running. |
| 15:49 |
Dyrcona |
You just got your grep command. |
| 15:50 |
Dyrcona |
frank__: What distribution of Linux and what version? |
| 15:50 |
frank__ |
debian-jessie |
| 15:51 |
Dyrcona |
Try this: sudo systemctl enable apache2-websockets |
| 15:51 |
Dyrcona |
Then this: sudo systemctl start apache2-websockets |
| 15:54 |
|
hbrennan joined #evergreen |
| 15:56 |
frank__ |
I am getting: Failed to execute operation: No such file or directory |
| 15:56 |
frank__ |
when running sudo systemctl enable apache2-websockets |
| 15:56 |
Dyrcona |
frank__: Sounds like you have not properly setup websockets. |
| 15:56 |
berick |
maybe: sudo apache2ctl-websockets start; |
| 15:56 |
berick |
i've had oddities with systemctl and websockets |
| 15:57 |
Dyrcona |
berick: It has worked for me on Ubuntu 16 and Debian 9. It may be an issue on Debian 8. |
| 15:57 |
Dyrcona |
systemd-- :) |
| 15:57 |
berick |
oh, hm, maybe it's because I've never tried to 'enable' it. |
| 15:58 |
Dyrcona |
Yeah, you have to enable it, then you can start it with systemctl. |
| 15:59 |
berick |
Dyrcona++ # that fixed it |
| 16:07 |
Dyrcona |
frank__: I think you missed a step or two in the OpenSRF README. |
| 16:09 |
frank__ |
Dyrcona: Do ypu have the README Opensrg link? |
| 16:10 |
frank__ |
I goit in the opensrf zip file, Isnt it? |
| 16:10 |
abneiman |
|
| 16:10 |
Dyrcona |
frank__: Yes, it is in the zip file. |
| 16:11 |
frank__ |
yes, you are right, let me follow the "Optional: Websockets installation instructions" |
| 16:12 |
Dyrcona |
You can click on Install Instructions for the appropriate OpenSRF version here: https://evergreen-ils.org/opensrf-downloads/ |
| 16:13 |
Dyrcona |
Those really should not be considered optional any more. |
| 16:27 |
|
khuckins_ joined #evergreen |
| 16:31 |
frank__ |
Dyrcona: I works now, I followed the steps and it is working now, |
| 16:32 |
frank__ |
Thanks for the advices Dyrcona berick |
| 16:37 |
|
_bott_ joined #evergreen |
| 16:58 |
Dyrcona |
frank__: That's good. |
| 16:58 |
* Dyrcona |
was eating. |
| 17:04 |
|
abowling1 joined #evergreen |
| 17:13 |
|
mmorgan1 left #evergreen |
| 17:22 |
|
khuckins joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 22:29 |
|
beanjammin joined #evergreen |
