| Time |
Nick |
Message |
| 00:01 |
|
kmlussier left #evergreen |
| 00:06 |
bshum |
So, apologies for lack of more warning, but we have a new wiki theme now that works better with our long overdue upgraded dokuwiki (last version was over a year ago) |
| 00:07 |
bshum |
Pros, the new wiki seems to be responsive (so that'll be nice for my phone viewing of berick's web client notes) |
| 00:07 |
bshum |
Cons, we may want to play more with the theme's colors, styling, etc. |
| 00:07 |
* bshum |
stops fiddling now before he gets himself in more trouble |
| 01:45 |
|
b_bonner joined #evergreen |
| 01:45 |
|
mtcarlson_away joined #evergreen |
| 06:49 |
|
timlaptop joined #evergreen |
| 07:21 |
|
gsams joined #evergreen |
| 07:45 |
|
collum joined #evergreen |
| 07:48 |
|
akilsdonk joined #evergreen |
| 07:54 |
|
rjackson-isl joined #evergreen |
| 08:20 |
|
ldw joined #evergreen |
| 08:33 |
csharp |
bshum: first impression: I like the new theme better |
| 08:37 |
phasefx |
I like how the pop-up menu overlays the icons on the side of the page (when authenticated) |
| 08:56 |
|
mmorgan joined #evergreen |
| 08:59 |
|
tspindler joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:01 |
|
Shae joined #evergreen |
| 09:02 |
|
kbeswick joined #evergreen |
| 09:27 |
|
RoganH joined #evergreen |
| 09:28 |
|
Dyrcona joined #evergreen |
| 09:32 |
|
yboston joined #evergreen |
| 09:56 |
|
Dyrcona joined #evergreen |
| 10:05 |
|
kmlussier joined #evergreen |
| 10:30 |
bshum |
csharp: I like it too, but I think the blue colored links made me look twice. |
| 10:30 |
bshum |
For some reason I think they ought to be green :) |
| 10:31 |
bshum |
But I can see the value in having them separately colored. |
| 10:35 |
|
Dyrcona joined #evergreen |
| 10:36 |
jeff |
some uncertainty if this is in chrome 35 or 36, but it looks like the long-anticipated Object.observe() has landed: http://www.html5rocks.com/en/tutorials/es7/observe/ |
| 10:37 |
jeff |
I'd guess Chrome 36 (which is currently beta), and that the Tweet from @ChromiumDev was incorrect in saying 35 |
| 10:38 |
gmcharlt |
bshum: I really like the new wiki template |
| 10:44 |
bshum |
gmcharlt: I like that it's responsive. |
| 10:44 |
bshum |
I was hoping that the dokubook theme (to mimic mediawiki) was, but it didn't turn out that way. |
| 10:45 |
bshum |
Oh good, and it works with no-JS |
| 10:45 |
bshum |
(forgot to test that too...) |
| 10:46 |
jeff |
in many ways, themes that mimic something else just end up creating more confusion because it "looks like" X but "isn't actually" X |
| 10:48 |
bshum |
True, true |
| 10:48 |
jboyer-isl |
Ugh, memories of "iOS app" wordpress mobile themes... |
| 11:27 |
|
jwoodard joined #evergreen |
| 11:38 |
mmorgan |
Revisiting a question from yesterday - I'm trying to figure out where the checkin modifier choices are stored on the workstation. Any ideas? |
| 11:40 |
|
Dyrcona joined #evergreen |
| 11:43 |
bshum |
mmorgan: Wouldn't it be obvious that something is engaged with the way the interface presents itself that a checkin modifier was enabled? |
| 11:43 |
bshum |
(just musing, I don't know the answer to the question yet) |
| 11:45 |
tsbere |
bshum: I think mmorgan means "between sessions" |
| 11:45 |
mmorgan |
bshum: Yes, it should be obvious by looking at the screen. My larger question actually is where all those sticky things in the client are stored. Checkin modifiers, checkboxes, etc. |
| 11:46 |
tsbere |
mmorgan: Have you closed the client when testing? The preferences file may not be written right away even if it is visible in about:config |
| 11:46 |
mmorgan |
tsbere: Not sure, will check that. |
| 11:47 |
bshum |
Yeah, but if they're visibly part of the checkin screen (with text/color/boxes/whatnot) why would you need to know where they're stored between sessions? Cause they seem to stick from closing out and coming back in, no? |
| 11:47 |
tsbere |
mmorgan: Beyond that, I seem to find them in the prefs.js file itself here |
| 11:47 |
tsbere |
bshum: Moving the lot of them from one server to another? |
| 11:48 |
Dyrcona |
bshum: Wanting to understand how things work, so it isn't voodoo? |
| 11:48 |
mmorgan |
Dyrcona: Exactly! |
| 11:48 |
* Dyrcona |
goes to find another chicken to sacrifice. |
| 11:48 |
bshum |
Dyrcona: Yeah, yeah, okay :) |
| 11:48 |
mmorgan |
and so when people ask my why something's happening that shouldn't, I have a clue where to look. |
| 11:48 |
bshum |
I just figure the visual clues were pretty obvious but I forget that staff don't actually read anything. |
| 11:51 |
mmorgan |
tsbere: You have solved my mystery. It is indeed in prefs.js, but not saved til I close the client. |
| 11:51 |
mmorgan |
tsbere++ |
| 11:54 |
|
vlewis joined #evergreen |
| 12:06 |
csharp |
hmm - we're having an issue where our hold available notifications are apparently not getting to patrons |
| 12:06 |
csharp |
I can see them get generated and sent successfully to each email server |
| 12:06 |
csharp |
and it's just hold notifications... overdue notifications appear to be OK |
| 12:07 |
tsbere |
csharp: Do you generate your from addresses differently between the two? |
| 12:07 |
csharp |
(worth mentioning that we're using legacy scripts to generate pre-overdue and overdue) |
| 12:07 |
csharp |
and A/T for holds |
| 12:07 |
csharp |
tsbere: probably - I'm looking into that now |
| 12:08 |
bshum |
Any specific batch of patrons? People with yahoo, AOL, etc. |
| 12:08 |
csharp |
bshum: all over the place |
| 12:08 |
bshum |
What we've noticed was a rise in issues with our A/T email notifications being rejected by certain providers. |
| 12:08 |
csharp |
and we're not blacklisted anywhere |
| 12:08 |
* tsbere |
would assume "anyone that has had DMARC come into use recently" as a likely grouping, given what he had to do to the MVLC mail server in regards to that recently |
| 12:08 |
csharp |
bshum: that's what it looks like here |
| 12:09 |
bshum |
We had to make adjustments to our SPF |
| 12:09 |
bshum |
And fix our reverse DNS entries |
| 12:09 |
csharp |
yeah, we just did that yesterday |
| 12:09 |
Dyrcona |
Comcast and AOL recently implemented DMARC. Others probably has as well. |
| 12:09 |
bshum |
To make our utility server a proper sender |
| 12:09 |
bshum |
For our domain |
| 12:09 |
csharp |
we didn't have an SPF before |
| 12:09 |
Dyrcona |
Yeah, people still use AOL. It's still a thing. |
| 12:09 |
csharp |
yeah AOL, comcast, and yahoo |
| 12:09 |
bshum |
But for folks who send from other email addresses (like one library who used a RE: yahoo.com address) it borked all their sending notices |
| 12:10 |
csharp |
windstream (which may be local) |
| 12:10 |
bshum |
Cause yahoo wouldn't let us alias as them |
| 12:10 |
bshum |
Obviously |
| 12:10 |
csharp |
bshum: ah - that might be at play too |
| 12:10 |
Dyrcona |
csharp: We have windstream here, too, but they mostly host servers up our way. |
| 12:10 |
tsbere |
We send all notices out as mailing lists that the libraries then subscribe to for replies and such |
| 12:10 |
tsbere |
Negates almost all sending issues with them |
| 12:10 |
tsbere |
At least for "who they come from" |
| 12:11 |
bshum |
csharp: I found my problems out from our mail.log from using postfix on our utility server to handle mail outgoing |
| 12:11 |
csharp |
most of our libraries have sender addresses entered |
| 12:11 |
bshum |
Just reading through the stuff took awhile |
| 12:11 |
bshum |
But patterns started to emerge fairly quickly |
| 12:12 |
csharp |
the funny thing is, the receiving servers are accepting them without complaint |
| 12:13 |
Dyrcona |
csharp: That's not funny in any sense of the word. Email can work that way: accept a message, then discard it. |
| 12:13 |
Dyrcona |
Perfectly valid, but not funny. |
| 12:13 |
csharp |
yeah - that's really unfunny, come to think of it |
| 12:14 |
Dyrcona |
Read RFC 2821 sometime....It's a wonder email works at all. |
| 12:14 |
Dyrcona |
Hmm. Maybe I should share something that I shared with bshum in private chat earlier? |
| 12:15 |
dbs |
yahoo is getting spamfiled like crazy by gmail |
| 12:15 |
Dyrcona |
Yahoo! mail is spam from my point of view. |
| 12:16 |
dbs |
Well, tell that to the poor people trying to participate in the Koha mailing list, or trying to announce code4lib journal issue 24... |
| 12:16 |
Dyrcona |
dbs: The list managers probably need to set up for DMARC. |
| 12:17 |
Dyrcona |
I have a Yahoo! account that I give to web sites that demand an email address. |
| 12:17 |
Dyrcona |
That's pretty much all I see Yahoo! as being good for. |
| 12:17 |
Dyrcona |
But, email is pretty much broken as designed, and all the work arounds just break it more. |
| 12:18 |
dbs |
So on the code4lib side, Yahoo got filtered by the list, so yeah, elm could probably fix that; but on the Koha side, yahoo mails are just getting filtered into my own gmail spam box. |
| 12:18 |
dbs |
OK |
| 12:19 |
Dyrcona |
dbs: What's in the from: header of your Koha list messages? |
| 12:20 |
jboyer-isl |
csharp: Since you said many of your libraries have sending emails entered, what kinds of domains do they have? We have so many yahoo.com email addresses here that I just hard-coded the from and stuck the "sending" address in Reply-To: |
| 12:20 |
|
ElliotFriend joined #evergreen |
| 12:21 |
jboyer-isl |
in all of our email templates, that is. |
| 12:21 |
Dyrcona |
If it just has the sender's name and email address, then DMARC isn't gonna be happy with the list messages, particular for those domains, like Yahoo, that have configured DMARC. |
| 12:26 |
Dyrcona |
FWIW, all of our notices go out with an email address at a domain (mvlc.org) that we control. This way we don't have problems with SPF or DMARC. |
| 12:27 |
Dyrcona |
Doesn't mean we don't get blacklisted from time to time. |
| 12:27 |
bshum |
That's where we're quickly headed too. |
| 12:27 |
bshum |
Or at the very least, getting rid of any FROM yahoo ones ;) |
| 12:28 |
jeff |
we send out notices as being from a subdomain of tadl.org, so that we can adjust its SPF record and such independent of tadl.org itself. |
| 12:28 |
csharp |
jboyer-isl: I'm wondering if that may be what we end up doing |
| 12:28 |
csharp |
(hard-coding the from and putting the entered email in the Reply-to) |
| 12:29 |
Dyrcona |
You also want to make sure that you're using this address for the envelope sender. That's even more important that want appears in the From: header. |
| 12:29 |
|
dkyle left #evergreen |
| 12:29 |
jboyer-isl |
It sounds like the way to go is to change the setting name and set all of the seed templates to use Reply-To, and maybe add a new setting for the "real" from address. |
| 12:30 |
jboyer-isl |
(Or, I suppose, adding a new setting for reply-to, and makeing sure that's in all of the seed templates, since that is the same effect in the end...) |
| 12:30 |
Dyrcona |
jeff++ #subdomain is even better idea. |
| 12:31 |
Dyrcona |
We use mailing lists so that multiple people at the appropriate library can get any bounce notifications. |
| 12:32 |
Dyrcona |
Then they subscribe to the list with whatever email they actually use. |
| 12:32 |
csharp |
Dyrcona: so you have a separate list for each library for that purpose? |
| 12:32 |
Dyrcona |
Yes. |
| 12:32 |
csharp |
yeah, we're big enough that I wouldn't want to go down that road if I could help it :-/ |
| 12:33 |
csharp |
"big" = number of individual units that would need to be considere |
| 12:33 |
csharp |
d |
| 12:33 |
Dyrcona |
csharp: Have you been getting a lot of bounces from the Evergreen mailing lists? |
| 12:33 |
Dyrcona |
yeah, you're significantly bigger than us. |
| 12:33 |
csharp |
actually, yes, now that I look :-/ |
| 12:33 |
Dyrcona |
DMARC. |
| 12:34 |
dbs |
Dyrcona: From: "casemall1987 yahoo.com" <casemall1987yahoo.com> |
| 12:34 |
dbs |
(sorry, got distracted by something that I had to reply to) |
| 12:34 |
dbs |
Authentication-Results: mx.google.com; spf=neutral (google.com: koha-bounceslists.katipo.co.nz does not designate permitted sender hosts) smtp.mail=koha-bounceslists.katipo.co.nz; dmarc=fail (p=REJECT dis=NONE) header.from=yahoo.com |
| 12:34 |
Dyrcona |
dbs: Yeah, looks like the Koha list software needs an update/configuration change. |
| 12:35 |
dbs |
that's an interesting one. |
| 12:35 |
dbs |
email-- |
| 12:35 |
Dyrcona |
Well, could be other reasons for it going into your spam folder. |
| 12:35 |
tsbere |
We reconfigured our mailing lists to use the list as the from in all cases. When configured to it sets the reply-to to the sender instead. |
| 12:35 |
dbs |
Google's yellow highlighted warning was that it might not have been sent by the claimed sender. |
| 12:36 |
dbs |
So it fits |
| 12:36 |
Dyrcona |
I like to describe the problem with email thusly: "People want a system where anyone in the world can send them a message at any time. Then, they get angry when they do." |
| 12:38 |
jeff |
DMARC-- |
| 12:38 |
jeff |
Yahoo-- |
| 12:38 |
dbs |
I think the "no officially supported way to upgrade from 2.4.4+ to 2.5.0" statement is insane, if true and we allow that to continue to be true. |
| 12:39 |
dbs |
If I were a competitor, I would point at that and laugh and laugh and laugh. |
| 12:39 |
* Dyrcona |
makes shameless plug for running the master branch and avoiding upgrade script issues like the ones discussed in that thread. |
| 12:39 |
csharp |
dbs++ # I completely agree with you about that |
| 12:40 |
Dyrcona |
The problem there strikes me as being when in the 2.4 lifecycle that 2.5.0 came out. |
| 12:40 |
dbs |
In the past, didn't we provide an officially supported way to upgrade by simply checking to see if the changes had already been applied and skipping over them if they had? That is to say, if we add something to the 2.4.3-2.4.4 upgrade script, we revamp the 2.4.0-2.5.0 upgrade script accordingly? |
| 12:41 |
dbs |
It's a problem that we used to handle, and then appear to have stopped handling. |
| 12:41 |
csharp |
dbs: in my experience over the last couple of years, those sorts of dead ends are not uncommon :-/ |
| 12:41 |
jboyer-isl |
jeff: I'm not sure why the dmarc-- and yahoo--, technically speaking 99%+ of email is lying about it's source, this just forces servers to be more honest. Should have been done 20+ years ago (which would have alleviated a lot of the current pain, I'll admit) |
| 12:42 |
csharp |
sometimes it takes extensive modification to get those scripts to work for us |
| 12:43 |
Dyrcona |
jboyer-isl++ # For pointing out that isn't 1989 any more. :) |
| 12:43 |
jboyer-isl |
csharp: Might it be worth considering what "fixup" scripts might have to be run to bring your db closer to the expected layout so the regular scripts work without error? Or are your issues known and deep enough that it's just going to be that way for a while? |
| 12:44 |
jboyer-isl |
And did that actually make sense? |
| 12:44 |
* csharp |
has "Fight the Power" triggered in his head by Dyrcona's last comment... "1989 a number, another summer..." |
| 12:45 |
jboyer-isl |
It's actually something I'm planning to look into once I can load another copy of production somewhere. |
| 12:45 |
csharp |
jboyer-isl: it did make sense... I think we're pretty well in line with "vanilla" EG as far as what we have in our DB - I occasionally find something we're missing that was missed several upgrades ago though ;-) |
| 12:46 |
Dyrcona |
For me upgrade scripts are as easy as psql -v eg_version=null -f Open-ILS/src/sql/Pg/upgrade/08[567][0-9]*.sql |
| 12:46 |
* bshum |
likes keying in each numbered script one at a time... but that does look fun Dyrcona :) |
| 12:47 |
jeff |
jboyer-isl: dmarc-- and yahoo-- might not be entirely fair, but the way in which yahoo implemented it certainly broke a lot of things, and continues to break a lot of things, and arguably could have been done in a better way. all that said, i'm not offering to do it. |
| 12:47 |
* Dyrcona |
actually uses this: http://git.mvlcstaff.org/?p=jason/evergreen_utilities.git;a=blob;f=scripts/db_upgrade.pl;h=2d08df2f496c2f00062e2fb2cd6b6d5b4f96dbfd;hb=cc9a96dc734997946c8027d41c9252a545dc05a8 |
| 12:47 |
jeff |
jboyer-isl: it's just unfortunate to see major changes being made to list software and list configurations in what seems like a pretty haphazard way in response to what seem to have been poorly communicated changes by a large email provider. |
| 12:48 |
jboyer-isl |
csharp: Yeah, I will only go so far back in our config.upgrade_log table for fear of what I might find 3-400 scripts ago. ;) |
| 12:48 |
* Dyrcona |
hears a familiar ring in jeff 's previous statement. |
| 12:49 |
jeff |
Dyrcona: do i want to know? :-) |
| 12:49 |
|
ldw joined #evergreen |
| 12:52 |
bshum |
dbs: In the past, I think what we were doing was leaving the numbers out of config.upgrade_log for point releases |
| 12:52 |
bshum |
And either stripping them, or leaving them as commented lines |
| 12:52 |
bshum |
So that they wouldn't cause conflicts with the major release upgrade scripts. |
| 12:52 |
bshum |
where the numbers were applied to config.upgrade_log |
| 12:52 |
bshum |
As you say, somewhere that thinking was changed |
| 12:53 |
Dyrcona |
I think the upgrades for all releases could be simplified if a simple list of needed upgrades were maintained and a Perl program read the list, compared it to config.upgrade_log and then ran the necessary upgrade scripts. |
| 12:55 |
gmcharlt |
web team meeting in 5 minutes |
| 12:55 |
bshum |
Personally, I can't say I'm super invested in the process, since I don't run regular releases. So I find it hard to think in those shoes sometimes. |
| 12:56 |
bshum |
To me, that means other people need to champion and explain to me how/why we fix it. |
| 12:56 |
* Dyrcona |
dittoes bshum despite my previous comment. |
| 12:56 |
bshum |
(not a good answer, but as much time as I have for it these days) |
| 12:56 |
bshum |
Anywho, isn't this where eeevil's long standing action item from dev meetings to write up his plan for deprecate/supercede is supposed to come in? |
| 12:56 |
dbwells |
yes |
| 12:57 |
dbwells |
I mention that (in a non-specific way) in my latest reply to that thread. |
| 13:00 |
dbwells |
I like Dyrcona's idea of just having a manual list. Might be no good reason to get any fancier. |
| 13:00 |
|
hbrennan joined #evergreen |
| 13:01 |
gmcharlt |
#startmeeting Evergreen Web Team meeting, 21 May 2014 |
| 13:01 |
pinesol_green |
Meeting started Wed May 21 13:01:07 2014 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 13:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 13:01 |
pinesol_green |
The meeting name has been set to 'evergreen_web_team_meeting__21_may_2014' |
| 13:01 |
gmcharlt |
#info Agenda is http://wiki.evergreen-ils.org/doku.php?id=webteam:meetings:agenda:2014-05-21 |
| 13:01 |
gmcharlt |
#topic Introductions |
| 13:01 |
gmcharlt |
#info Galen Charlton, ESI |
| 13:01 |
kmlussier |
#info Kathy Lussier, MassLNC |
| 13:01 |
bshum |
#info Ben Shum, Bibliomation |
| 13:01 |
phasefx |
#info Jason Etheridge, ESI |
| 13:01 |
ElliotFriend |
#info Elliot Voris; McCaslin Library, St. Louis Christian College |
| 13:02 |
jeff |
#info Jeff Godin, Traverse Area District Library (TADL) |
| 13:03 |
gmcharlt |
thanks |
| 13:03 |
gmcharlt |
#topic Announcements |
| 13:03 |
gmcharlt |
#info bshum has upgraded the wiki software; there's a new theme in place |
| 13:03 |
gmcharlt |
#info the PayPal donation link was fixed |
| 13:04 |
gmcharlt |
any other announcements? |
| 13:05 |
gmcharlt |
OK, moving on |
| 13:05 |
gmcharlt |
#topic Action items from previous meetings |
| 13:06 |
gmcharlt |
#info gmcharlt has consolidated the welcome and about evergreen pages => http://evergreen-ils.org/about-us/ |
| 13:06 |
gmcharlt |
#info kmlussier has completed the Google+ integration; JetPack is now used to publish to FaceBoko and Google+ |
| 13:06 |
gmcharlt |
so moving on to the ones not yet done |
| 13:07 |
gmcharlt |
the redesign of the downloads page (graced) is pending, I assume |
| 13:08 |
gmcharlt |
regarding the "learn more" buttons, it lookis like you're looking for another volunteer to take that on, kmlussier? |
| 13:09 |
kmlussier |
Yes, I keep deferring that task and putting other tasks ahead of it. I looked into it far enough to see that there doesn't seem to be an easy way within the theme to deal with the accessibility issue. |
| 13:10 |
gmcharlt |
would changing the text like this ("Learn more" => "Download Evergreen", => "Read documentation", => "Get involved") suffice for the moment? |
| 13:11 |
kmlussier |
It's been a while since I looked at it, but, IIRC, you can't use distinct labels on each of the buttons. |
| 13:12 |
gmcharlt |
ah |
| 13:12 |
gmcharlt |
OK, I see that now |
| 13:12 |
bshum |
That's what I remember about the template too. It's a bit inflexible there. |
| 13:12 |
kmlussier |
gmcharlt: But if you could do that, then, yes, I think that would address the problem. |
| 13:13 |
ElliotFriend |
Is there a Wordpress hook that you could tap into for that? |
| 13:14 |
gmcharlt |
might require making a child theme to add the hook |
| 13:14 |
gmcharlt |
I'll take a look at it, though as a low-priority item |
| 13:14 |
gmcharlt |
#action gmcharlt will investigate options for adjusting the "Learn More" labels |
| 13:14 |
kmlussier |
gmcharlt++ |
| 13:15 |
gmcharlt |
next up, publicizing the proposed devs page. kmlussier? |
| 13:15 |
kmlussier |
Defer to next week? |
| 13:15 |
gmcharlt |
sure |
| 13:15 |
gmcharlt |
#action kmlussier will publicize the existance of the proposed development projects page |
| 13:16 |
gmcharlt |
next up - jeff, I see you responded to ericar's inquiry just now |
| 13:16 |
gmcharlt |
so I think we'll just carry the action item over |
| 13:16 |
gmcharlt |
#action ericar to work with jeff and dbs on the Evergreen libraries directory |
| 13:16 |
gmcharlt |
kmlussier: so, regarding the discussion to the list on web site from previous eg conferences? |
| 13:17 |
kmlussier |
I can send something to the list before the next meeting. |
| 13:17 |
jeff |
gmcharlt: thanks! |
| 13:17 |
gmcharlt |
#action to start discussion to the list on web site from previous eg conferences. |
| 13:17 |
gmcharlt |
er |
| 13:17 |
gmcharlt |
#action kmlussier to start discussion to the list on web site from previous eg conferences. |
| 13:17 |
jeff |
erohlfs++ |
| 13:17 |
gmcharlt |
and another carry-off |
| 13:17 |
gmcharlt |
#action gmcharlt will coordinate with the EOB regarding the trademark policy page |
| 13:17 |
gmcharlt |
#action ericar will continue working on creating the “How to use Launchpad” page |
| 13:18 |
|
PSM joined #evergreen |
| 13:18 |
gmcharlt |
so, phasefx has started a draft of a rewrite of the FAQs |
| 13:18 |
gmcharlt |
#info FAQ rewrite draft is at http://evergreen-ils.org/dokuwiki/doku.php?id=phasefx:faq |
| 13:18 |
gmcharlt |
is there any immediate feedback for him? |
| 13:18 |
bshum |
phasefx++ |
| 13:18 |
phasefx |
yeah, just need sanity checking/feedback.. if that looks good, I can finish the skeleton that is there and slip it in place |
| 13:19 |
kmlussier |
I have nothing immediate, but I'll take some time to look at it and send any feedback I have to the list. |
| 13:19 |
phasefx |
gracias |
| 13:19 |
gmcharlt |
sounds good |
| 13:19 |
bshum |
I liked what I saw so far. |
| 13:19 |
kmlussier |
phasefx++ |
| 13:19 |
gmcharlt |
#action folks to send phasefx feedback on the FAQs draft |
| 13:19 |
gmcharlt |
phasefx++ |
| 13:19 |
bshum |
But maybe we need to show it to people who arent as connected to Evergreen |
| 13:19 |
kmlussier |
I'm happy to see some FAQ's disappear. ;) |
| 13:20 |
gmcharlt |
:) |
| 13:20 |
gmcharlt |
speaking of things disappearing |
| 13:20 |
gmcharlt |
#topic Deleting wiki pages |
| 13:21 |
gmcharlt |
kmlussier: you have the floor |
| 13:21 |
kmlussier |
We've talked about this at previous meetings, and I think we even came up with some labor-intensive process for deleting wiki pages. |
| 13:21 |
kmlussier |
But, being labor intensive, I don't think anything's happened with it. |
| 13:21 |
kmlussier |
I'm just wondering if there is some kind of threshold where we are "allowed" to delete wiki pages. |
| 13:22 |
|
bmills joined #evergreen |
| 13:22 |
kmlussier |
For example, this one: http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:customizations:opac |
| 13:22 |
gmcharlt |
labor-intensive because of an approvals process? |
| 13:22 |
bshum |
+1 to liberal deleting. One of the themes last night put the whole navigation visible and it scared me how old some things are. |
| 13:22 |
kmlussier |
Yes, I think it was. |
| 13:22 |
PSM |
Hi, I just installed server and client 2.6 and I am unable to restart Postgres using pl_ctl restart, for some reason I am getting error 'command not found'. I would appreciate if someone can help me with this, thanks. |
| 13:22 |
kmlussier |
In the above example, the content is old, and updated content has been added to the official docs, so it seems like an easy one to ax. |
| 13:23 |
bshum |
I think if its in official docs, or deprecated, we should remove the wiki version |
| 13:23 |
phasefx |
I'm not sure how dokuwiki works; if we delete something, can we still get at the history? |
| 13:23 |
gmcharlt |
+1 to streamlining pruning the wiki |
| 13:23 |
ElliotFriend |
Would it make sense to have some kind of "wiki museum" to move the ancient stuff to? |
| 13:23 |
gmcharlt |
phasefx: yes, I believe so |
| 13:24 |
bshum |
phasefx: Yes, the show history of even a deleted page will reflect past writings |
| 13:24 |
phasefx |
cool deal |
| 13:24 |
kmlussier |
ElliotFriend: The problem is, if it's in a wiki museum, people still find it and then try to use the instructions. |
| 13:24 |
bshum |
It'll just load initially as a "no page here" view |
| 13:24 |
ElliotFriend |
kmlussier: good point. And I didn't realize that history is still available for a deleted page |
| 13:25 |
gmcharlt |
ElliotFriend: I agree with kmlussier, though there may be a place for a musuem for pages that are more about project culture than about how to use or set up Evergreen |
| 13:26 |
ElliotFriend |
How do we keep track of wiki pages that have been deleted, then? Is there a log of that within dokuwiki? |
| 13:26 |
bshum |
There is the recent changes view |
| 13:26 |
gmcharlt |
yes, e.g. http://wiki.evergreen-ils.org/doku.php?id=start&do=recent |
| 13:27 |
bshum |
Yeah deletions would show there in red |
| 13:28 |
gmcharlt |
and behind the scenes, there are logs of even older chanegs |
| 13:28 |
gmcharlt |
so I don't think we need to wrry about permanently losing stuff if a page gets deleted in error |
| 13:29 |
ElliotFriend |
Then I'd say delete away ha! |
| 13:31 |
gmcharlt |
#agreed Wiki editors should feel empowered to delete outdated content, particularly if it's marked as deprecated or is described in the official documentation |
| 13:31 |
kmlussier |
Thank you! |
| 13:31 |
* kmlussier |
wanders away for a minute to start deleting. :) |
| 13:31 |
gmcharlt |
:) |
| 13:31 |
gmcharlt |
#topic Going over website task list |
| 13:31 |
gmcharlt |
#info Task list is at https://docs.google.com/spreadsheet/ccc?key=0Ap6xBlSDakSudFFiRERMRGdRQlpGVmpNazBtX1FPaGc&usp=sharing#gid=0 |
| 13:32 |
|
kbeswick joined #evergreen |
| 13:32 |
gmcharlt |
OK, marking the publicization of posts to Google+ done |
| 13:33 |
gmcharlt |
bshum: I know you were playing around the site search recently... any updates? |
| 13:33 |
bshum |
Oh... Now that page makes sense. Other tabs |
| 13:33 |
bshum |
It looked so empty last night... |
| 13:34 |
bshum |
So for site search, I couldn't figure out how to embed the search page into wordpress |
| 13:34 |
bshum |
I did get it to do a pop up area with results |
| 13:34 |
bshum |
But it was narrow and ugly with the coloring based on our theme |
| 13:35 |
bshum |
Needs more work before we can get it forward |
| 13:35 |
gmcharlt |
ok |
| 13:35 |
gmcharlt |
need any help, or just a matter of time and tuits? |
| 13:36 |
bshum |
Probably could use a second pair of eyes to check my work. But yeah seems mostly time and tuits I think. |
| 13:36 |
gmcharlt |
ok |
| 13:36 |
gmcharlt |
#action bshum will continue to poke away at site search |
| 13:36 |
gmcharlt |
and for the next one |
| 13:37 |
gmcharlt |
#action gmcharlt will ping RoganH about his thinking for the support page |
| 13:37 |
gmcharlt |
I know ericar has been working on the how to use launchpad writeup |
| 13:38 |
gmcharlt |
and I'll get on the trademark policy page in the next few weeks |
| 13:38 |
|
RoganH joined #evergreen |
| 13:38 |
gmcharlt |
ok, are there any current tasks that folks think need more discussion |
| 13:39 |
gmcharlt |
and are there any ideas for new projects that folks would like to jump on? |
| 13:40 |
|
zerick2 joined #evergreen |
| 13:41 |
bshum |
Nothing new on my end. |
| 13:42 |
gmcharlt |
ok |
| 13:42 |
gmcharlt |
#info the next meeting is currently scheduled for 1 p.m. EDT on 18 June 2014 |
| 13:42 |
gmcharlt |
thanks, everybody! |
| 13:42 |
gmcharlt |
#endmeeting |
| 13:42 |
pinesol_green |
Meeting ended Wed May 21 13:42:54 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 13:42 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-05-21-13.01.html |
| 13:42 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-05-21-13.01.txt |
| 13:42 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-05-21-13.01.log.html |
| 13:42 |
jeff |
gmcharlt++ |
| 13:43 |
ElliotFriend |
gmcharlt++ |
| 13:43 |
phasefx |
gmcharlt++ |
| 13:43 |
bshum |
phasefx: For illustrative purposes, kmlussier just deleted http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:customizations:opac |
| 13:44 |
bshum |
On the right side of the page area, for "Old Revisions" |
| 13:44 |
bshum |
That's how you would be able to see the past history of the page and the content that was originally there. |
| 13:44 |
* bshum |
likes the little clock icon |
| 13:44 |
phasefx |
roger roger; cool |
| 13:45 |
jeff |
At present, if I search Google for evergreen opac customization and click the top result, I get: |
| 13:45 |
jeff |
This topic does not exist yet |
| 13:45 |
jeff |
You've followed a link to a topic that doesn't exist yet. If permissions allow, you may create it by clicking on ?Create this page?. |
| 13:46 |
jeff |
If I know to click the little clock icon on the side, I see "Deleting outdated content. Updated content can be found in the official documentation." |
| 13:47 |
jeff |
I don't know if it's worth doing anything different or not, but from Google's point of view, that page still exists -- the HTTP response code is 200 OK |
| 13:47 |
jeff |
hack dokuwiki to show the edit message that deleted a page? configure manual redirects? dunno. |
| 13:49 |
dbs |
jeff: presumably that will disappear once Google recrawls the page and sees that there is no content? |
| 13:50 |
dbs |
Unless you're searching for "Evergreen This topic does not exist yet" in which case there might be plenty of contending hits. |
| 13:50 |
jeff |
dbs: it's likely the page will no longer be the first search result. it does still include the keywords in both the url and the page content, though -- so I dunno. |
| 13:50 |
RoganH |
dbs: that should be the name of a FLOSS punk band. |
| 13:50 |
dbs |
Deleted pages include "<meta name="robots" content="noindex,nofollow"/>" |
| 13:51 |
dbs |
As does the "This topic does not exist yet" page. So it will get dropped from Google et al's index. |
| 13:51 |
jeff |
dbs: ah! excellent catch! i should have looked at that. |
| 13:51 |
jeff |
dbs++ |
| 13:52 |
dbs |
dokuwiki++ |
| 13:54 |
* csharp |
hangs head in embarassment |
| 13:54 |
csharp |
it wasn't DMARC (though it's nice to know that info) - it was that our A/T process got blown away a few days ago and the lockfiles were still present |
| 13:54 |
* csharp |
slinks away muttering |
| 13:55 |
bshum |
Oops. |
| 13:55 |
csharp |
actually, I'm mostly relieved that it was something a) simple and b) under my control |
| 13:55 |
jboyer-isl |
csharp: A valuable lesson was still learned! (well, two I suppose. ;) ) |
| 13:55 |
csharp |
heh - yep |
| 13:55 |
csharp |
more nagios alerts! |
| 13:55 |
bshum |
csharp: Was it blown away by something specific? |
| 13:56 |
csharp |
I was doing a full bibs + holdings export |
| 13:56 |
csharp |
I'm pretty sure that was it |
| 13:56 |
jeff |
hrm. i wonder if i should monitor this serv-- YES. |
| 13:57 |
csharp |
jeff: exactly |
| 13:58 |
bshum |
csharp: Just curious. I've had my A/T stop at the collecting phase and not actually proceed to process and send anything out before. |
| 13:58 |
bshum |
I couldn't quite figure it out yet, but then I started splitting up my A/T into groupings by granularity and running them on separate processes / timings. |
| 13:58 |
kmlussier |
I had to skip out for the end of the web team meeting, but in answer to gmcharlt's question about tasks people are working on, I am playing around with a new Getting Involved page. I saw an example from another project that inspired me. |
| 13:58 |
bshum |
And that handled the amount of work better than doing it all in one go. |
| 13:58 |
gmcharlt |
inspiration++ |
| 13:58 |
jeff |
todo: come up with wording for "your hold was cancelled by the statewide system. we don't know if you cancelled it, or if something else happened. sorry." |
| 13:59 |
gmcharlt |
s/.*/don't blame us!/ |
| 13:59 |
gmcharlt |
jeff: does that help you? ;) |
| 14:00 |
bshum |
PSM: Did you get the help you were looking for? Sorry there was a webteam meeting when you asked your question. |
| 14:00 |
jeff |
gmcharlt: an immeasurable amount! |
| 14:00 |
jeff |
gmcharlt: wait, no, unmeasurable. nevermind. |
| 14:00 |
gmcharlt |
lol |
| 14:01 |
bshum |
fwiw, "pl_ctl restart" sounds like it would definitely be the wrong command if you're trying to restart Postgres, for that'd be pg_ctl |
| 14:09 |
* Dyrcona |
wonders if changing the channel banner during meetings would help? |
| 14:09 |
bshum |
Well, if we gave pinesol_green admin powers |
| 14:09 |
bshum |
It could change the topic |
| 14:10 |
jeff |
i think a simple ~meeting factoid would be enough. |
| 14:10 |
bshum |
But yeah, that sounds better. |
| 14:10 |
jeff |
can factoids be directed? dunno. |
| 14:10 |
kmlussier |
Is there a problem with giving pinesol_green admin powers? |
| 14:10 |
bshum |
Well I think the topic would literally be the topic noted for discussion |
| 14:11 |
jeff |
(as in, shown in channel but mentioning/addressed to a nick) |
| 14:11 |
bshum |
I haven't seen it done in a long while |
| 14:11 |
Dyrcona |
kmlussier: Maybe, but it could make roulette more interesting. |
| 14:11 |
csharp |
~troubleshoot | jeff |
| 14:11 |
pinesol_green |
jeff: If you're having trouble getting Evergreen to work, please follow this guide for isolating the problem: http://evergreen-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors |
| 14:11 |
jeff |
kmlussier: not sure what is meant by "admin powers", but I'm not sure what the gain would be. |
| 14:11 |
jeff |
csharp++ thanks |
| 14:11 |
Dyrcona |
@roulette |
| 14:11 |
pinesol_green |
Dyrcona: *click* |
| 14:11 |
jeff |
~sorrymeeting | csharp |
| 14:11 |
jeff |
etc. |
| 14:11 |
csharp |
yeppers |
| 14:11 |
jeff |
roulette-- |
| 14:12 |
jeff |
(my opinion only :P) |
| 14:12 |
Dyrcona |
With admin powers, pinesol_green could actually boot people when it goes bang. :) |
| 14:12 |
csharp |
bshum: we had the A/T stuff die for us, but ESI divided holds into its own process and all worked well after that |
| 14:12 |
bshum |
csharp: I ended up splitting preoverdues from overdues from markinglost events too |
| 14:13 |
Dyrcona |
jeff: I can see your point. If the purely "fun" stuff gets over used, it can be annoying. |
| 14:13 |
bshum |
I think last count was something like 400+ or so A/T event defs |
| 14:13 |
Dyrcona |
Could it be rigged to send a message when someone joins the channel during a meeting? |
| 14:14 |
bshum |
@love roulette |
| 14:14 |
pinesol_green |
bshum: The operation succeeded. bshum loves roulette. |
| 14:14 |
Dyrcona |
*It* being pinesol_green. |
| 14:14 |
bshum |
Hmm, probably. |
| 14:14 |
bshum |
I know at the least we were talking about adding that greeter plugin |
| 14:14 |
bshum |
For new people |
| 14:15 |
Dyrcona |
csharp bshum we use granularity with our A/T events, too, but we still have trouble with them getting stuck once in a while. |
| 14:15 |
jeff |
Dyrcona: that too (over-use of "fun" commands), but my annoyance with @roulette is different. the whole "making trivial the matter of putting a gun to one's head and pulling the trigger", etc. |
| 14:16 |
Dyrcona |
jeff: Understood. |
| 14:18 |
jeff |
i would just caution against spending too much time working on "solutions" for the "problem" of people asking off-topic questions during meetings. factoid with some well-worded text and done. :-) |
| 14:19 |
jeff |
greeter isn't going to catch everyone, because not every "interruption" is by someone who just joined, or who is new. topic changing isn't going to do much, i'd wager, etc, etc. |
| 14:19 |
Dyrcona |
One thing is it would be nice if the response were a /msg, cause you wouldn't want the solution to further clutter the channel or meeting logs. |
| 14:19 |
Dyrcona |
Yeah, who reads topics, anyway? ;) |
| 14:19 |
Dyrcona |
I rescind my suggestion, whatever it was I did. |
| 14:20 |
jeff |
i'd actually say that the "~sorrymeeting" (or whatever) factoid being public in-channel is useful, since it's clear to all (and in the logs) that the person making an inquiry has been answered in some form |
| 14:20 |
jeff |
ugh, and now i'm talking something to death in an effort to encourage people to not over-obsess over a solution. sorry! :-) |
| 14:25 |
Dyrcona |
:) |
| 14:25 |
|
dkyle joined #evergreen |
| 14:25 |
Dyrcona |
jeff: I think obsessing over details comes with the job. ;) |
| 14:42 |
csharp |
~sorrymeeting is <reply> Hi! Welcome to the Evergreen ILS support channel! We're in a meeting right now, so we'll ask you to hold your questions until we're done. Thanks! |
| 14:42 |
pinesol_green |
I'll remember that, csharp |
| 14:42 |
jeff |
~sorrymeeting | csharp |
| 14:42 |
pinesol_green |
csharp: Hi! Welcome to the Evergreen ILS support channel! We're in a meeting right now, so we'll ask you to hold your questions until we're done. Thanks! |
| 14:43 |
jeff |
csharp++ |
| 14:43 |
bshum |
csharp++ jeff++ |
| 14:44 |
_bott_ |
For the curious, my XML-RPC/collections issue had nothing to do with much of anything. It was related to foreign characters in legacy notes on bills migrated in. Some regexp_replace and nothing to see here. |
| 14:45 |
jeff |
_bott_: ideally, the characters wouldn't break things, even if they were "bad data". :-( |
| 14:46 |
jeff |
_bott_: thanks for following up for those who might still have been wondering. :-) |
| 14:47 |
_bott_ |
jeff: agreed, but so easy to blame it on 2008. |
| 14:47 |
* csharp |
sees hostnames in his email log: WINDSTREAN.NET, gmailo.com, bellsoth.net, holtmail.com |
| 14:49 |
bshum |
Those are always fun |
| 14:49 |
bshum |
And at least easy to find in the email part of most patrons |
| 14:50 |
* jeff |
runs his "patrons with syntactically invalid email addresses" report and is happy to see it still at zero |
| 14:59 |
|
akilsdonk joined #evergreen |
| 15:02 |
|
kmlussier joined #evergreen |
| 15:02 |
kmlussier |
Can we get rid of this wiki page too? http://wiki.evergreen-ils.org/doku.php?id=opac:bibtemplate |
| 15:03 |
kmlussier |
I know BibTemplate isn't used in the OPAC anymore, but I wasn't sure if it was used somewhere else. |
| 15:15 |
bshum |
Eh, I don't recall if there's any current use now. |
| 15:17 |
dbs |
I'm pretty sure there is not |
| 15:17 |
bshum |
jeff: Some variant of http://irc.evergreen-ils.org/evergreen/2013-12-16#i_54639 ? |
| 15:18 |
dbs |
Open-ILS/web/js/ui/default/acq/lineitem/related.js:dojo.require('openils.BibTemplate'); |
| 15:18 |
dbs |
hrm |
| 15:19 |
jeff |
bshum: pretty much, yes |
| 15:19 |
bshum |
*blinks twice* |
| 15:19 |
dkyle |
Jeff: have you considered using constraints to prevent data quality issues you are running reports for? |
| 15:19 |
jeff |
dkyle: in the case of the email address one, that's what i did -- well, not constraints, but enabled the email regex input validation org unit setting. |
| 15:19 |
dbs |
there are a few hits under Open-ILS/web/js/ui/default |
| 15:20 |
jeff |
kmlussier: i guess i'd leave bibtemplate for now. |
| 15:20 |
kmlussier |
Darn! |
| 15:20 |
jeff |
kmlussier: but it could probably be adjusted to note that it's no longer relevant for the opac. |
| 15:20 |
dbs |
Open-ILS/web/js/ui/default/acq/lineitem/related.js: // perhaps we just pull these from the beating heart of bibtemplate |
| 15:20 |
dbs |
YES YES YES |
| 15:20 |
jeff |
hehe |
| 15:22 |
jeff |
dkyle: i used the report to identify invalid addresses and to help drive the crafting of the regex i ended up going with, and then batch-invalidated all of the email addresses that were syntactically invalid, then enabled the input regex. |
| 15:22 |
jeff |
I actually had our head of circ THANK me for the input validation being enabled -- because now when there was an obvious typo the field turned yellow immediately, and they could correct the mistake. |
| 15:22 |
jeff |
Of course that doesn't catch everything, but it's a step forward. |
| 15:25 |
jeff |
dkyle: back to the topic of constraints, though -- i can't remember if we've talked about this recently, but most of my concern would be adding a constraint without a corresponding check at a higher level that would be capable of guiding the user toward the error. |
| 15:25 |
dkyle |
jeff: hmm, i need to revisit the yous list. I had just thought of postgres constraints, but not the user side of it. |
| 15:26 |
jeff |
dkyle: constraint on actor.usr.email would be pretty effective at stopping invalid data from making it to the db, but without that upper-level UI support, I doubt I'd get any kind of "thanks" from staff or patrons when their attempt to enter an email address was met with a staff client exception / javascript alert() or TPAC Internal Server Error :-) |
| 15:26 |
dkyle |
jeff: right, you could prevent bad data, but you have an error to figure out |
| 15:28 |
jeff |
"email field turned yellow when I hit ',' instead of '.'" is better than "i got an error about the database when i tried to update this patron's account... let me look closely at every field i changed to see what might be wrong" :-) |
| 15:28 |
jeff |
so at present i'm content with the OU setting that the patron editor uses being the first line of defense, and the report being the "catch anything that falls through the cracks", and no db-level constraint at present. |
| 15:30 |
csharp |
or "I have no idea why, but I wasn't able to save the record" which is what happens now when there's a DB constraint error in a dojo interface |
| 15:32 |
jeff |
worse, until recently the patron editor was pretty silent about most of those types of errors. see bug 1246833 |
| 15:32 |
pinesol_green |
Launchpad bug 1246833 in Evergreen 2.5 "User editor does not report method errors on Save" (affected: 1, heat: 8) [Medium,Fix released] https://launchpad.net/bugs/1246833 |
| 15:32 |
dkyle |
jeff: um yep, much better indeed. some upper level framework that could handle in-db constraints might be cool.... or might just be a crazy idea. |
| 15:33 |
jeff |
not that ``alert("Method error: " + status + ": " + status_text);'' is friendly by any means, but it's better than "be silent, just don't actually save" |
| 15:34 |
jeff |
oh. topical. i hadn't noticed the recent list post of ``When I try to save a new record in my Staff Client I receive an error: 'Event: 2002: DATABASE_QUERY_FAILED-> The attempt to query to the DB failed''' |
| 15:36 |
bshum |
Yeah I wasn't too sure what that meant exactly. |
| 15:37 |
bshum |
Having never added a brief record in acq before |
| 15:37 |
bshum |
Assuming it's related to the IRC question I fielded last night, but they didn't describe what they were doing exactly when they got the error |
| 15:43 |
jeff |
might be worth clarifying that that error is likely more than just "restart things" |
| 15:55 |
bshum |
kmlussier: In bug 1321780, curious about what the mods32 spreadsheet looks like in that DB |
| 15:55 |
pinesol_green |
Launchpad bug 1321780 in Evergreen "Title browse isn't honoring non-filing characters in 740 field" (affected: 2, heat: 12) [Medium,New] https://launchpad.net/bugs/1321780 |
| 15:58 |
kmlussier |
bshum: I can't look at the moment. But I will note that we saw the same problem in every 2.5+ OPAC we looked at. |
| 15:58 |
kmlussier |
http://acorn.biblio.org/eg/opac/browse?blimit=10&qtype=title&bterm=the+heart+sutra&locg=1 |
| 15:58 |
bshum |
Well I don't know what mine is, but this is what I see for "titlebrowse" part of my mods32 in config.xml_transform |
| 15:58 |
bshum |
http://pastie.org/9196949 |
| 15:58 |
bshum |
And that seems to say ind2 |
| 15:59 |
bshum |
Which is wrong? |
| 15:59 |
bshum |
That maybe should be ind1? |
| 15:59 |
bshum |
Either that or i don't know how to read how this stuff all connects together |
| 15:59 |
kmlussier |
Yes, that's right. It should be ind1 for the 740. |
| 16:00 |
bshum |
Is it always ind1 for titles? |
| 16:00 |
bshum |
Or only for the 740 added entry? |
| 16:00 |
bshum |
Ack |
| 16:00 |
kmlussier |
No, I think it's ind2 for 245 |
| 16:00 |
bshum |
245 is ind2 |
| 16:00 |
bshum |
Damnit |
| 16:00 |
bshum |
Well that's special :D |
| 16:00 |
kmlussier |
I didn't make up the rules. :) |
| 16:00 |
bshum |
*grumbles something about hating more reingesting* |
| 16:01 |
kmlussier |
Yeah, the word reingest crossed my mind when I first heard of the problem. And I shuddered. |
| 16:02 |
* bshum |
doesn't know the correct solution to take with this stff |
| 16:02 |
bshum |
*stuff |
| 16:02 |
bshum |
But at least I guess I can help to "confirm" your bug report :\ |
| 16:04 |
kmlussier |
So a question we had when looking at this and some other indexing issues. We have the mods stylesheet and then we have the mods definition in xml_transform. Which is used in indexing? I'm assuming the one in the database? |
| 16:04 |
gmcharlt |
yes, the DB |
| 16:05 |
bshum |
So this came into being with d1f553f184426655470142447d2cf48812565e1e |
| 16:05 |
kmlussier |
gmcharlt: What purpose does the stylesheet serve? |
| 16:05 |
pinesol_green |
[evergreen|Dan Wells] Tweak MODS32 stylesheet for titles - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d1f553f> |
| 16:06 |
gmcharlt |
kmlussier: the one on the filesysytem? transforming bib records to MODS for output by one of the SuperCat services |
| 16:10 |
bshum |
So, if I'm reading the xsl right |
| 16:11 |
bshum |
We could further tweak this with a case like if the tag is 740, do the check for ind1 |
| 16:11 |
bshum |
else, do ind2 |
| 16:11 |
bshum |
But I guess we ought to verify how all other titles also work? |
| 16:14 |
bshum |
But wait |
| 16:14 |
bshum |
With where that's positioned, isn't it only performing titleBrowse if it's found with 245? |
| 16:15 |
bshum |
<xsl:for-each select="marc:datafield[@tag='245']"> |
| 16:15 |
bshum |
and <titleBrowse> is in that group |
| 16:18 |
bshum |
kmlussier: Our system probably isn't a good example, we have a custom 740 metabib field that's targeting the specific tag 740 subfield a, and not using mods. |
| 16:18 |
bshum |
And the browse flag for ours is set to true |
| 16:18 |
bshum |
So it's probably ruining the data |
| 16:19 |
bshum |
Also, we haven't upgraded to include the fix for titleBrowse the way dbwells fixed it |
| 16:19 |
bshum |
upgraded/reingested |
| 16:21 |
|
mtate joined #evergreen |
| 16:22 |
bshum |
http://spork1.biblio.org/eg/opac/browse?blimit=10&qtype=title&bterm=heart+sutra&locg=1 |
| 16:23 |
bshum |
vs. |
| 16:23 |
bshum |
http://spork1.biblio.org/eg/opac/browse?blimit=10&qtype=title&bterm=the+heart+sutra&locg=1 |
| 16:23 |
bshum |
Cause we have it badly indexed (twice) |
| 16:24 |
bshum |
Hmm |
| 16:24 |
bshum |
Yeah, it's in there once as "heart sutra" (with "the " away) because our title - alternative is picking it up and that's a browse field |
| 16:25 |
bshum |
But it's also getting picked up as "the heart sutra" because we have that custom index that's grabbing the whole thing |
| 16:25 |
bshum |
And that's also a browse field |
| 16:25 |
* bshum |
thinks maybe he can drop a custom index..... YES?!?! |
| 16:26 |
bshum |
kmlussier: So in conclusion, I'm not sure now whether this is really a bug or maybe just a local misconfiguration quirk. |
| 16:27 |
kmlussier |
Sorry - I'm in an informal meeting, but I'll read back once we're done. |
| 16:27 |
bshum |
No worries, I'm working on my monologue stats |
| 16:28 |
kmlussier |
I'm also skeptical because we've seen it on two of our systems. I'm about to check the third. |
| 16:29 |
bshum |
Well, I can only state where my investigation has taken me so far. |
| 16:29 |
bshum |
I'm sure there's something beyond what I'm seeing |
| 16:31 |
kmlussier |
hmmm...I'll have to look more closely in the database later. |
| 16:31 |
bshum |
/mods32:mods/mods32:titleInfo[mods32:title and starts-with(@type,'alternative')] is what I have for xpath for my title - alternative |
| 16:32 |
bshum |
I wonder if that means that when it comes across alternative and alternative-nfi |
| 16:32 |
bshum |
It'll index both |
| 16:32 |
bshum |
And make both ways available for browse |
| 16:33 |
bshum |
And that's why it'll show up in browse search both ways |
| 16:33 |
bshum |
Cause I can see an entry for "the heart sutra" in the right place in MVLC's catalog too, when browsing "heart sutra" - http://catalog.mvlc.org/eg/opac/browse?blimit=10&qtype=title&bterm=heart+sutra&locg=1 |
| 16:33 |
bshum |
Unless I'm just not understanding how I'm searching, or seeing results |
| 16:35 |
bshum |
In which case, maybe what we want is two separate metabib_field entries |
| 16:35 |
bshum |
One for alternative title which is for search purposes |
| 16:35 |
bshum |
And one for alternative-nfi which is used for browse |
| 16:35 |
|
tspindler left #evergreen |
| 16:36 |
bshum |
Ack, but nope |
| 16:36 |
bshum |
alternative-nfi is only for 740 |
| 16:36 |
bshum |
246 is alternative too |
| 16:36 |
bshum |
But doesn't have an nfi definition |
| 16:37 |
bshum |
Because of course it doesn't have that as part of it... sigh |
| 16:37 |
* bshum |
loves how "consistent" this is. |
| 16:38 |
bshum |
so that's probably why the metabib_field grabs alternative |
| 16:38 |
kmlussier |
Yes, so, I was finding something similar. It seemed to be indexing the record both ways. But I hadn't looked in the database to see what was going on. |
| 16:38 |
bshum |
So yep, that's what needs to be changed. |
| 16:38 |
bshum |
I think |
| 16:39 |
bshum |
The downside being that if we only index the nfi version |
| 16:39 |
bshum |
That means if I did a title search for "the heart sutra" it would fail |
| 16:39 |
bshum |
? |
| 16:39 |
bshum |
Cause it wouldn't include the word "the" in it |
| 16:39 |
kmlussier |
That's what happens when you do a title search for something in the 245 field. |
| 16:40 |
kmlussier |
And is why there is a hint available (if you enable the OU setting) suggesting that people drop the initial article if they enter it in their search. |
| 16:40 |
bshum |
Really? |
| 16:40 |
bshum |
That seems terrible :) |
| 16:43 |
jeff |
wait, really? i feel embarassed not knowing that. |
| 16:44 |
bshum |
Yeah that doesn't seem quite right somehow |
| 16:44 |
jeff |
almost as embarrassed as me not spelling embarrassed correctly. :P |
| 16:45 |
bshum |
Wow, that's just depressing |
| 16:45 |
bshum |
tested and true. |
| 16:45 |
bshum |
I hate that. |
| 16:45 |
bshum |
I want it to index the whole thing |
| 16:45 |
bshum |
Just in case |
| 16:46 |
bshum |
:\ |
| 16:46 |
bshum |
Bleh |
| 16:46 |
bshum |
This is why I just stick to keyword search :D |
| 16:47 |
bshum |
In that case we really, really ought to turn on this library setting... |
| 16:48 |
kmlussier |
Well, the thing is, if it does pay attention to "the" when you enter the initial article, then the user would be stuck if they didn't use the initial article when entering the search. |
| 16:50 |
kmlussier |
bshum: It's a global flag. |
| 16:50 |
bshum |
Hmm |
| 16:50 |
kmlussier |
Map of search classes to regular expressions to warn user about leading articles |
| 16:51 |
jeff |
okay, testing on 2.5.1 title search for the help and "^the help$" both return results I would expect. that makes me think that i misunderstood the problem. what am I doing different? |
| 16:51 |
|
ldw joined #evergreen |
| 16:51 |
|
akilsdonk joined #evergreen |
| 16:51 |
kmlussier |
jeff: In browse search? |
| 16:51 |
bshum |
Okay I'm not seeing this global flag |
| 16:52 |
jeff |
kmlussier: oh. no, not browse search. now i understand. |
| 16:52 |
bshum |
Ah there |
| 16:52 |
bshum |
"Map of search classes to regular expressions to warn user about leading articles." |
| 16:53 |
bshum |
Gotcha |
| 16:53 |
bshum |
Weird looking |
| 16:53 |
kmlussier |
Isn't that what I said? |
| 16:53 |
kmlussier |
:) |
| 16:54 |
bshum |
Well actually |
| 16:54 |
bshum |
[16:39:47] <kmlussier> That's what happens when you do a title search for something in the 245 field. |
| 16:54 |
bshum |
You didn't say "browse" |
| 16:54 |
bshum |
I was thinking like jeff, trying to figure out how it searches weirdly with title search in general... |
| 16:55 |
kmlussier |
Ha! I can see where that would be confusing, but I was referring to: |
| 16:56 |
jeff |
it was in the context of bshum talking about browse search, though. i just didn't read enough context. :-) |
| 16:56 |
bshum |
I feel slightly better if browse behaves with NFI then |
| 16:56 |
kmlussier |
(4:51:11 PM) kmlussier: Map of search classes to regular expressions to warn user about leading articles |
| 16:56 |
bshum |
regular search, I'd be very unhappy |
| 16:56 |
bshum |
Well, more unhappy |
| 16:56 |
bshum |
Than I am |
| 16:56 |
bshum |
But this is why we have problems with having one metabib_field that serves two purposes |
| 17:00 |
dbwells |
Just catching up on the recent conversation. So, the conclusion is that 740s currently show up in both the right *and* wrong placed in browse? That seems to be what I am seeing, and also supported by looking at the code. |
| 17:00 |
bshum |
dbwells: Yes, that's what I think I'm seeing as well. |
| 17:02 |
dbwells |
Also, it looks like the in-DB xsl and the filesystem xsl are out of sync for this field. That isn't part of the problem, but is a mechanical error which caused me some minor confusion. |
| 17:03 |
bshum |
:\ |
| 17:07 |
|
krvmga joined #evergreen |
| 17:08 |
krvmga |
in 2.5 in advanced search, where is the code that allows the Shelving Location box to be populated? |
| 17:10 |
krvmga |
the reason i'm asking is that i'm getting the box to show up but it has no data in it. |
| 17:11 |
bshum |
My gut reaction to that is custom org unit tree mismatching org units / copy locations |
| 17:11 |
bshum |
But I don't know offhand where all this stuff comes from |
| 17:11 |
krvmga |
bshum: thanks for the thought. i'll ask tspindler tomorrow. |
| 17:12 |
krvmga |
bshum: is there a reason that you didn't make the library names in search returns hotlinks? |
| 17:12 |
|
frank___ joined #evergreen |
| 17:13 |
bshum |
krvmga: If you're asking about our production, that's mainly because we're not live yet on a version that includes that feature (ask me again next week) |
| 17:13 |
frank___ |
hi all, does someone could tell me what is the script I have to run to make a reingest? |
| 17:13 |
krvmga |
bshum: oh, sorry, i thought you were on 2.5 already |
| 17:13 |
bshum |
krvmga: But if you're asking about our test server, I've been avoiding it for now because I don't think people really care about it at the results level. |
| 17:13 |
bshum |
krvmga: That's a 2.6 feature isn't it? |
| 17:13 |
frank___ |
I am working on 2.6 EG v |
| 17:14 |
krvmga |
bshum: 2.5, according to the release notes |
| 17:14 |
kmlussier |
bshum: There is a 2.5 feature that only uses OU settings |
| 17:14 |
bshum |
Ah well |
| 17:14 |
bshum |
Then definitely no :) |
| 17:14 |
kmlussier |
In 2.6, it was improved with the library pages. |
| 17:14 |
bshum |
I prefer keeping folks locked away in my catalog FOREVER |
| 17:14 |
bshum |
No exit strategy |
| 17:14 |
bshum |
Kidding, of course. |
| 17:14 |
krvmga |
a maze of twisty little passages, all alike |
| 17:14 |
bshum |
We're just lazy and haven't spent time putting all the pieces together yet |
| 17:15 |
bshum |
But I think mainly I don't like the idea of page results with so many links going outwards |
| 17:15 |
bshum |
I think that's best tucked away in the record details level |
| 17:15 |
krvmga |
bshum: i get nervous if i find myself in a situation where i'm doing something before you. |
| 17:15 |
bshum |
Though I am still thinking about adding a new custom page where I put all our libraries names on it |
| 17:15 |
bshum |
And have that linked to each library page |
| 17:15 |
bshum |
A sort of main listing as it were |
| 17:15 |
krvmga |
bshum: we have that already |
| 17:16 |
krvmga |
but i'm going to bet you mean something different from what we have. |
| 17:18 |
kmlussier |
OK, I've given up on working on my other project to look in the database, and I think I've caught up to speed on what's happening. But to make sure I'm understanding it correctly. We have the alternate title index that is set to search and browse... |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:20 |
kmlussier |
And that index will create one browse entry based on alternative title, which is where we see the entries starting with "the"... |
| 17:20 |
kmlussier |
And will create a second entry based on alternative-nfi, which honors those non-filing indicators. |
| 17:20 |
bshum |
krvmga: Well, I was thinking about making it a page in the catalog, and not something referenced elsewhere on another website. |
| 17:20 |
krvmga |
bshum: that's what i thought. |
| 17:21 |
bshum |
We have a list of our members with links to their websites on our biblio.org website |
| 17:21 |
kmlussier |
And the reason we can't just use alternative-nfi for browse is because we would then lose the 246 in the browse index? |
| 17:21 |
bshum |
But I want to incorporate something similar like an index of our libraries into our catalog |
| 17:21 |
bshum |
And have it link to the individual library pages |
| 17:21 |
kmlussier |
And the reason we don't include the 246 in alternative-nifi is because it doesn't use nonfiling characters? |
| 17:22 |
bshum |
Probably many ways to build it, but I'll probably go lazy and create some really boring and statically driven. But we only add members sporadically at the moment :) |
| 17:22 |
krvmga |
kmlussier: what do you think about the idea of a separate filter for data in 505? |
| 17:22 |
krvmga |
right now it's just "title" |
| 17:22 |
* kmlussier |
's head is full and can't think of anything beyond nonfiling characters at the moment. |
| 17:22 |
bshum |
kmlussier: Sounds like what I was seeing, so I think you're caught up |
| 17:23 |
kmlussier |
And the reason "the" is included in the original alternate title index is because the nonfiling character is in a different place for the 740 than it is for the 245 field? |
| 17:23 |
kmlussier |
@marc 505 |
| 17:23 |
pinesol_green |
kmlussier: The titles of separate works or parts of an item or the table of contents. The field may also contain statements of responsibility and volume numbers or other sequential designations. (Repeatable) [a,g,r,t,u,6,8] |
| 17:27 |
krvmga |
the searches work fine as is but i'm constantly running into confused patrons. example title search on our catalog for "welcome to new york" |
| 17:27 |
krvmga |
http://bark.cwmars.org/eg/opac/results?query=welcome+to+new+york&fg%3Aformat_filters=&qtype=title&locg=1 |
| 17:27 |
krvmga |
sometimes patrons are _absolutely_ sure they've got the title correct. (and they don't). and they complain to me. |
| 17:28 |
krvmga |
nothing to do, i suppose, really. |
| 17:28 |
kmlussier |
krvmga: So what do you mean by a separate filter? |
| 17:28 |
krvmga |
kmlussier: i was imagining a patron being able to specify that they were searching for a song title, for example. |
| 17:29 |
krvmga |
as is, the title search "let it be" will bring up albums right away that have the song on it |
| 17:29 |
krvmga |
i was thinking about how to maybe show that the hit was on the song title |
| 17:29 |
krvmga |
patrons usually think what's in the 245 is the TITLE and don't know about other things |
| 17:30 |
krvmga |
and so i get these angry emails about how our system is TOTALLY USELESS (their caps, not mine) |
| 17:30 |
kmlussier |
krvmga: yboston's library has an alphabetical browse for song title. Or they did have one. |
| 17:30 |
* kmlussier |
needs to hit the road. |
| 17:30 |
krvmga |
kmlussier: cool, i'm gonna check it out |
| 17:30 |
kmlussier |
One of my long commute days. |
| 17:31 |
krvmga |
safe travels |
| 17:31 |
|
kmlussier left #evergreen |
| 17:33 |
|
mmorgan left #evergreen |
| 18:23 |
|
vlewis joined #evergreen |
| 18:31 |
|
jcamins_ joined #evergreen |
| 18:31 |
|
jboyer_isl joined #evergreen |
| 18:31 |
|
wjr_ joined #evergreen |
| 18:42 |
|
sseng joined #evergreen |
| 18:45 |
|
vlewis_ joined #evergreen |
| 18:45 |
|
dreuther_ joined #evergreen |
| 18:50 |
|
pmurray` joined #evergreen |
| 18:55 |
|
tsbere joined #evergreen |
| 19:11 |
|
mrpeters joined #evergreen |
| 20:01 |
|
kmlussier joined #evergreen |
| 20:25 |
gsams |
so I switched over to action/trigger hold notifications, and I'm absolutely sure I turned email notifications off in opensrf.xml |
| 20:26 |
gsams |
yet, our new library is getting both the action/trigger notification and the old one as well. I have the hold_notify <email> set to false like it should be to turn it off |
| 20:26 |
gsams |
the oddest part is that for other libraries its working correctly |
| 20:27 |
gsams |
it's like their patrons exist on a different plane or something |
| 20:27 |
hbrennan |
And you didn't make this change in say, the past day? |
| 20:27 |
hbrennan |
haha |
| 20:27 |
gsams |
well, I made the change today. But it's already working everywhere else |
| 20:27 |
hbrennan |
Hmmm... |
| 20:27 |
gsams |
Everything that's been happening with the new library has made me feel like our system is haunted or something |
| 20:28 |
hbrennan |
I wish I knew more about how consortiums are set up (<-- lie) |
| 20:28 |
gsams |
haha |
| 20:29 |
gsams |
Every day this week I've wished I knew more about Evergreen than I do. |
| 20:30 |
hbrennan |
I don't think that ever changes |
| 20:30 |
hbrennan |
One of the joys of open source! |
| 20:30 |
gsams |
And I've been bugging everyone in here the past few days, I can only be thankful for the amount of patience and understanding everyone has had with me this week |
| 20:30 |
gsams |
indeed |
| 20:39 |
bshum |
Changes to opensrf.xml usually require service restart |
| 20:39 |
gsams |
well, that might explain things then |
| 20:39 |
bshum |
Otherwise it'll just keep doing its thing |
| 20:40 |
hbrennan |
Hmm, that's good to know! That's going on a stickie |
| 20:40 |
gsams |
weird how it didn't do anything with my other tests though, that's going to bug me I think. |
| 20:40 |
bshum |
Also |
| 20:40 |
dcook |
Could I beg a favour from someone? |
| 20:41 |
bshum |
Depends on how your email notification was scripted |
| 20:41 |
bshum |
It might be hard coded into the script itself to run email |
| 20:41 |
gsams |
it was just using the example file it looks like |
| 20:41 |
hbrennan |
I missed you, bshum |
| 20:41 |
bshum |
dcook: Of course! |
| 20:41 |
gsams |
referenced in opensrf.xml |
| 20:42 |
dcook |
bshum: Awesome. Could you try: yaz-client z3950.librariesaustralia.nla.gov.au:210 |
| 20:42 |
dcook |
And let me know if it times out or if you can connect? |
| 20:42 |
* dcook |
is getting time outs and wants to confirm that it's them and not him |
| 20:43 |
dcook |
I suppose you'd need to have yaz-client installed though... |
| 20:43 |
bshum |
I do |
| 20:44 |
bshum |
On the laptop |
| 20:44 |
gsams |
I was about to say something like, well with bshum he probably does. |
| 20:44 |
bshum |
So I'll just go grab it |
| 20:44 |
dcook |
Awesome! Thanks, bshum :) |
| 20:44 |
dcook |
I'd share my orange flavoured chocolate if I could get it to you immediately |
| 20:44 |
dcook |
I might eat it all first though. Somehow only 4 have pieces left even though the bag was full only moments ago.. |
| 20:45 |
dcook |
Ahh |
| 20:45 |
dcook |
It looks like it might be back up |
| 20:46 |
dcook |
You don't have to grab your laptop anymore, bshum :) |
| 20:46 |
bshum |
dcook: Aww, I just got it :) |
| 20:46 |
dcook |
You can do it just for fun? :) |
| 20:46 |
bshum |
I do have fun with it |
| 20:47 |
bshum |
dcook: Well, it complains about some connection rejected by v4 target |
| 20:47 |
bshum |
Whatever that means :) |
| 20:47 |
gsams |
hmm. Now I need to set it so that the new library doesn't have to send items out to other libraries until we can get things more settled. |
| 20:48 |
dcook |
Pretty sure it's because you don't have a valid username and password :) |
| 20:48 |
bshum |
Ahh, that makes sense ;) |
| 20:48 |
dcook |
But it rejected rather than timed out, so yay! Thanks :) |
| 20:48 |
bshum |
Heh |
| 20:48 |
bshum |
yaz is one of those things I use too often |
| 20:48 |
bshum |
To prove to other people that our z3950 is just fine |
| 20:49 |
dcook |
hehe |
| 20:49 |
bshum |
And it's their ancient version of Yaz that's the real problem |
| 20:49 |
dcook |
How does Evergreen provide z39.50? |
| 20:49 |
* dcook |
is curious now |
| 20:50 |
bshum |
gsams: the thing I meant to say was that overdue_notices.sh might be doing its own thing |
| 20:50 |
bshum |
I'm not sure if it reads the values from opensrf.xml |
| 20:50 |
bshum |
Or if the setting in opensrf.xml is just used to generate email content |
| 20:50 |
bshum |
And the script is what actually composes and sends |
| 20:50 |
bshum |
dcook: Well, it's sorta included |
| 20:50 |
gsams |
then it might be referencing the old file too, and I should turn that off as well. |
| 20:50 |
gsams |
ha |
| 20:51 |
bshum |
You can set up a simple2zoom service that'll point at the SRU gateway (I may have used some of those words right) |
| 20:51 |
bshum |
So you talk z39.50 to the service, the service talks SRU to Evergreen, and you may get some results. |
| 20:52 |
gsams |
bshum: overdue_notices.sh is only sending out overdus and predues it looks like |
| 20:53 |
gsams |
I'm not seeing any references to holds at least |
| 20:53 |
dcook |
bshum: Interesting! |
| 20:54 |
bshum |
gsams: Well no, hold notifications aren't run that way I think. |
| 20:54 |
bshum |
I think only circ notifications |
| 20:55 |
bshum |
dcook: I may be oversimplying something, but more or less that's what I always thought it did. |
| 20:56 |
bshum |
By default, Evergreen doesn't ship with z39.50 enabled. You have to configure (ports, scope), and then turn it on |
| 20:57 |
dcook |
Yeah, Koha doesn't have it enabled by default either, although it's pretty easy to set up. |
| 21:00 |
bshum |
gsams: You're probably right that it's just a change to opensrf.xml to turn off the value for hold notifications by email. And then restart services. |
| 21:00 |
bshum |
Just pick a good random hour to reset :) |
| 21:00 |
gsams |
so basically, wait until after close and restart evergreen services |
| 21:00 |
gsams |
this I can do |
| 21:01 |
gsams |
now I just need to figure out how to say the new libraries patrons can place holds everywhere but they can't supply anything at the moment |
| 21:01 |
gsams |
library's |
| 21:03 |
bshum |
That sounds... weird. |
| 21:03 |
gsams |
well, it is |
| 21:04 |
gsams |
If we could, we'd like to set it so they only get so many holds per week or month period, but I don't think that is really possible |
| 21:04 |
bshum |
So, they're not able to fill holds? |
| 21:04 |
gsams |
I mean, transited holds |
| 21:04 |
bshum |
But they want their patrons to place holds and get materials? |
| 21:04 |
gsams |
yeah, I think it would be best at the moment |
| 21:05 |
gsams |
they are really in scramble mode with the migration at the moment |
| 21:05 |
gsams |
I think they could handle the incoming, but not the outgoing so much right now |
| 21:05 |
bshum |
Seems to me like it'd be simpler to just not fill any holds for a bit during the migration till they're ready to be live again. |
| 21:05 |
bshum |
But maybe I'm oversimplifying :) |
| 21:06 |
gsams |
heh. They aren't the sort of library that can do that sort of thing it seems |
| 21:06 |
gsams |
so. I'm trying to figure that out tonight. |
| 21:08 |
gsams |
I'm guessing that what I want is, they can place holds on them as long as they pick them up there? |
| 21:09 |
* bshum |
shrugs |
| 21:09 |
gsams |
yeah that's where I am. I'm discussing it |
| 21:09 |
gsams |
outside of chat that is |
| 21:09 |
bshum |
I imagine it's possible to do what you're asking with the hold matrix |
| 21:09 |
bshum |
But I wouldn't feel good for those patrons. |
| 21:10 |
gsams |
neither would I honestly its just an interim measure until they get on their feet |
| 21:10 |
gsams |
this has been messy for everyone involved |
| 21:11 |
gsams |
with the hold matrix, how does it handle fall through? If I make a setting that says The Consortium can't place holds on items owned by New Library, and then another one that said that New Library patrons can place holds on New Library items would that work? |
| 21:12 |
gsams |
would it allow New Library patrons to place holds but not the rest of the group? |
| 21:12 |
gsams |
I always get confused with how that sort of logic is handled |
| 21:13 |
gsams |
I suppose I could just try it and see what happens after closing |
| 21:13 |
gsams |
that would probably be my best bet |
| 21:15 |
bshum |
The hold matrix does not fall through |
| 21:15 |
bshum |
Only the circ matrix does |
| 21:15 |
bshum |
So it's much more rigid in how it matches |
| 21:15 |
bshum |
One rule per situation. |
| 21:15 |
bshum |
Whichever one weights the best |
| 21:17 |
gsams |
mmm. that makes a lot of sense considering the system. |
| 21:18 |
gsams |
So if I am to do this particular process it needs to be library by library settings, or a different approach. |
| 21:18 |
gsams |
or at least, that would make more sense here |
| 21:40 |
pinesol_green |
[evergreen|Mike Rylander] LP#1321429: Use server-local time as best-guess - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4e84fd9> |
| 22:06 |
pinesol_green |
[evergreen|Jeff Godin] LP#1246843: Don't show contact invalidators for new users - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1ed5744> |
| 22:15 |
bshum |
Man I feel so rusty |
| 22:18 |
* dbs |
sprays wd40 on bshum |
| 22:19 |
bshum |
Heh, thanks :) |
| 22:25 |
|
ldw joined #evergreen |
| 22:47 |
bshum |
dbs: I'm looking at bug 1303544 and in my testing the extra .trim in the misc_util.tt2 for isbn/upc/issn result in having nothing show up at all in the catalog. Maybe I'm doing something wrong in my test server, I'll double check on another one. |
| 22:47 |
pinesol_green |
Launchpad bug 1303544 in Evergreen master "ISBNs should be cleaned up in record summary output" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1303544 |
| 22:48 |
bshum |
Otherwise, the change to record/summary.tt2 works fine and seems to put the ISBN on its own as described |
| 22:55 |
|
mtcarlsoz joined #evergreen |
| 23:04 |
|
shadowspar joined #evergreen |
| 23:27 |
dbs |
bshum: I don't think I have a current test VM around to give it a shot right now; feel free to merge just the summary.tt2 changes |
