| Time |
Nick |
Message |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:14 |
|
graced joined #evergreen |
| 07:35 |
|
rjackson_isl joined #evergreen |
| 07:37 |
|
Arlene joined #evergreen |
| 07:44 |
|
bmills joined #evergreen |
| 07:46 |
|
bmills1 joined #evergreen |
| 07:55 |
|
remingtron joined #evergreen |
| 07:55 |
|
jboyer-isl joined #evergreen |
| 08:30 |
|
krvmga joined #evergreen |
| 08:33 |
krvmga |
i just had a complaint from a library that, in the myopac holds status display, the number x holds on y circulating copies shows x from queue_position rather than from record_hold_count. |
| 08:34 |
krvmga |
we try not to show anyone where they are in the queue (since that's fairly useless). is there any other rationale for this? |
| 08:35 |
|
akilsdonk joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:36 |
jonadab |
krvmga: Showing people where they are in the queue is useless for large libraries that usually have multiple copies of things. Small library patrons would break out torches and pitchforks if they couldn't see where they are in the queue. |
| 08:37 |
jonadab |
Although _usually_ they ask the staff at the desk. |
| 08:38 |
krvmga |
jonadab: some of our libraries have gotten fanatical about not letting the patron know where they are in the queue |
| 08:38 |
jonadab |
krvmga: Right, if you're large enough to have multiple branches, you don't want to show that. |
| 08:39 |
|
ericar joined #evergreen |
| 08:40 |
krvmga |
i find it uncomfortable to be in the position to tell the large libraries that patrons are going to be able to see "where they are" in the hold queue and there's nothing to do about it. |
| 08:40 |
krvmga |
naturally, it's a larger library complaining about this |
| 08:41 |
jonadab |
Right, what I mean is, if your install of Evergreen serves multiple libraries, you are probably too large to want that information shown. |
| 08:41 |
krvmga |
we could take that bit of info display out totally, i suppose. |
| 08:41 |
jonadab |
When I said "small libraries", I'm thinking the entire everything for the whole everything fits in one building. |
| 08:42 |
jonadab |
Single-OU system. |
| 08:45 |
jonadab |
Our patrons would riot if they couldn't see their queue position, because there can be twenty of them on the list for our one copy of a new movie, for example. |
| 08:46 |
jonadab |
I of course have no problem with it being a config option that the system administrators can turn off entirely for a particular install. |
| 08:48 |
csharp |
PINES doesn't show the queue at all for anyone since it's misleading information - it would only be accurate if FIFO holds were in play |
| 08:49 |
jonadab |
PINES is very definitely a much larger system, so yeah, that makes sense. |
| 08:51 |
jonadab |
Large systems don't do strict FIFO holds because of stuff like holds routing. |
| 08:51 |
jonadab |
But holds routing is not even remotely a thing for really small libraries. |
| 08:52 |
csharp |
right |
| 08:52 |
krvmga |
in our catalog, i've now commented out the code in hold_status.tt2 that displays queue position. local problem solved. |
| 08:53 |
krvmga |
i did, however, make a change in the code. it was displaying a grammatical error. the fix was simple and i think it should be included in evergreen generally. |
| 08:54 |
krvmga |
i'll have put it in git. |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:12 |
|
julialima_ joined #evergreen |
| 09:16 |
kmlussier |
krvmga: Can you push it to the working repository and add a Launchpad bug for it? |
| 09:16 |
krvmga |
kmlussier: yes, i will do that. |
| 09:20 |
|
mrpeters joined #evergreen |
| 09:29 |
kmlussier |
I understand why systems don't want to share the holds queue position, but, speaking from my experience as a librayr user, I like to see the holds queue position even though I know it's flawed. |
| 09:30 |
kmlussier |
If I'm 122 in the holds queue, I know I'll have to wait a while. If I'm number 1 and I see there are items available, I know to ask if it doesn't come in a reasonable timeframe. |
| 09:30 |
bshum |
"flawed" can be an understatement. |
| 09:31 |
jonadab |
It's flawed in some minor ways even for very small systems (e.g., a Books on Wheels patron may have the thing out on 60-day loan). |
| 09:31 |
Dyrcona |
Our members' staff insist on us displaying it, even though I've characterized it as an outright lie. |
| 09:31 |
jonadab |
But for large multi-library systems it can be *highly* flawed. |
| 09:32 |
* kmlussier |
is speaking from the perspective of a large, multi-library system |
| 09:32 |
Dyrcona |
It is quite simply, the order your hold was placed, and has no relationship whatsoever with the order in which it will fill. |
| 09:33 |
kmlussier |
But it does have some relationship to the order in which it is filled. But is just one of several other factors. |
| 09:33 |
bshum |
Right, given opportunistic capture. Or libraries doing whatever they want at checkout anyways. |
| 09:33 |
Dyrcona |
It is the least of those factors. |
| 09:33 |
|
yboston joined #evergreen |
| 09:33 |
* kmlussier |
shrugs |
| 09:33 |
* mmorgan |
agrees with kmlussier. Patrons want to have an idea if they will get it "soon", or if they will have to wait a long time. |
| 09:34 |
Dyrcona |
And with the way some of our member manage open hold stacks, you're likely to get the notification, show up, and find out they gave your book to someone else. |
| 09:34 |
bshum |
"but I've been number 2 for months now?????" |
| 09:34 |
Dyrcona |
I've been number 1, forever! |
| 09:34 |
Dyrcona |
heh |
| 09:34 |
bshum |
Ugh, what Dyrcona says ends up being true too often. |
| 09:34 |
jonadab |
Sure, you can always be first on the list forever, if the person who has it out never brings it back. |
| 09:34 |
Dyrcona |
Of course, the staff blame Evergreen. |
| 09:35 |
Dyrcona |
jonadab: I'm talking about things with multiple copies, popular stuff. |
| 09:35 |
kmlussier |
You can be first on the list forever if your hold got lost in delivery. Which is why it's sometimes good for a patron to raise a question if they have been #1 for a long time |
| 09:35 |
Dyrcona |
The pickup library just happens to be one of the only two that don't own a copy, or their copy is overdue/lost. |
| 09:35 |
jonadab |
kmlussier: Oh, interesting point. |
| 09:36 |
jonadab |
Dyrcona: Sure, but again, that's a multi-library system issue. |
| 09:36 |
Dyrcona |
You can be first on the list forever for myriad reasons. |
| 09:36 |
Dyrcona |
jonadab: That's all I'm talking about because that's where I work. |
| 09:36 |
jonadab |
Righ. |
| 09:36 |
* bshum |
likes the random negative number queue |
| 09:37 |
jonadab |
Holds get really weird in multi-library systems. |
| 09:37 |
bshum |
What does -1 mean? (hates that ticket) |
| 09:37 |
mmorgan |
Patrons who are waiting a long time for a hold will likely ask (and rightly so) whether they know their queue position or not. |
| 09:37 |
jonadab |
^ True. |
| 09:38 |
Dyrcona |
Problem is, too many people seem to confuse it with the ticket at the deli counter. |
| 09:38 |
mmorgan |
Maybe there needs to be some explanation available to the patron around what that really means. |
| 09:38 |
Dyrcona |
It's nothing like that. |
| 09:38 |
jonadab |
mmorgan: Perhaps 5% of patrons would read the explanation. |
| 09:38 |
Dyrcona |
First, we need to make staff understand it. |
| 09:38 |
jonadab |
Yeah... |
| 09:38 |
* csharp |
thinks if you have to explain something, you're already losing |
| 09:38 |
* Dyrcona |
agrees with csharp. |
| 09:39 |
mmorgan |
jonadab: perhaps, but it's a reference for patrons and staff. |
| 09:39 |
csharp |
"here's your place in the queue, however it doesn't mean *exactly* what you think it means... here are the 5 factors at play..." |
| 09:39 |
jonadab |
mmorgan: True. If there's a link to the explanation next to the number (when the number is shown), staff could at least know where to find the info. |
| 09:39 |
* mmorgan |
thinks holds can be so complicated in a consortium, explanation is essential. |
| 09:40 |
jonadab |
csharp: What if it were simplified to "probably soon", "maybe soon", "after a while", "eventually"? |
| 09:40 |
jonadab |
With per-install config for what numbers correspond to each level. |
| 09:40 |
csharp |
@eightball will I get my hold soon? |
| 09:40 |
pinesol_green |
csharp: Yes! |
| 09:41 |
jonadab |
Heh. |
| 09:41 |
csharp |
maybe just have @eightball handle it :-P |
| 09:41 |
csharp |
or just have a random number generator that makes sure number 1 is lower than number 2 |
| 09:42 |
csharp |
sorry - I don't mean to be so dismissive - holds is so complicated - if it were simpler, I'd be more behind showing the queue\ |
| 09:43 |
jonadab |
csharp: I'm only arguing in favor of showing it in the case of a single-building library system with no branches or anything, no holds routing, etc. |
| 09:43 |
jonadab |
There are still complications, but way fewer of them. |
| 09:43 |
csharp |
I've been studying Evergreen holds for nearly 7 years and it still boggles my mind - I wouldn't expect front-end staff and patrons to get it |
| 09:43 |
csharp |
jonadab: yeah that makes sense |
| 09:44 |
bshum |
Holds make sense to me. Usually. :) |
| 09:44 |
bshum |
There's always an explanation. |
| 09:44 |
bshum |
It may not be the answer you want.... but there is an answer. |
| 09:44 |
jonadab |
Heh. |
| 09:45 |
jonadab |
"Yes, you are first on the list. The book is sitting with seven others on the to-bindary shelf. When we get up to 50 books that need to be rebound, we'll send them to the bindary..." |
| 09:46 |
jonadab |
(We don't send books to the bindary any more, actually.) |
| 09:46 |
jonadab |
(Because books that have been rebound don't look as visually attractive and therefore don't circulate.) |
| 09:47 |
bshum |
Only 3771 active hold matrix rules to read through today :) |
| 09:47 |
jonadab |
Oh wow. |
| 09:47 |
bshum |
Read that as: "it could be more complicated" |
| 09:48 |
mmorgan |
In a consortium, we're trying to be fair both to libraries that buy the materials and to patrons who want the materials. So, yeah, it's complicated:) |
| 09:49 |
Dyrcona |
bshum: Yeah, you could only have 718! |
| 09:49 |
bshum |
Dyrcona: Yeah, I have to take time and do some finesse on all the rules. |
| 09:50 |
bshum |
We still haven't collapsed our circ rules to use fall through. |
| 09:50 |
bshum |
4551 there, whee....... |
| 09:50 |
csharp |
yowza |
| 09:50 |
kmlussier |
I guess this is why it's a good thing that we can all locally customize the holds queue position out of the display, because it will never be something we all agree upon. :) |
| 09:51 |
bshum |
customizations++ |
| 09:51 |
bshum |
:) |
| 09:51 |
kmlussier |
customizations++ YAOUS++ options++ |
| 09:51 |
* Dyrcona |
has a meeting. |
| 09:55 |
jonadab |
Yes, customizations are good. |
| 09:56 |
csharp |
@quote random |
| 09:56 |
pinesol_green |
csharp: Quote #29: "<Rogan_> Apparently I'm a trouble maker or busy body or something." (added by gmcharlt at 02:28 PM, July 11, 2012) |
| 10:02 |
|
ericar_ joined #evergreen |
| 10:06 |
csharp |
so is it a sound assumption that permissions that are referenced in fm_IDL.xml but not anywhere else are essentially "unused"? |
| 10:08 |
csharp |
example: DELETE_IMPORT_ITEM_ATTR_DEF is created in the database and gets translated, but the only other occurrence is in fm_IDL.xml |
| 10:08 |
csharp |
355:<retrieve permission="CREATE_IMPORT_ITEM_ATTR_DEF UPDATE_IMPORT_ITEM_ATTR_DEF DELETE_IMPORT_ITEM_ATTR_DEF ADMIN_IMPORT_ITEM_ATTR_DEF" context_field="owner"/> |
| 10:08 |
csharp |
357:<delete permission="DELETE_IMPORT_ITEM_ATTR_DEF ADMIN_IMPORT_ITEM_ATTR_DEF" context_field="owner"/> |
| 10:10 |
jeff |
Since the permission exists in the database and the IDL, why are you considering it "unused"? |
| 10:11 |
csharp |
jeff: I guess because most perms I encounter are referred to somewhere in the business logic (perl, JS) |
| 10:11 |
jeff |
My understanding is that for interfaces which use pcrud, the IDL and database are the only place the permissions need to exist. |
| 10:11 |
csharp |
ah... |
| 10:12 |
csharp |
pcrud is not something I've investigated before |
| 10:20 |
|
julialima_ joined #evergreen |
| 10:28 |
|
gdunbar joined #evergreen |
| 10:42 |
* berick |
confirms they are used by pcrud |
| 10:42 |
_bott_ |
I should know this, but, what ever happened to the OPAC language selection? I see that dbs: / Laurentian has an option, but did it fall out of the main code base? I've specifically been asked about Spanish, which I know had some work done at some point. |
| 10:42 |
berick |
_bott_: it's only visible if you have additional languages configured |
| 10:44 |
berick |
_bott_: https://laurentian.concat.ca/eg/opac/results?query=french+history&qtype=keyword&fi%3Asearch_format=&locg=105&sort=&detail_record_view=1 |
| 10:44 |
_bott_ |
Ah! "IF ctx.locales.keys.size > 1" If I build it, they will come |
| 10:44 |
berick |
:) |
| 10:45 |
berick |
IIRC it boils down to having a .po file in place for the additional language |
| 10:45 |
berick |
configured in eg_vhost.conf |
| 10:45 |
_bott_ |
Gotcha |
| 10:45 |
berick |
(and having a matching locale in the db -- of which there are already several) |
| 10:47 |
|
sarabee joined #evergreen |
| 10:50 |
tsbere |
I suppose if your locales.keys.size < 1 you have a bigger problem than just no selector. ;) |
| 10:52 |
_bott_ |
So now that I know what I'm looking for, is anyone aware of any up to date work on a Spanish translation? |
| 10:57 |
gmcharlt |
_bott_: per https://translations.launchpad.net/evergreen, looks like last time anybody supplied translations was last September |
| 10:59 |
kmlussier |
bshum / dbwells: If I have a fix for bug 1373203, is it something you view as being backportable? I've always considered that issue to be a bug, but I could see where it might be a gray area. |
| 10:59 |
pinesol_green |
Launchpad bug 1373203 in Evergreen "Need a more intuitive means of escape after clicking Advanced Hold Options" (affected: 3, heat: 18) [Medium,Confirmed] https://launchpad.net/bugs/1373203 - Assigned to Kathy Lussier (klussier) |
| 11:00 |
|
sciani joined #evergreen |
| 11:04 |
|
mllewellyn joined #evergreen |
| 11:17 |
dbwells |
kmlussier: In my opinion, cases like this one depend on the level of changes to the code. If the changes are relatively simple, I'd backport it, but if they are more fundamental, it's probably really a new feature. I know that just kicks the can a bit, but it's the best I've got. |
| 11:19 |
kmlussier |
dbwells: I have a branch at working/user/kmlussier/lp1373203-let-users-escape-metarecord-holds. I just haven't had a chance to do anything beyond light testing, but should be able to post it to LP later today. |
| 11:30 |
|
dreuther_ joined #evergreen |
| 11:34 |
* dbs |
always likes getting "System was down yesterday so we recorded circulations in Word" messages |
| 11:35 |
dbs |
(first, local network was down, the library system was fine--but I get what they mean; second, we have an offline client! Jeez.) |
| 11:43 |
|
vlewis joined #evergreen |
| 11:45 |
csharp |
dbs: many of our folks FEAR THE STANDALONE too |
| 11:47 |
dbs |
csharp: I suspect it's largely "We never use it, except in crisis mode, and therefore aren't confident that we're using it right, whereas Word gives us 100% feedback" |
| 11:48 |
dbs |
So maybe if standalone provided easy access to the list of everything that's been recorded so far, it might reassure them they're using it right |
| 11:53 |
tsbere |
I can at least understand "our local network was down so we couldn't even log into the domain, so we recorded circs on the laptop that doesn't have Evergreen on it in Word" |
| 11:58 |
|
BigRig_ joined #evergreen |
| 12:03 |
dbs |
but you don't even need to log into the domain for standalone, at least not if you've connected in the past |
| 12:03 |
berick |
phasefx: curious if you tested commit e45a691 in google chrome ("add a Retrieve All These Patrons button") |
| 12:04 |
berick |
w/ more than one user selected |
| 12:05 |
berick |
phasefx: i ask becuase .. search down for "opening multiple tabs" in http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_notes&s[]=browser&s[]=client |
| 12:06 |
phasefx |
berick: I did test it. Chrome offered an option for allowing the web page to open multiple tabs.. it showed up as an icon on the location bar |
| 12:07 |
goood |
berick: yeah, it's the "enable pop-ups for this site" feature that allows opening multiple tabs |
| 12:07 |
berick |
crazy, is that new? |
| 12:07 |
berick |
either way.. cool! |
| 12:07 |
berick |
that was really bugging me |
| 12:08 |
goood |
unsure when that happened, but gmcharlt found the causal link in 2015, I think |
| 12:08 |
|
buzzy joined #evergreen |
| 12:09 |
berick |
excellent |
| 12:09 |
gmcharlt |
open all the things in all the tabs! |
| 12:10 |
tsbere |
dbs: In regards to "can't log into the domain" - The situation I recall was "can't log into the *windows* domain", aka "can't log into the PC, forget about getting to Evergreen" |
| 12:11 |
dbs |
oh, heh, gotcha |
| 12:12 |
dbs |
How's memory usage if you select 10 patrons and open up all those tabs? |
| 12:13 |
gmcharlt |
dbs: to be measured... my gut feeling is that some sort of limit will need to be placed on it |
| 12:13 |
gmcharlt |
to avoid the even-if-10-is-OK-200-is-surely-not factor |
| 12:15 |
kmlussier |
Remind me...where does the Retrieve All These Patrons button display? |
| 12:16 |
berick |
patron search, IIRC |
| 12:17 |
phasefx |
also in Item Status -> Circ History |
| 12:18 |
gmcharlt |
and record buckets |
| 12:19 |
gmcharlt |
and IIRC copy buckets |
| 12:35 |
jonadab |
dbs, csharp: Yes, our staff here won't use the ILS offline either. And yes, the Children's Room staff have been known to scan barcodes into Notepad. |
| 12:35 |
jonadab |
The good news is, they don't seem to mind putting them into the ILS themselves when it comes back online. |
| 12:36 |
jonadab |
And yeah, never using it except in an emergency is probably highly relevant to why they're not comfortable with it. |
| 12:38 |
Dyrcona |
Anyone remember how to restart a single service with opensrf.pl or whatever it was called? |
| 12:39 |
jonadab |
osrf-control.sh ? |
| 12:39 |
Dyrcona |
osrf_control is new. This is what predated it. |
| 12:39 |
jonadab |
AH. |
| 12:39 |
Dyrcona |
Maybe google knows. |
| 12:41 |
berick |
Dyrcona: osrf_control is opensrf-perl.pl w/ some additions/changes. restarting a single service should be very similar |
| 12:41 |
berick |
--service <name> --restart IIRC |
| 12:41 |
Dyrcona |
Ah, that's what I thought, but wasn't 100% sure. |
| 12:41 |
gmcharlt |
exactly |
| 12:41 |
gmcharlt |
and, of course, that works for services written in C, too |
| 12:42 |
Dyrcona |
Did you know to say --localhost or -l with it? |
| 12:42 |
gmcharlt |
berick++ |
| 12:42 |
Dyrcona |
s/know/need/ |
| 12:42 |
Dyrcona |
I seem to recall that one did. |
| 12:42 |
gmcharlt |
Dyrcona: for a default configuration, typically one does |
| 12:42 |
|
ericar_ joined #evergreen |
| 12:43 |
gmcharlt |
unless one's gone to the trouble of including specific hostnames in opensrf_core.xml |
| 12:43 |
Dyrcona |
Also, when did the switch become official? 2.4? 2.5? |
| 12:44 |
Dyrcona |
Yeah, we have hostnames in our config, but I'm working on some generic instructions. |
| 12:44 |
Dyrcona |
Hopefully, the reader knows.... :) |
| 12:44 |
gmcharlt |
Dyrcona: osrf_control was introduced in 2.3 |
| 12:45 |
gmcharlt |
and osrf_ctl.sh was removed in 2.4 |
| 12:45 |
Dyrcona |
gmcharlt: Thanks. |
| 12:45 |
Dyrcona |
I was just looking at the git history. |
| 12:45 |
Dyrcona |
berick++ |
| 12:45 |
Dyrcona |
gmcharlt++ |
| 12:46 |
Dyrcona |
So the question is if I want the instructions to go all the way back to 2.2. |
| 12:46 |
Dyrcona |
Does anyone still run something that old? |
| 12:47 |
gmcharlt |
2.5, technically speaking |
| 12:47 |
gmcharlt |
once we desupport EG 2.5 entirely, Opensrf 2.2.x can also go away, methinks |
| 12:48 |
gmcharlt |
but if your doc is staying in the realm of fully-supported EG releases, then I think there's no need to mention osrf_ctl.sh at all |
| 12:48 |
Dyrcona |
Right. |
| 12:48 |
jonadab |
Ah, I had the filenames of osrf_ctl.sh and osrf_control mixed up with one another. |
| 12:48 |
Dyrcona |
I'll stick with that. |
| 12:48 |
Dyrcona |
Thanks, again! |
| 12:48 |
gmcharlt |
berick: do you recall if we're officially dropping 2.5.x once 2.8.0 is out? |
| 12:49 |
berick |
gmcharlt: doesn't it go into the 3-month security patch window? |
| 12:49 |
berick |
or, wait, would that be 2.6? |
| 12:50 |
gmcharlt |
I think that might be 2.6... |
| 12:50 |
gmcharlt |
as 2.5 is currently security-updates-only |
| 12:50 |
berick |
2.5 should be done, then |
| 12:50 |
berick |
should have been 3 months ago |
| 12:50 |
berick |
well, 2 |
| 12:50 |
|
krvmga joined #evergreen |
| 12:52 |
bshum |
Hmm |
| 12:53 |
bshum |
Aha, I guess you're right. |
| 12:53 |
bshum |
2.5 is done. |
| 12:53 |
bshum |
Well, sorta. |
| 12:53 |
bshum |
It's 15 months from first release. |
| 12:54 |
|
akilsdonk joined #evergreen |
| 12:54 |
bshum |
2.5 was roughly November 2013? So... security only was from November 2014 till February 2015. |
| 12:54 |
bshum |
Or something like that. |
| 12:54 |
bshum |
It's soon done |
| 12:54 |
berick |
ah, wasn't a sept. release date |
| 12:54 |
berick |
makes sense |
| 12:55 |
|
Stompro joined #evergreen |
| 12:56 |
dbwells |
The release was on 11/11/13, so I say we stick a fork in it by all accounts. |
| 12:57 |
Dyrcona |
Well, except for the 6 months of security updates (if any). |
| 12:58 |
Dyrcona |
Speaking of releases, berick, do you expect 2.8 beta to be "on time?" ;) |
| 12:58 |
* Dyrcona |
missed bshum's comment. |
| 12:59 |
bshum |
dbwells: +1, goodbye 2.5. |
| 12:59 |
bshum |
:) |
| 13:04 |
Dyrcona |
bye, bye, Evergreen 2.5. I drove my Chevy to the levy but the levy was dry. |
| 13:04 |
* krvmga |
frustrated with git because of not using it often enough to get to know it. |
| 13:04 |
krvmga |
Dyrcona++ |
| 13:06 |
* Dyrcona |
loves git and is considering walking on the wild side of submodules for one project. |
| 13:09 |
csharp |
@quote add < Dyrcona> bye, bye, Evergreen 2.5. I drove my Chevy to the levy but the levy was dry. |
| 13:09 |
pinesol_green |
csharp: The operation succeeded. Quote #106 added. |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:21 |
kmlussier |
krvmga++ #First commit to the working repository. |
| 13:21 |
csharp |
eeevil: around? |
| 13:21 |
goood |
csharp: -ish. what's up? |
| 13:22 |
jeff |
for those curious about the change in Chrome with regard to multiple window.open() calls, I think this bug gives a few clues as to timeline -- may have only been fixed in September 2014: https://code.google.com/p/chromium/issues/detail?id=158274 |
| 13:22 |
csharp |
well, I'd appreciate your eyes on a report SQL building issue I've hit... I'll pastebin something in a second that you can view at your leisure ;-) |
| 13:23 |
goood |
csharp: point me at it. I could use a break :) |
| 13:24 |
csharp |
ok - basically, the SQL builder appears to be ignoring the fieldmapper regarding which field to join on |
| 13:26 |
|
Arlene joined #evergreen |
| 13:28 |
csharp |
goood: http://pastie.org/9975450 |
| 13:28 |
|
sandbergja joined #evergreen |
| 13:29 |
csharp |
goood: if you need any of the generated debug info, I can provide that too - I'm stumped, though :-/ |
| 13:31 |
|
gdunbar joined #evergreen |
| 13:32 |
* csharp |
argues with his wife about whether he just saw the sun break through the clouds for about 30 seconds |
| 13:32 |
Dyrcona |
Sun? I don't think it exists any more. |
| 13:35 |
krvmga |
Dyrcona: that's just a legend. |
| 13:36 |
krvmga |
i heard the village elders speak of this thing they called "sun". |
| 13:36 |
berick |
Dyrcona: i have no reason to expect 2.8b to be delayed |
| 13:36 |
* csharp |
remembers big yellow face from his youth - it warmed the sea |
| 13:36 |
krvmga |
it must have existed once upon a time. |
| 13:38 |
goood |
csharp: so, might_have is more like has_many than has_a, in that it's used (see ahr) for virtual fields and restricts them to one remote object. because age_protect is not virtual on acp, you'll want to make the reltype has_a, and use nullability to turn it into a left (child nullable) join |
| 13:38 |
jonadab |
Nasssty yellow face. It watches us, my precious. Scorches us. |
| 13:39 |
csharp |
goood: ok - makes sense - then I'll change my bug report on that too, then |
| 13:39 |
jonadab |
That's why we doesn't go into the Big Room where it lives very often. |
| 13:39 |
csharp |
goood: thanks for the guidance |
| 13:39 |
krvmga |
jonadab++ |
| 13:40 |
csharp |
eww- already pushed to master :-/ |
| 13:40 |
goood |
np, and aye :) |
| 13:40 |
|
montgoc1 joined #evergreen |
| 13:40 |
csharp |
bug 1419813 should be reverted somehow |
| 13:40 |
pinesol_green |
Launchpad bug 1419813 in Evergreen "wrong default join type for config.rule_age_hold_protection in reports" (affected: 1, heat: 6) [Medium,Fix committed] https://launchpad.net/bugs/1419813 |
| 13:41 |
csharp |
so, should that be a new bug, logistically? |
| 13:42 |
bshum |
csharp: Well, 2.7.4, 2.6.7, and 2.8-beta have yet to be cut. |
| 13:42 |
bshum |
So.............. you could get that reverted or fixed on the same bug as a followup. IMO. |
| 13:42 |
csharp |
I think I'll just amend the original report and recommend reverting |
| 13:42 |
csharp |
does that require a signoff too? :-/ I've not been in this situation before |
| 13:43 |
bshum |
I haven't been following |
| 13:43 |
bshum |
So is the bug that it was right the original way? |
| 13:43 |
csharp |
bshum: correct |
| 13:43 |
csharp |
conceptually correct in some ways, but functionally wrong |
| 13:44 |
csharp |
"it looks right, but it don't work" |
| 13:44 |
goood |
csharp: for some background, I used the same definitions as Class::DBI for the reltype values: http://search.cpan.org/~tmtm/Class-DBI-v3.0.17/lib/Class/DBI.pm#might_have |
| 13:44 |
bshum |
Well, since gmcharlt pushed it, I'd poke him to revert it. But I suppose any of us could pull it out and then mark that bug as "invalid" based on your newest findings. |
| 13:45 |
Dyrcona |
Well, sounds like it still needs a change to indicate nullability? |
| 13:45 |
csharp |
goood: cool |
| 13:47 |
gmcharlt |
csharp: bshum: I'll take a look at it now |
| 13:47 |
csharp |
gmcharlt: thanks |
| 13:48 |
csharp |
gmcharlt: I would recommend reverting the change but considering the bug still active, since, as Dyrcona suggests, the original problem still exists |
| 13:48 |
goood |
Dyrcona: might_have indicates nullability ... what I don't recall OTTOMH is what the default join type is -- and different columns would demand different default join types. au.card, for instance, would want to default to an inner join, where as age_protect (obv, for csharp, at least) wants to be a left join |
| 13:48 |
Dyrcona |
goood: OK. |
| 13:48 |
goood |
what we really need is a nullable flag on <link>s |
| 13:48 |
csharp |
default is "has_a" |
| 14:09 |
pinesol_green |
[evergreen|Galen Charlton] Revert "LP#1419813 Fix default joins for config.rule_age_hold_protection." - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=922bdf4> |
| 14:18 |
Dyrcona |
"Your branch is behind master by 36 commits...." Geez, it was only Friday morning when I last pulled. ;) |
| 14:33 |
bshum |
Heh |
| 14:34 |
Dyrcona |
Nope, I was off by 1... It was Thursday. |
| 14:34 |
* Dyrcona |
segfaults. |
| 14:48 |
|
ericar_ joined #evergreen |
| 14:51 |
Stompro |
Our new 42u rack for evergreen servers has arrived, woohoo. |
| 14:51 |
bshum |
Beastly. |
| 14:51 |
* bshum |
remembers those days fondly. |
| 14:52 |
* bshum |
also remembers how the "server room" (aka, tiny closet) ended up 100+ degrees one day in the summer. |
| 14:52 |
jonadab |
Wow, enjoy. Our servers are in the coat closet. |
| 14:52 |
Stompro |
It's not all for Evergreen servers, we just needed more room to fit in the new servers. |
| 14:52 |
jonadab |
We do, fortunately, have an AC unit in there. |
| 14:53 |
bshum |
So did we. Till it died. |
| 14:53 |
Stompro |
our rack is in a 2000SF basement room with cement walls that keep everything nice a cool. |
| 14:53 |
* bshum |
is glad we don't host our own equipment anymore. |
| 14:54 |
gmcharlt |
Stompro: I misread that as a 42U *server* |
| 14:54 |
gmcharlt |
and was like... WOW!!! |
| 14:54 |
* bshum |
wants that server. |
| 14:54 |
bshum |
Well, run our own server room I mean. We keep the servers elsewhere now. |
| 14:54 |
* bshum |
sometimes missing walking (okay, RUNNING) down the hall to check on them. |
| 14:55 |
Stompro |
That is why I submitted the PO for the powered exoskeleton, so I could mount our new 42U server :) |
| 14:55 |
gmcharlt |
Stompro++ |
| 14:55 |
Dyrcona |
We will soon be in a colo situation, but the servers will be just down the hall. |
| 14:59 |
dbs |
The Raspberry Pi 2 has 1GB of RAM, almost enough to run Evergreen. |
| 15:00 |
bshum |
dbs: I was thinking about if we did it in clusters. |
| 15:00 |
bshum |
Like PG on one Pi2 and apache/Evergreen on another one |
| 15:00 |
bshum |
Or a "brick" of Pi2 would definitely pull it off. |
| 15:00 |
bshum |
Or you know... tuning :) |
| 15:02 |
dbs |
bshum: mmm, yeah, bricks would work there |
| 15:03 |
* bshum |
smells conference presentation material there |
| 15:04 |
jboyer-isl |
Blade servers? How about note card servers! |
| 15:04 |
jboyer-isl |
SanDisk profits jump 30% Q3 2015 |
| 15:04 |
bshum |
Speaking of which |
| 15:04 |
bshum |
Proposals deadline Friday |
| 15:06 |
Dyrcona |
Has library settings editor for web staff client been done? Or, is it just a drop in 'cause the interface is mostly written in Dojo? |
| 15:10 |
|
akilsdonk joined #evergreen |
| 15:20 |
kmlussier |
Dyrcona: I haven't seen it yet. I was assuming it would be done during sprint 4 - admin & reporting |
| 15:20 |
gmcharlt |
bshum: you may be interested in the pullrequest for bug 1154579 |
| 15:20 |
pinesol_green |
Launchpad bug 1154579 in Evergreen "Attempting to delete a copy location with attached copies should display an error message" (affected: 5, heat: 22) [Low,Confirmed] https://launchpad.net/bugs/1154579 |
| 15:20 |
gmcharlt |
Dyrcona: kmlussier: most likely yes, and most likely yes |
| 15:20 |
bshum |
gmcharlt: I was thinking about that on Saturday while I was poking at it more. |
| 15:21 |
bshum |
gmcharlt++ # I'll poke at your branch |
| 15:21 |
gmcharlt |
bshum: another thing that occurs to me: I'd argue that it should be possible to see logically-deleted locations in the copy location editor |
| 15:22 |
gmcharlt |
not necessarily to undelete them, although that wouldn't be hard, but just to be aware of them for potential reporting purposes |
| 15:22 |
gmcharlt |
bshum: I'll also shortly have a branch that slaps on a couple more acpl.deleted = 'f' clauses |
| 15:22 |
kmlussier |
Proposal deadline is this week? Wow |
| 15:24 |
bshum |
gmcharlt: Seeing deleted locations sounds like a nice add-on to the feature :) |
| 15:24 |
gmcharlt |
bshum: and/or a bugfix, depending on one's POV :) |
| 15:25 |
gmcharlt |
(to be clear, I don't have particularly strong feelings on that point) |
| 15:25 |
jboyer-isl |
bshum, gmcharlt: It seems odd to me, because you can’t see anything else that’s been deleted. (bre, acp, acn, etc.) |
| 15:25 |
jboyer-isl |
Oops, you can see bre. |
| 15:26 |
gmcharlt |
yep, you can see bre; but also, acpl counts more as configuration rather than transient data, IMO |
| 15:27 |
jboyer-isl |
I can see that. |
| 15:28 |
bshum |
Question |
| 15:28 |
bshum |
Hmm, wait.... |
| 15:28 |
* bshum |
doublechecks |
| 15:32 |
Dyrcona |
Speaking of sprint-4. Is there a public place where the web client sprint plans have been shared? My Google-Fu is weak today. |
| 15:32 |
kmlussier |
There is this: http://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:dev_sprints |
| 15:32 |
* kmlussier |
was just looking for that info |
| 15:33 |
|
gdunbar joined #evergreen |
| 15:33 |
bshum |
gmcharlt: I tested the warning but I think it gave me an uncaught exception error in my console rather than displaying me anything |
| 15:33 |
bshum |
I'm double checking that. |
| 15:33 |
bshum |
Ah nevermind there it is |
| 15:34 |
bshum |
Testing by trying to delete "Stacks" for the demo concerto data just takes awhile to figure out that hey, maybe you can't do that. |
| 15:34 |
bshum |
I got the exception popup finally after a nonresponsive JS waiting |
| 15:34 |
Dyrcona |
kmlussier: Thanks muchly. |
| 15:35 |
Dyrcona |
I was getting documentation sprints and list archives. |
| 15:35 |
jboyer-isl |
bshum: That check is pretty basic and could probably be improved by studying some SQL. (Or even throwing a LIMIT 1 on the end to get the Q planner to stop being so picky) |
| 15:35 |
gmcharlt |
bshum: hmm, as there isn't actually an index on asset.copy.location... |
| 15:36 |
jboyer-isl |
gmcharlt++ # Thanks for taking care of the error messages. I didn’t know if that was the only action one could take on that page that would error out. |
| 15:38 |
bshum |
gmcharlt: Hmm, since the only unique constraint is now that the name/owning_lib is unique for non-deleted locations, showing all the locations could be "fun" if you realize that you've deleted past incarnations of the same copy location name multiple times or whatnot. |
| 15:38 |
* bshum |
just thinking through everything |
| 15:38 |
bshum |
Now that you're making me think harder. |
| 15:39 |
gmcharlt |
bshum: yep - one would probably want the form to filter deleted locs by default, and have a checkbox or something to display the deleted ones |
| 16:00 |
gmcharlt |
bshum: and now, bug 1424813 |
| 16:00 |
pinesol_green |
Launchpad bug 1424813 in Evergreen "a couple more queries should check for deleted copy locations" (affected: 1, heat: 6) [Low,New] https://launchpad.net/bugs/1424813 |
| 16:04 |
gmcharlt |
bshum: and bug 1424827 now exists, but just as a wishlist item |
| 16:04 |
pinesol_green |
Launchpad bug 1424827 in Evergreen "logically deleted copy locations should be accessible in copy location editor" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1424827 |
| 16:06 |
|
ericar_ joined #evergreen |
| 16:08 |
bshum |
gmcharlt++ # I'll go ahead and finish testing and push those working fixes to master in a bit. |
| 16:21 |
|
dreuther_ joined #evergreen |
| 16:24 |
|
akilsdonk joined #evergreen |
| 16:53 |
berick |
looking at working/collab/miker/web-client-28-rebase, which is browser client bug fixes, w/ a dash of features. |
| 16:54 |
berick |
i'd love to get it into the beta. it's a big list, though. anyone that can sign off on some would be appreciated. |
| 16:55 |
berick |
second, it does have some features. i'd prefer to merge those as well, since the browser client is not actually in use yet and IMO should not be restrained by the confines of the release schedule. |
| 16:55 |
berick |
(excepting any features that touch other parts of the system) |
| 16:55 |
berick |
opinions? |
| 16:56 |
jeff |
+1 but i may be biased. :-) |
| 16:56 |
Dyrcona |
+1 |
| 16:58 |
bshum |
+1 to this case |
| 16:58 |
bshum |
(but I reserve the right to revise my opinion on how we decide to merge web client code in future "releases") |
| 17:00 |
berick |
heh |
| 17:00 |
berick |
i'll allow it ;) |
| 17:09 |
kmlussier |
+1 |
| 17:09 |
pinesol_green |
[evergreen|Galen Charlton] LP#904581: when calculating hold status, be more careful about fetching transits - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f64806> |
| 17:09 |
pinesol_green |
[evergreen|Galen Charlton] LP#1423813: adjust some queries to account for deleted copy locations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4a1c335> |
| 17:09 |
pinesol_green |
[evergreen|Galen Charlton] LP#1154579: explicitly alert if copy location failed to be deleted - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c304ebb> |
| 17:11 |
bshum |
@later tell dbwells If you get a moment, I think Dyrcona wanted to get your eyes on https://bugs.launchpad.net/evergreen/+bug/1282286 to be fully fixed before we push signoffs to master, etc. |
| 17:11 |
pinesol_green |
bshum: The operation succeeded. |
| 17:11 |
pinesol_green |
Launchpad bug 1282286 in Evergreen "Pressing Shift-F3 in the MARC editor results in invalid lose data warning" (affected: 2, heat: 20) [Undecided,Confirmed] |
| 17:29 |
|
mmorgan left #evergreen |
| 18:19 |
|
wlayton joined #evergreen |
| 18:33 |
|
akilsdonk joined #evergreen |
| 20:52 |
|
mrpeters left #evergreen |
| 20:53 |
|
wlayton joined #evergreen |
| 23:01 |
|
RBecker joined #evergreen |
