| Time |
Nick |
Message |
| 07:29 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
ericar joined #evergreen |
| 08:30 |
|
Dyrcona joined #evergreen |
| 08:39 |
|
mrpeters joined #evergreen |
| 08:46 |
|
Dyrcona joined #evergreen |
| 08:47 |
|
mmorgan joined #evergreen |
| 08:51 |
|
kmlussier joined #evergreen |
| 09:27 |
|
terran joined #evergreen |
| 09:27 |
|
gsams_ joined #evergreen |
| 09:29 |
|
krvmga joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:31 |
krvmga |
when i use browse search in our catalog and browse for authors beginning with "patter", the highlighted item in the browse returns begins with "patten" rather than "patter". I'm at a loss to explain this. you can see it for yourself here: http://catalog.cwmars.org/eg/opac/browse?blimit=25&qtype=author&bterm=patter&locg=1 |
| 09:31 |
krvmga |
any thoughts would be appreciated. :) |
| 09:33 |
kmlussier |
krvmga: If there was an author with the name patter, then it would highlight patter. But, since there isn't, it finds what the system thinks is the next best thing, which I guess is the term that would appear above what would have been the matching name. |
| 09:34 |
csharp |
our Horizon catalog at DeKalb had that issue and more than one patron complained to me about it |
| 09:35 |
csharp |
there's not a good way to indicate "there is not an exact match for your browse term in the list you selected" |
| 09:35 |
krvmga |
kmlussier: as long as this is expected behavior, i'm okay with it. :) |
| 09:35 |
kmlussier |
krvmga: We have a masslnc idea related to this. http://masslnc.org/node/3074 |
| 09:35 |
krvmga |
csharp: i was using Horizon before Evergreen, too. :) |
| 09:36 |
krvmga |
kmlussier: thanks :) |
| 09:36 |
csharp |
kmlussier: that works for me |
| 09:36 |
kmlussier |
huh...on the screenshot on that masslnc idea shows the system bolding the title that falls alphabetically after the entered search terms. |
| 09:36 |
krvmga |
kmlussier++ |
| 09:36 |
mmorgan |
Hmm. Here's the same search in our catalog: http://evergreen.noblenet.org/eg/opac/browse?blimit=10&qtype=author&bterm=patter&locg=1 |
| 09:36 |
csharp |
kmlussier: look out for the rabbit hole! |
| 09:37 |
kmlussier |
csharp: Ha ha. I spend half of my work days exploring rabbit holes. |
| 09:37 |
krvmga |
mmorgan: hmmmmmm....that is kind of what i would have thought would have happened |
| 09:37 |
krvmga |
instead of what did happen here |
| 09:37 |
mmorgan |
kmlussier: Only half? ;-) |
| 09:37 |
krvmga |
now, of course, my question is: why is it doing it differently for you than for me? |
| 09:38 |
csharp |
works the same in PINES as what krvmga shows: http://gapines.org/eg/opac/browse?blimit=25&qtype=author&bterm=patter&locg=1 |
| 09:38 |
kmlussier |
krvmga: MVLC's is doing the same as NOBLE's. http://catalog.mvlc.org/eg/opac/browse?blimit=10&qtype=author&bterm=patter&locg=1 |
| 09:38 |
krvmga |
well, allrighty then...looks like a good question |
| 09:38 |
kmlussier |
I wonder if it's related to the number or results you display on each page? |
| 09:38 |
kmlussier |
I noticed that C/W MARS and PINES are both displaying 25 by default |
| 09:39 |
krvmga |
kmlussier: yeah, i did that so it actually looked more like browsing |
| 09:39 |
kmlussier |
huh. Changing it to 10 didn't change the highlighted term. hmmm |
| 09:42 |
krvmga |
so...on the 10 result page, #5 is highlighted; on the 25 result page, #13 is highlighted -- hmmmm...both numbers in a fibonacci sequence...<puts tinfoil hat on> |
| 09:44 |
|
jvwoolf joined #evergreen |
| 09:49 |
mmorgan |
C/W MARS catalog seems consistently to highlight the entry above the search term when there is no exact match. Other catalogs consistently highlight the entry below. |
| 09:52 |
jeff |
"there are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors." |
| 09:52 |
bshum |
Might be fun to see what the actual indexed term is in the browse indexes |
| 09:57 |
pinesol_green |
[sipserver|Galen Charlton] LP#1180468: update license statement to GPL v2 or later - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=27b8919> |
| 09:57 |
krvmga |
jeff++ |
| 09:57 |
krvmga |
lol |
| 10:00 |
* mmorgan |
wants to say it must have to do with an odd vs. even number displayed on the results page, but kmlussier said changing to 10 from 25 didn't change the highlighted term. |
| 10:00 |
kmlussier |
mmorgan: I'm still exploring that theory. I think it's related. |
| 10:01 |
kmlussier |
In browse.tt2, I see <span class="browse-result-value[% result.row_number == 0 && !CGI.param('bpivot') ? ' browse-result-best-match' : '' %]"> |
| 10:10 |
csharp |
changing 25 to 24 didn't change the behavior for me: http://gapines.org/eg/opac/browse?blimit=24&qtype=author&bterm=patter&locg=1 |
| 10:18 |
kmlussier |
Yeah, I tried changing the default in a couple of different ways on a MassLNC VM, but I wasn't able to replicate the problem. :( |
| 10:18 |
dbwells |
For those getting 'patten' highlights, do you get a 'patten' hit with this query as well? select * from metabib.browse_entry where id = (SELECT * FROM metabib.browse_pivot((SELECT COALESCE(ARRAY_AGG(id), ARRAY[]::INT[]) FROM config.metabib_field WHERE field_class = 'author'), 'patter')); |
| 10:21 |
krvmga |
dbwells: yes, i got a patten hit |
| 10:22 |
dbwells |
That's interesting. What is the sort_value for your hit? |
| 10:23 |
krvmga |
dbwells: patter bruce van |
| 10:23 |
krvmga |
ROFL!!! |
| 10:24 |
krvmga |
i thought it was bruce van patten |
| 10:24 |
krvmga |
my mistake |
| 10:24 |
krvmga |
it was NOT a "patten" hit |
| 10:24 |
* krvmga |
needs new glasses. |
| 10:26 |
kmlussier |
Well, that's interesting, because bruce van patter doesn't display there. It displays in the v's. |
| 10:26 |
kmlussier |
http://catalog.cwmars.org/eg/opac/browse?blimit=10&qtype=author&bterm=van+patter&locg=1 |
| 10:27 |
krvmga |
kmlussier: strange. the value = Patter, Bruce Van |
| 10:28 |
krvmga |
index vector = 'bruce':2 'patter':1 'van':3 |
| 10:29 |
dbwells |
My guess is that this authority related. krvmga are you using authority records? |
| 10:29 |
krvmga |
dbwells: yes |
| 10:29 |
krvmga |
are NOBLE and MVLC not using authority records? |
| 10:29 |
krvmga |
or is CWMARS using them somehow differently? |
| 10:29 |
kmlussier |
Ah! Of course! That's the other thing C/W MARS and PINES have in common. |
| 10:30 |
|
rlefaive joined #evergreen |
| 10:30 |
dbwells |
Patter, Bruce Van is probably an alternate heading which doesn't match any records. It takes up the pivot in the browse, but then doesn't display due to zero matches. |
| 10:30 |
kmlussier |
krvmga: There are only a few sites that are using authority records that are linked to each other for the purposes of displaying cross references |
| 10:31 |
kmlussier |
dbwells++ # Nice sleuthing! |
| 10:32 |
krvmga |
dbwells++ |
| 10:32 |
kmlussier |
I think there's a bug report in there somewhere, but I don't understand the issue well enough to file it. |
| 10:33 |
* kmlussier |
investigates another bug she discovered while exploring this issue. |
| 10:33 |
kmlussier |
rabbit_holes-- |
| 10:35 |
dbwells |
Fixing it is probably a matter of making the visible pivot shift "up" (i.e. later in the sort) instead of down, though I'm not sure how that stage works. We're not using authorities, so I don't have a ready means to pursue this ATM. |
| 10:38 |
kmlussier |
dbwells: Just helping us pin down the problem is very helpful. |
| 10:39 |
kmlussier |
And, actually, now that I think about it, I think I have enough understanding to file a bug report. |
| 10:46 |
|
JBoyer joined #evergreen |
| 10:50 |
JBoyer |
rabbit_holes++ |
| 10:50 |
JBoyer |
There's some good stuff down some of those, kmlussier. ;) |
| 10:51 |
kmlussier |
JBoyer: I haven't found a hookah-smoking caterpillar yet, so I'm still unimpressed. |
| 10:52 |
JBoyer |
Well, some of them are just dirty, sure. |
| 10:52 |
kmlussier |
krvmga: In looking at this specific issue further, I see that Patter, Bruce Van is a 400 entry on the authority record for Van Patter, Bruce, which is linked to 3 bib records. |
| 10:52 |
berick |
odd how rarely you find rabbits down there |
| 10:52 |
Dyrcona |
berick: You mostly find droppings. |
| 10:53 |
kmlussier |
krvmga: So that heading really should display once bug 1358392 is fixed. |
| 10:53 |
pinesol_green |
Launchpad bug 1358392 in Evergreen "See references not always displaying on browse search" [Medium,Confirmed] https://launchpad.net/bugs/1358392 |
| 10:53 |
krvmga |
kmlussier: thanks! |
| 10:54 |
kmlussier |
krvmga: That bug is part of the browse project we're doing with ESI, so we may see it fixed as a result of that work. |
| 10:54 |
kmlussier |
But I'll file the bug anyway. |
| 10:54 |
JBoyer |
I'm looking at adding some z39.50 "use" attribute mapping to our yaz setup (the <map use="4"><index>eg.title</index></map> lines on http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:sru_and_z39.50 ) |
| 10:55 |
JBoyer |
I assume the list of indexes is just metabib.*_search or something simliar? |
| 10:55 |
Dyrcona |
JBoyer: I believe so, yes. |
| 10:56 |
Dyrcona |
Do you think the indexes that you will add will be generally useful to others? |
| 10:56 |
JBoyer |
Great. I'm not in a position to really find out now (in training...) so I thought I'd lazyweb it. Documentation on setting up a z39.50 server is kind of thin at the moment. (I know, I could fix it...) |
| 10:57 |
Dyrcona |
Yes it is very thin, but I was recently in the code for zstyle search. |
| 10:57 |
JBoyer |
Dyrcona: Mostly I want to add additional use attributes that could be pointed to existing indexes. New indexes would come later. |
| 10:57 |
Dyrcona |
JBoyer: Well, I meant the ones you were adding to the z configuration...not necessarily new indexes in Eg itself. |
| 10:58 |
JBoyer |
We're sending "Unsupported use attributes" errors to ShareIT and I'd like to knock most of those out. |
| 10:58 |
Dyrcona |
But yes, they are metabib indexes, and I don't recall there being any restrictions. |
| 10:58 |
Dyrcona |
Funny, no one has reported that to us with ShareIT.... What use attributes? |
| 10:58 |
JBoyer |
Dyrcona: I see. Yeah, if I think the additions are fairly reasonable (i.e. not me just assigning a ton of things to keyword) I'll submit some changes to the example config. |
| 10:59 |
|
jwoodard joined #evergreen |
| 10:59 |
JBoyer |
Can't say, the error logs are awfully sparse. I'll have to go back and forth with support to find out what they're sending. |
| 10:59 |
* Dyrcona |
knows that song and dance. :) |
| 11:00 |
JBoyer |
The only attrs we claim to support are the ones on that wiki page, because I didn't have a list of what use id was what until today. |
| 11:00 |
Dyrcona |
You might be interested in a little patch we applied for ShareIT. |
| 11:00 |
JBoyer |
Also, lacking time, etc. et.c |
| 11:00 |
JBoyer |
Ooh, do tell. |
| 11:00 |
Dyrcona |
I'll link the branch in a moment. |
| 11:00 |
JBoyer |
Thanks |
| 11:01 |
Dyrcona |
I'll also check if we have any additional attributes, but I don't think we do. |
| 11:03 |
Dyrcona |
JBoyer: It's the top 2 commits on this branch: http://git.mvlcstaff.org/?p=jason/ILS.git;a=shortlog;h=refs/heads/rt4992-default-sru-keyword-all |
| 11:03 |
JBoyer |
I'm fairly sure there are some in the list that we already support, just don't map, but I'll have to look into that more when I'm at my desjk. |
| 11:03 |
Dyrcona |
Our members noticed that search wasn't doing what they liked when search multiple terms. |
| 11:04 |
Dyrcona |
Basically, z search is doing exact matches, when people were expecting "all" matches. |
| 11:04 |
Dyrcona |
There was some discussion between miker and I about it, and I came up with that hack that I think NOBLE also uses. |
| 11:05 |
JBoyer |
Ah. That might be part of what I'm seeing also. (things we obviously have that it's not finding, though there are also speed issues...) |
| 11:05 |
Dyrcona |
I should say we came up with that hack. |
| 11:05 |
Dyrcona |
Yeah, speed is an issue. |
| 11:05 |
Dyrcona |
At C/W MARS, it times out retrieving more than 50 results or so. |
| 11:06 |
JBoyer |
Does SRU not have a good way to pass the "relation" or whatever the comparison function is? (like "exact", "less than", and so on) I'd think that would be a good way to fix the exact vs any thing, but would take more backend work. |
| 11:07 |
Dyrcona |
JBoyer: As I recall, it can send a relation, but the default is exact if none is specified. |
| 11:07 |
Dyrcona |
So, the hack changes the default to all. |
| 11:07 |
|
bos20k joined #evergreen |
| 11:08 |
Dyrcona |
'Cause ShareIT is just sending search terms and not using many (if any) relators. |
| 11:08 |
miker |
So, here's how browse works on the inside, and why you're seeing the thing highlighted that you are: we split the page size in half, and add the "extra" to the bottom half if it's odd. we look for the first string starting with what the user typed [details left out for brevity] or "greater" according to the db collation settings and that becomes the pivot. Using the full value of the pivot, we look for strings equal to or greater than that, and thos |
| 11:08 |
miker |
become the bottom half of the page, with the pivot being the top of the bottom-half list. Then, we look for strings less than the pivot value, ordered by the collation settings, and that becomes the top half. |
| 11:09 |
* Dyrcona |
checks his z39.50 oils config for the search indexes set up their. |
| 11:09 |
Dyrcona |
s/their/there/ |
| 11:11 |
|
bos20k joined #evergreen |
| 11:12 |
Dyrcona |
JBoyer: Looks like we changed 7 and 8 to eg.isbn and eg.issn respectively. I think those are indexes that we may have added. |
| 11:13 |
Dyrcona |
Other than that, we've got the same attributes as defined on the wiki. |
| 11:23 |
JBoyer |
I've been in and out of here, but thanks for the patches and pointers. I guess I should pay some attention to the training I'm in, heh. |
| 11:24 |
JBoyer |
Dyrcona++ |
| 11:28 |
|
bos20k joined #evergreen |
| 11:31 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Adding 2.10.4 Point Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ae4ccf7> |
| 11:40 |
gmcharlt |
kmlussier++ |
| 11:46 |
|
sandbergja joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:12 |
kmlussier |
Ooh! I just came across the new calendar widget in webby for the first time! |
| 12:16 |
kmlussier |
I like it! |
| 12:22 |
|
bmills joined #evergreen |
| 12:23 |
|
bos20k joined #evergreen |
| 12:39 |
|
berick joined #evergreen |
| 12:43 |
mmorgan |
kmlussier: The calendar looks nice! But I noticed something on our test system. I enter "1/1/80" for a birthdate and webby sees it as 1/1/2080. The xul client sees it as 1/1/1980. We don't have the date format ou setting set. |
| 12:44 |
|
brahmina joined #evergreen |
| 12:45 |
mmorgan |
Do you see the same thing? |
| 12:45 |
kmlussier |
1/1/2080 sounds like a perfectly reasonable birthdate. ;) |
| 12:45 |
mmorgan |
Sure! We do like to start 'em early :) |
| 12:45 |
kmlussier |
I don't know. I didn't try manually entering dates yet. I was using a widget in a box where I quickly wanted to get to today's date, and I was happy to see there was a quick way to jump to today. |
| 12:46 |
* kmlussier |
is pleased rather easily |
| 12:46 |
mmorgan |
Yes, that calendar navigation stuff is nice. |
| 12:46 |
* mmorgan |
is distracted easily |
| 12:47 |
Dyrcona |
mmorgan: What browser did you use? I ask because a different browser might give a different result. |
| 12:48 |
mmorgan |
I'm using Chrome. It seems to be the best choice for webby. |
| 12:49 |
kmlussier |
On webby, when I use Chrome, it doesn't recognize 03/17/70 as a valid format and I can't submit the form. |
| 12:50 |
kmlussier |
mmorgan: I think Firefox should be okay for the web client too. The biggest problem with Firefox was the lack of calendar widget, but that's been fixed now with this new widget. |
| 12:50 |
mmorgan |
Looks like webby has the ou for the date format set as yyyy-MM-dd HH:mm |
| 12:51 |
kmlussier |
mmorgan: Yeah, I just saw that. So let's update that setting and see what happens. |
| 12:51 |
mmorgan |
kmlussier: Ok, good to know, I won't rule out Firefox. |
| 12:51 |
Dyrcona |
Well, I just checked with both Chrome and Firefox against my concert VM and both turn 1/1/80 into 1/1/2080. |
| 12:52 |
Dyrcona |
It may be something that can be controlled with Angular. |
| 12:52 |
Dyrcona |
I doubt the format setting will affect what happens with a two digit year. |
| 12:53 |
kmlussier |
Yeah, an alternative might be to force the date format into a four-digit year. But it would be better if Angular knew what to do with the two digit year. |
| 12:53 |
Dyrcona |
kmlussier: 03/17/70 doesn't work because of the first 0, drop that and it works. |
| 12:54 |
Dyrcona |
kmlussier: Angular knows what to do with the two-digit year, it's just not doing what you want. :) |
| 12:54 |
jeff |
Is it known what branch webby.evergreencatalog.org is currently running? |
| 12:54 |
kmlussier |
Dyrcona: No, it doesn't work because of the Format date setting that is being used on webby right now. Dropping the zero doesn't help either. |
| 12:55 |
Dyrcona |
Oh, that.... |
| 12:55 |
Dyrcona |
Well, I s'pose you have to put the date in the expected format. |
| 12:55 |
Dyrcona |
1970-03-17 |
| 12:55 |
Dyrcona |
And it will probably want time, too. |
| 12:56 |
* mmorgan |
slips away for a bit |
| 12:57 |
|
berick joined #evergreen |
| 13:00 |
Dyrcona |
Interesting.... |
| 13:01 |
kmlussier |
Even without the leading zero in there, it still isn't working right for me. It's storing the two-digit year as 2070 or 2085 |
| 13:01 |
Dyrcona |
kmlussier: Well, yeah, that's what the underlying implementation is doing with two digit years. |
| 13:02 |
Dyrcona |
I was just messing with manually entering values on webby and it does not like 3/17/70 for some reason. |
| 13:03 |
kmlussier |
Dyrcona: I just changed the format date settings so that it should take that format now. |
| 13:04 |
Dyrcona |
OIC. You changed it to require the leading zero. |
| 13:04 |
Dyrcona |
Without any setting, on my concerto vm, it accepted it without the 0, but rejected it with the 0. |
| 13:05 |
Dyrcona |
'Twould be nice if it would accept a variety of formats, but telling the month from the day can be tricky. |
| 13:05 |
kmlussier |
Dyrcona: Sorry, APEX doesn't require the leading zero, but I think the consortium wide setting does require the leading zero. It accepts it without the zero in APEX, but stores it as 2070. |
| 13:06 |
Dyrcona |
OK. Different ou settings. |
| 13:06 |
Dyrcona |
And like I said before the 2070 is what the code is doing with two digit years. |
| 13:07 |
Dyrcona |
And, it comes down the question of which one is in use, because I find several. |
| 13:10 |
kmlussier |
Dyrcona: Which what is in use? The datepicker? |
| 13:26 |
Dyrcona |
Yeah, the datepicker. I see more than one available, and I can't tell from view source. |
| 13:27 |
jeff |
in webby, i don't see a way to print a list of "what a patron currently has checked out" short of selecting all of the items and picking "print item receipt" from Actions. Am I overlooking an easier option? |
| 13:27 |
Dyrcona |
When I google search, I get results for different date pickers, but it looks like angular 1.5 (at least) has one, so it is likely that one. |
| 13:28 |
berick |
the date picker is part of angular-ui-bootstrap |
| 13:30 |
|
brahmina joined #evergreen |
| 13:30 |
Dyrcona |
berick: Thanks. I was trying to see if the handling of two-digit years could be configured. |
| 13:31 |
Dyrcona |
Like, anything over 40 treat as 19xx, for instance. |
| 13:32 |
Dyrcona |
I also think it would be good to configure the use of four digit years in the formats, but that's just a general observation, not aimed at anyone in particular. |
| 13:38 |
Dyrcona |
I'm sure there are never many centenarian library users, but you never know. :) |
| 13:39 |
Dyrcona |
berick: Is it md-datepicker? |
| 13:40 |
miker |
Dyrcona: IIRC, gmcharlt adjusted the user editor in exactly that way -- use 4-digit year |
| 13:40 |
miker |
just recently |
| 13:41 |
gmcharlt |
bug 1581126 |
| 13:41 |
pinesol_green |
Launchpad bug 1581126 in Evergreen "webstaff: make datepicker respect format.date OUS" [Undecided,New] https://launchpad.net/bugs/1581126 |
| 13:41 |
berick |
Dyrcona: https://angular-ui.github.io/bootstrap/ |
| 13:41 |
Dyrcona |
miker: Yep, that's what we were talking aobut, I think kmlussier changed it. |
| 13:42 |
Dyrcona |
berick: Thanks, muchly. I hadn't found that, yet. |
| 13:42 |
berick |
looks like it's uib-datepicker |
| 13:43 |
kmlussier |
gmcharlt: That's on webby right now, right? |
| 13:43 |
gmcharlt |
kmlussier: yeah |
| 13:51 |
jeff |
16284 errors, 4 warnings |
| 13:51 |
* jeff |
chuckles |
| 13:56 |
|
ericar joined #evergreen |
| 13:56 |
kmlussier |
jeff: Yes, I think that's how it's done in the web client. Use the select all check box, and then print item receipt from the Actions menu. |
| 14:06 |
berick |
IIRC, right-click also works |
| 14:06 |
berick |
might be slightly faster |
| 14:09 |
kmlussier |
Yes, right-click does indeed work |
| 14:09 |
kmlussier |
berick++ |
| 14:10 |
* kmlussier |
is thinking about generating consensus among column picker defaults. |
| 14:10 |
kmlussier |
For example, checkin workstation as a default display column in the Items Out screen probably isn't warranted. |
| 14:13 |
|
lualaba joined #evergreen |
| 14:13 |
|
tspindler1 joined #evergreen |
| 14:14 |
* mmorgan |
would love to see irrelevant column choices disappear from the column picker. |
| 14:15 |
* terran |
would love that as well |
| 14:24 |
|
mdriscoll joined #evergreen |
| 14:33 |
jeff |
not too far afield from that subject... under billing history, the Payments tab presents columns which seem to be more xact-related than payment-related: "Last Payment Type" and the like. |
| 14:33 |
jeff |
the columns also can't be saved due to "Cannot save settings without a grid persist-key" |
| 14:34 |
jeff |
I'm digging a little deeper |
| 14:35 |
jeff |
oh hey, neat other-quick: the z-index of the bill history End Date datepicker seems to be above that of the Other menu (you may have to struggle to create a circumstance where you can see this) |
| 14:36 |
jeff |
actually, probably not much of a struggle. |
| 14:38 |
|
rlefaive joined #evergreen |
| 14:41 |
|
cag00 joined #evergreen |
| 14:43 |
|
rlefaive joined #evergreen |
| 14:53 |
|
tspindler1 left #evergreen |
| 15:15 |
Stompro |
Thanks mmorgan++, that is a great suggestion. All the migrated billed circs have either MAXFINES or null for the stopfines, so that should work. |
| 15:30 |
mmorgan |
Stompro: Changing the status of the items to Lost would probably be a good idea, too, since the mark lost trigger will do that also. |
| 15:32 |
Stompro |
mmorgan, that would also help move them to a non-holdable status so our purchase request and unfillable holds report would be more accurate. Thanks |
| 15:39 |
mmorgan |
YW. Now if I could only figure out how to deal with lp 1562061 |
| 15:39 |
pinesol_green |
Launchpad bug 1562061 in Evergreen "Marking a Long Overdue transaction Lost adds a second bill to the patron record" [Undecided,New] https://launchpad.net/bugs/1562061 |
| 15:40 |
Stompro |
Is that the main bug keeping Long Overdue from working like it should? |
| 15:43 |
mmorgan |
I think Long Overdue works pretty well as long as it's being used as a substitute for Lost. Just doesn't play well when you're planning to mark long overdue items lost later. |
| 15:43 |
|
tspindler1 joined #evergreen |
| 15:44 |
terran |
Agreed - we currently tell our libraries not to mark something Lost if it's already Long Overdue, but it would be nice if the system handled it gracefully. |
| 15:44 |
mmorgan |
lp 1331174 is another bug |
| 15:44 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 15:46 |
Dyrcona |
Interesting thing I just "noticed" in the web staff client. |
| 15:47 |
Dyrcona |
I had a patron registration tab open with some information filled in. |
| 15:47 |
Dyrcona |
When it went to auto log me out, I got the Leave this page dialog in my browser. |
| 15:47 |
Dyrcona |
Guess that is to be expected, though. |
| 15:48 |
mmorgan |
terran: Do you have ongoing problems with staff marking long overdue items lost? |
| 15:49 |
terran |
mmorgan: we did in the beginning, but they pretty much stopped doing it after having to go back and correct each of the bills |
| 15:50 |
mmorgan |
ok, thanks. It certainly would be nice if the system handled it gracefully. |
| 15:50 |
terran |
mmorgan: if it handled it gracefully, it would be one less thing we'd have to train on :) |
| 15:51 |
mmorgan |
Indeed! |
| 15:55 |
Stompro |
mmorgan, so if the lost process would check for a long overdue bill (bill_type: 10) ... I wonder if it should also look for an exisiting lost bill also, just in case someone marks something lost a second time? I don't know if that can happen. |
| 15:57 |
mmorgan |
I have never seen a second Lost bill applied. Even in the staff client, if a user tries to mark and already Lost item lost again, it's not allowed. A message pops up saying it's already lost. |
| 15:59 |
Stompro |
I wonder if you first change the status to something else via the item attribute editor and then try marking it lost again? |
| 16:00 |
|
tspindler1 left #evergreen |
| 16:02 |
mmorgan |
Stompro: I'm not sure where the logic is that stops the second lost processing. I'll try what you suggest and see what happens.... |
| 16:05 |
mmorgan |
Hmm. So changing the Lost status in the ITEM to something else allows the item to be marked Lost again, and a second bill is generated. |
| 16:06 |
mmorgan |
Clarification - marked Lost by Patron in the staff client. |
| 16:07 |
* mmorgan |
didn't realize the client was looking at the item status for that function. |
| 16:11 |
Stompro |
So maybe along with checking to see if there is a long overdue bill, it should also check to see if there is an existing lost bill. |
| 16:14 |
mmorgan |
Stompro: Do you see that it is checking for a bill of a certain type? Or is that what you're proposing? |
| 16:15 |
Stompro |
Gah, I don't get how the create_bill function in src/perlmods/lib/OpenILS/Application/Circ/CircCommon.pm has a different number of arguments than what is used in set_item_lost_or_lod in src/perlmods/lib/OpenILS/Application/Cat/AssetCommon.pm |
| 16:16 |
Stompro |
mmorgan, that is just what I'm proposing while looking at where the bill is generated. |
| 16:21 |
* mmorgan |
looks at the pm's |
| 16:25 |
Stompro |
Hmm, void_lost in CircCommon.pm searches for current bills - i like examples, examples++ ... So what if someone has their long overdue bill voided, should markitemlost add a new bill? |
| 16:27 |
* mmorgan |
doesn't speak perl very well, but tries to follow along. |
| 16:29 |
mmorgan |
examples++ |
| 16:29 |
* jeff |
shakes fist at Chrome dev tools closing the websocket pane when a websocket connection is closed |
| 16:30 |
berick |
mmorgan: if you say it aloud under the full moon, your enemies will be smitten. |
| 16:31 |
mmorgan |
If a long overdue bill is voided, I would think a markitemlost process should add a new bill. |
| 16:32 |
Stompro |
So before the new bill is created at line 795 of AssetCommon.pm - we search for current bills of type lost or long overdue, maybe we exclude based on voided or not. If there are any results then we don't add a new bill. |
| 16:33 |
terran |
Stompro: +1 to that from me |
| 16:35 |
Stompro |
mmorgan, I'm trying to think of a situation where you would want to respect the voided bill... what would cause someone to void a bill for a long overdue item, but leave the item in long overdue status instead of manually marking it lost/missing/damaged? |
| 16:35 |
Dyrcona |
Stompro: To answer your question about the different number of arguments: Perl is funny like that. ;) |
| 16:35 |
terran |
Dyrcona: But not ha-ha funny ;( |
| 16:35 |
Dyrcona |
Stompro: When set_item_lost_lod calls create_bill, the note and timestamp are not passed in. |
| 16:36 |
Dyrcona |
Stompro: So, those parameters get the valued of undef (null in most other languages). |
| 16:37 |
Dyrcona |
Stompro: So, if the note is undef, that's OK. It means we don't have a note, and that works in Perl and in the database. |
| 16:37 |
Dyrcona |
Stompro: If the timestamp is undef, that's OK. When inserted into the database, it will get replaced with the value of now(). |
| 16:37 |
|
genpaku joined #evergreen |
| 16:37 |
mmorgan |
Stompro: My thinking is if a patron already has a lost or long overdue bill, not voided, they should not get another lost or long overdue bill |
| 16:37 |
Stompro |
Dyrcona, but it does pass $args{bill_note}... |
| 16:38 |
mmorgan |
If the patron has either of those for the transaction that is voided, they could be eligible to get another lost or long overdue. |
| 16:38 |
mmorgan |
A patron should only have one unvoided bill for the cost of the item. |
| 16:39 |
Dyrcona |
Ah, but $args{bill_note} is not the note..... |
| 16:39 |
Dyrcona |
It's actually the text representation of the bill type. |
| 16:39 |
* mmorgan |
hates that she has to leave now, just when things are getting interesting :-( |
| 16:39 |
Stompro |
Dyrcona, sigh, of course, why would it be. |
| 16:40 |
Dyrcona |
Stompro: I think the field in that hash is unfortunately named. |
| 16:40 |
* Dyrcona |
is probably responsible for it, too. |
| 16:40 |
* Dyrcona |
checks. |
| 16:41 |
* jeff |
attempts to learn more about eg-grid's auto-field option and how it relates to linked IDL classes |
| 16:42 |
mmorgan |
Don't stop talking about billing on my account ;-) |
| 16:42 |
* mmorgan |
is pulled away.. |
| 16:42 |
Dyrcona |
Oh, apparently I'm not... :) |
| 16:42 |
|
mmorgan left #evergreen |
| 16:42 |
Stompro |
Dyrcona, thanks, it makes sense now, I knew that not all the arguments needed to be there, it just looked like there were some in the middle being skipped which I didn't think was possible. |
| 16:43 |
Dyrcona |
Stompro: You're right, ones in the middle can't be skipped with that style of argument. You'd need named parameters for that. |
| 16:43 |
Dyrcona |
The hash key is poorly named in this case. |
| 16:44 |
Dyrcona |
It probably should be bill_type or something like that. |
| 16:44 |
Dyrcona |
I never asked why, but bill's have a text field and a numeric field for the type. |
| 16:45 |
Stompro |
There already a bill_type field :-) which is for the numeric code. |
| 16:45 |
jeff |
if i'm not mistaken, one is newer than the other, but both exist and an attempt is made to maintain them in the name of not breaking things like old reports |
| 16:45 |
Dyrcona |
Yeah... |
| 16:46 |
Dyrcona |
bill_type should be bill_btype and bill_note should be bill_type to correspond with the fields in the table. |
| 16:46 |
Dyrcona |
jeff: That makes sense. |
| 16:47 |
Dyrcona |
Though, the fields are just btype an type. |
| 16:48 |
Dyrcona |
Lots of fun stuff going on in there. ;) |
| 16:50 |
terran |
Before I sign off, Stompro++ and Dyrcona++ and mmorgan++ for working on this! |
| 16:51 |
Stompro |
Dyrcona thanks for clearing that up for me, Dyrcona++ |
| 16:55 |
kmlussier |
berick: If I had known that, I would have learned to speak perl long ago. |
| 16:58 |
berick |
kmlussier: well, as with any language of Mordor, you have to pay a hefty price. |
| 16:58 |
berick |
e.g. a stronger glasses prescription |
| 16:58 |
jeff |
oh! hah! auto-fields="false" is the same as auto-fields="true" |
| 16:59 |
jeff |
because "if ($scope.autoFields)" |
| 17:00 |
|
bmills joined #evergreen |
| 17:00 |
berick |
jeff: if defined correctly in the directive, auto-fields="false" will translate to $scope.autoFields = false in the JS |
| 17:00 |
jeff |
perhaps auto-fields="false" is a bad idea, and directive attributes are best thought of like checked="foo" style html attributes. |
| 17:01 |
berick |
ah, grid.js should probably be changed from autoFields : '@' to autoFields : '=' |
| 17:01 |
berick |
(IIRC) |
| 17:01 |
berick |
one captures the string value, one captures the eval'ed value |
| 17:02 |
jeff |
berick: oh, good. i was starting to wonder myself, but i'm still working on foundationals. |
| 17:02 |
pinesol_green |
[evergreen|Galen Charlton] fix typos in 2.10.4 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=05afbf2> |
| 17:08 |
jeff |
related, it appears that (at least in one place where i've tried it) auto-fields="true" on something like idl class "mp" having a field for "Billable Transaction", containing an object. |
| 17:14 |
pinesol_green |
[evergreen|Galen Charlton] 2.10.3-2.10.4 schema upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7c14cea> |
| 17:24 |
|
jvwoolf left #evergreen |
| 17:55 |
gmcharlt |
https://evergreen-ils.org/evergreen-2-10-4-released/ |
| 17:59 |
kmlussier |
gmcharlt++ |
| 18:30 |
|
bmills joined #evergreen |
| 18:35 |
|
bmills1 joined #evergreen |
| 19:14 |
|
gsams_ joined #evergreen |
| 19:22 |
|
serflog joined #evergreen |
| 19:22 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 20:40 |
|
abowling left #evergreen |
| 20:45 |
|
bmills joined #evergreen |
| 21:12 |
jeff |
gmcharlt++ |
