| Time |
Nick |
Message |
| 04:12 |
|
Silva joined #evergreen |
| 04:29 |
|
b_bonner joined #evergreen |
| 04:29 |
|
mtcarlson_away joined #evergreen |
| 04:39 |
|
mtcarlson_away joined #evergreen |
| 04:39 |
|
b_bonner joined #evergreen |
| 05:20 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:05 |
|
geoffsams joined #evergreen |
| 07:01 |
|
Callender joined #evergreen |
| 07:05 |
|
Silva joined #evergreen |
| 07:24 |
|
mtcarlsoz joined #evergreen |
| 07:25 |
|
mrpeters joined #evergreen |
| 08:05 |
|
ericar joined #evergreen |
| 08:22 |
|
akilsdonk joined #evergreen |
| 08:23 |
|
akilsdonk_ joined #evergreen |
| 08:24 |
|
rjackson-isl joined #evergreen |
| 08:25 |
|
akilsdonk joined #evergreen |
| 08:32 |
|
collum joined #evergreen |
| 08:48 |
|
kmlussier joined #evergreen |
| 08:49 |
|
gsams joined #evergreen |
| 08:51 |
|
krvmga joined #evergreen |
| 08:51 |
|
jwoodard joined #evergreen |
| 08:52 |
krvmga |
now i'm back on the problem of the Place Hold link showing up in the staff client for electronic resources (like overdrive). |
| 08:53 |
krvmga |
hbrennan suggested yesterday to look at the copy locations editor. i did. there's nothing because there is no copy to have a location. |
| 08:53 |
krvmga |
so there's no location and there's no copy even if there was a location. |
| 08:54 |
krvmga |
tsbere suggests checking to see if the staff have PLACE_UNFILLABLE_HOLD permission. i'm doing that now. |
| 09:04 |
krvmga |
yes, staff have permission for PLACE_UNFILLABLE_HOLD. i would think that this was the culprit except that i see that system users, in general, also have this permission and yet the Place Hold doesn't appear in the OPAC for electronic resources. |
| 09:04 |
krvmga |
only in the staff client |
| 09:04 |
csharp |
krvmga: I think that's the way PLACE_UNFILLABLE_HOLD works - it looks to see if you're logged into the staff client |
| 09:05 |
|
kmlussier joined #evergreen |
| 09:05 |
|
mrpeters joined #evergreen |
| 09:06 |
krvmga |
csharp: ic. interesting. |
| 09:06 |
csharp |
since you mentioned that, it sounds to me that PLACE_UNFILLABLE_HOLD is the answer to your mystery |
| 09:07 |
csharp |
because it allows you to place a hold on a title even if there are no eligible copies |
| 09:07 |
csharp |
(in the hopes that one day, ONE DAY, there may be a copy to fill my hold, so help you God) |
| 09:08 |
krvmga |
csharp: if it works the way you said, this makes sense. the person at cwmars who would know the most about this is on vacation right now. tspindler thinks there was some good reason we gave this permission to staff but is not sure what it was. |
| 09:09 |
krvmga |
the issue we'll have to face here is that some library staff are getting confused about it. |
| 09:09 |
krvmga |
tsbere++ |
| 09:09 |
csharp |
krvmga: yeah, staff need it |
| 09:09 |
kmlussier |
krvmga: My guess is that you gave that permission so that they could place holds on age protected items. |
| 09:09 |
krvmga |
csharp++ |
| 09:09 |
csharp |
exactly |
| 09:10 |
krvmga |
kmlussier: you mean copy level holds? |
| 09:10 |
csharp |
we didn't grant it to staff after our 2.3 upgrade last year and got tickets nearly immediately |
| 09:10 |
kmlussier |
No, not copy level holds. |
| 09:10 |
krvmga |
you can place title holds on age protected items in the opac |
| 09:10 |
csharp |
though it does sound like we need an enhancement to the logic to exclude items that will *never* have copies |
| 09:10 |
krvmga |
is that also related to the PLACE_UNFILLABLE_HOLDS permission? |
| 09:10 |
kmlussier |
krvmga: That's because your users have that permission |
| 09:11 |
krvmga |
kmlussier: that's what i thought. |
| 09:11 |
csharp |
s/items/bibs/ |
| 09:11 |
krvmga |
csharp: i agree about the logic |
| 09:11 |
kmlussier |
So let's say you have a record with three copies that are all age protected. They may not be eligible to fill a hold for a particular patron, but they will be eligible in another month, so you don't want to turn that patron away from placing the hold. |
| 09:12 |
csharp |
not sure how those would be identifiable from a coding logic perspective though |
| 09:12 |
* kmlussier |
concurs with changing the logic. |
| 09:12 |
kmlussier |
Sounds like a Wishlist request. :) |
| 09:12 |
csharp |
krvmga: want to open a bug ticket on it? ;-) |
| 09:13 |
krvmga |
csharp: i will write it up and put it on launchpad. |
| 09:13 |
csharp |
and as far as staff go, "don't press that button!" might be the only approach at the moment |
| 09:14 |
krvmga |
csharp: lol, i just said something very similar to tspindler two minutes ago :) |
| 09:14 |
csharp |
:-D |
| 09:16 |
|
mmorgan joined #evergreen |
| 09:21 |
|
kbeswick joined #evergreen |
| 09:23 |
* csharp |
kills a long-running report with the name "TEST OMGS" |
| 09:23 |
jeff |
it can be useful to have some reporting on holds on bibs that have located uris, or reporting on holds on bibs with no copies |
| 09:24 |
csharp |
the "You Ain't Never Gonna Get that Book" report |
| 09:26 |
tsbere |
csharp / krvmga / kmlussier: I think age protected items allow hold overrides without the place unfillable permission. At the very least I don't recall anything looking for permissions on that one. |
| 09:27 |
|
yboston joined #evergreen |
| 09:27 |
tsbere |
(made more obvious by the fact patrons can still place those holds when the system doesn't check that perm unless you are staff) |
| 09:28 |
krvmga |
tsbere: so, despite this looking like the culprit, you're suggesting that it's not? |
| 09:28 |
krvmga |
CSI Evergreen |
| 09:28 |
|
Callender joined #evergreen |
| 09:29 |
tsbere |
krvmga: I am saying "granting that permission is not needed for age protected hold placement" - That doesn't mean there isn't a good reason otherwise. "New books are not holdable but not via age protection, and we want staff to be able to place holds on them anyway" for example. |
| 09:29 |
krvmga |
the actual case is that, for an Overdrive title, the Place Hold link doesn't appear in the public OPAC but, for the same Overdrive title, the Place Hold link will appear in the staff client. |
| 09:30 |
tsbere |
The permission in question is "I don't care what the bib is, how many copies (if any), what those copies say, etc, give staff the option of placing the hold anyway" - So yes, Overdrive titles will get a place hold link, and staff will be able to use it. |
| 09:31 |
krvmga |
ok, so it's still worth putting it on launchpad. |
| 09:31 |
krvmga |
book him, danno. |
| 09:31 |
kmlussier |
Bug 1194860 is what made me think the Place Unfillable Hold permission was required for age protected items. |
| 09:31 |
pinesol_green |
Launchpad bug 1194860 in Evergreen ""You have permission to override some of the failed holds." appearing when it should not for patrons in the OPAC" (affected: 6, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/1194860 |
| 09:32 |
krvmga |
wow, i just realized how old that reference was. |
| 09:38 |
|
Callender_ joined #evergreen |
| 09:48 |
|
mrpeters joined #evergreen |
| 10:14 |
krvmga |
https://bugs.launchpad.net/evergreen/+bug/1334684 |
| 10:14 |
pinesol_green |
Launchpad bug 1334684 in Evergreen "logic changes in place unfillable holds needed" (affected: 1, heat: 6) [Undecided,New] |
| 10:18 |
krvmga |
i thought there had been some development to strip out trailing spaces (or other invisible characters) from barcode pastes from the opac into staff client item status. is this ringing a bell for anyone? |
| 10:19 |
kmlussier |
I recall stripping spaces at checkout and maybe even checkin, but not item status. |
| 10:19 |
mmorgan |
Me too. I remember thinking it would be useful for item status as well. |
| 10:21 |
krvmga |
kmlussier: that must be what i was recalling. |
| 10:21 |
krvmga |
could this be related? https://bugs.launchpad.net/evergreen/+bug/1028544 |
| 10:21 |
pinesol_green |
Launchpad bug 1028544 in Evergreen 2.4 "Util.js trim doesn't do what it says." (affected: 1, heat: 6) [Undecided,Triaged] |
| 10:21 |
kmlussier |
krvmga: I think DPearl1 did that work, so you can check with him. |
| 10:28 |
kmlussier |
Guess I was wrong. And it looks like it was only checkout. bug 1197050 |
| 10:28 |
pinesol_green |
Launchpad bug 1197050 in Evergreen "Trim away whitespace from barcodes" (affected: 5, heat: 22) [Wishlist,Fix released] https://launchpad.net/bugs/1197050 |
| 10:28 |
krvmga |
https://bugs.launchpad.net/evergreen/+bug/1334689 |
| 10:28 |
pinesol_green |
Launchpad bug 1334689 in Evergreen "trailing spaces not trimmed from barcode pastes in item status" (affected: 1, heat: 6) [Undecided,New] |
| 10:29 |
krvmga |
i posted that so that it would be on record for Dan to look at |
| 10:29 |
kmlussier |
krvmga: Also see https://bugs.launchpad.net/evergreen/+bug/1332651 that was just recently submitted. |
| 10:29 |
pinesol_green |
Launchpad bug 1332651 in Evergreen "Screens are inconsistent when there is a space within the barcode of items or patrons" (affected: 1, heat: 6) [Undecided,New] |
| 10:30 |
kmlussier |
It looks like some community discussion is warranted. |
| 10:30 |
|
tspindler joined #evergreen |
| 10:32 |
krvmga |
kmlussier: i thought that dpearl had done some development that solved 1332651 |
| 10:32 |
krvmga |
i'll have to check. |
| 10:32 |
kmlussier |
krvmga: I'm also inclined to mark your new one as a duplicate since it seems the best outcome of Callender's bug report is to make a decision on spacing in barcodes and then to have each of these interfaces comply with that decision. |
| 10:33 |
kmlussier |
krvmga: In looking at the old bug reports, DPearl's code stripped spaces at login. There is still a lot of inconsistency in Evergreen. |
| 10:34 |
krvmga |
kmlussier: i thought callendar's bug report was talking about internal spaces. maybe the two should be combined. |
| 10:34 |
Callender |
yes, it was |
| 10:35 |
Callender |
I think trimming beginning and trailing spaces is ok, but some libraries use spaces within barcodes, and trimming those on some screens causes bad things |
| 10:35 |
Callender |
so barcodes are allowed to be entered with spaces in them, but then none of the search screens allow spaces when searching for them.. so you can never find them |
| 10:35 |
kmlussier |
Ah, ok. Then krvmga's bug report is a little different. |
| 10:35 |
krvmga |
I think that solving one of these doesn't solve the other. |
| 10:35 |
* kmlussier |
concurs. |
| 10:36 |
krvmga |
krvmga agrees with kmlussier that community discussion is called for. |
| 10:47 |
mmorgan |
I find that when entering a barcode with spaces in the copy editor, the spaces are stripped out. I didn't think it was possible to save a barcode with spaces. |
| 10:55 |
jeff |
The behavior has changed over time, and can be inconsistent between different interfaces or different types of barcodes. Also, migrations especially can introduce/preserve spaces. |
| 10:58 |
mmorgan |
In our previous system, we had a mix of barcodes with spaces and without. When we migrated, we decided to strip out all spaces because we could not see a way to save a barcode with a space. |
| 10:58 |
mmorgan |
Are there still some interfaces in the client that allow barcodes with spaces? |
| 11:05 |
mmorgan |
... storing barcodes with spaces, that is. |
| 11:12 |
Callender |
the patron editor allows barcodes to be saved with spaces within them, but the patron search will strip them |
| 11:36 |
* krvmga |
away |
| 11:43 |
jeff |
That moment when you're excited about and investigating a product and interested in working with the vendor to make it work well with your environment... and then you get an initial quote and the excitement ends. |
| 12:01 |
hopkinsju |
I love this wording from the default 500 error page: "Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error." |
| 12:01 |
hopkinsju |
In other words "WHAT DID YOU DO?" |
| 12:15 |
jeffdavis |
All errors are the user's fault, for a sufficiently broad definition of "user". |
| 12:16 |
jeffdavis |
And, for that matter, of "fault". |
| 12:19 |
bshum |
Heh |
| 12:33 |
krvmga |
jeffdavis: this reminded me of 2+2=5 for very large values of 2. |
| 12:37 |
jeffdavis |
:) |
| 12:44 |
kmlussier |
I noticed that somebody changed some of the org unit names for the demo system at demo.evergreencatalog.com. I'm assuming the person who did it didn't have access to run autogen. Does that mean we might see some odd behavior there? |
| 12:45 |
bshum |
kmlussier: Potentially. Though that is a fun question... as to how often the demo system is reset nowadays |
| 12:46 |
kmlussier |
bshum: I asked that question a month or two ago, and my impression was that it wasn't being reset very often. |
| 12:46 |
|
kitteh_ joined #evergreen |
| 12:55 |
kmlussier |
So I am seeing some unexpected behavior on the demo system. I'm not sure if it's the autogen issue, but is there any chance somebody at ESI could reset the demo system sometime in the near future? :) |
| 12:56 |
kmlussier |
I was using it to get some DIG work done. I can use Dyrcona's server, but, since remington's July 1 deadline is looming, there might be other DIG folks who need it. |
| 12:58 |
* jeff |
tries to remember why some copies have no active_date |
| 12:58 |
bshum |
Maybe they aren't active yet. |
| 12:58 |
kmlussier |
Oh wait. The odd behavior was user error. Oops. |
| 12:59 |
kmlussier |
It helps if kmlussier enters the correct search terms. |
| 13:02 |
|
gsams joined #evergreen |
| 13:19 |
kmlussier |
eeevil: In the release notes for bug 1271630, you say that located URI's now uses the same sorting algorithm as copies. Does that mean I should expect the preferred library's copy to float to the top? If so, I don't see that happening. |
| 13:19 |
pinesol_green |
Launchpad bug 1271630 in Evergreen "Allow Located URIs to supply copy-like visibility to bibs" (affected: 1, heat: 6) [Wishlist,Fix released] https://launchpad.net/bugs/1271630 |
| 13:19 |
kmlussier |
I'm finishing up documentation for the new Located URI functionality, and I just want to make sure I understand how preferred library works with it. |
| 13:28 |
|
dreuther joined #evergreen |
| 13:36 |
|
akilsdonk_ joined #evergreen |
| 13:40 |
|
ldw joined #evergreen |
| 13:42 |
|
vlewis joined #evergreen |
| 13:51 |
|
akilsdonk joined #evergreen |
| 13:51 |
|
gsams joined #evergreen |
| 13:53 |
bshum |
t |
| 13:54 |
eeevil |
kmlussier: I'll look in a moment and verify or clarify |
| 14:11 |
eeevil |
@later tell kmlussier if you mean on the record detail page, yes, you should see the search-context-owned located URIs first, then pref_ou-owned located URIs listed second, then prox-ordered ones. that's the same way copies (well, actually, volumes) sort on the record detail page. they use the same logic. Here's the thing, though ... the located URI has to be owned by /exactly/ the prefered OU. if they are owned by the system and you pref and |
| 14:11 |
eeevil |
search OU are a branch, they'll sort by proximity |
| 14:11 |
pinesol_green |
eeevil: The operation succeeded. |
| 14:12 |
eeevil |
@later tell kmlussier and to be clear, the same would be true for volumes owned by a system, WRT actual copy sorting |
| 14:12 |
pinesol_green |
eeevil: The operation succeeded. |
| 14:16 |
|
bmills joined #evergreen |
| 14:17 |
|
frank____ joined #evergreen |
| 14:24 |
|
mrpeters left #evergreen |
| 14:26 |
frank____ |
hi all, when I run the autogen.sh -u command, and I got the org_unit_proximity empty, It's not normal right?, |
| 14:59 |
|
frank____ joined #evergreen |
| 14:59 |
|
gsams joined #evergreen |
| 14:59 |
|
vlewis joined #evergreen |
| 14:59 |
|
kitteh_ joined #evergreen |
| 14:59 |
|
Callender joined #evergreen |
| 14:59 |
|
yboston joined #evergreen |
| 14:59 |
|
kbeswick joined #evergreen |
| 14:59 |
|
mmorgan joined #evergreen |
| 14:59 |
|
jwoodard joined #evergreen |
| 14:59 |
|
mtcarlson_away joined #evergreen |
| 14:59 |
|
eby__ joined #evergreen |
| 14:59 |
|
sseng joined #evergreen |
| 14:59 |
|
Bmagic joined #evergreen |
| 14:59 |
|
hopkinsju joined #evergreen |
| 14:59 |
|
gmcharlt joined #evergreen |
| 14:59 |
|
eeevil joined #evergreen |
| 14:59 |
|
bshum joined #evergreen |
| 14:59 |
|
dkyle joined #evergreen |
| 14:59 |
|
jeff_ joined #evergreen |
| 14:59 |
|
pastebot joined #evergreen |
| 14:59 |
|
DPearl1 joined #evergreen |
| 14:59 |
|
book` joined #evergreen |
| 14:59 |
|
dconnor joined #evergreen |
| 14:59 |
|
RBecker joined #evergreen |
| 14:59 |
|
artunit joined #evergreen |
| 14:59 |
|
berickm joined #evergreen |
| 14:59 |
|
jeffdavis joined #evergreen |
| 14:59 |
|
phasefx2 joined #evergreen |
| 14:59 |
|
graced joined #evergreen |
| 14:59 |
|
pmurray_away joined #evergreen |
| 14:59 |
|
JLDAGH joined #evergreen |
| 14:59 |
|
egbuilder joined #evergreen |
| 14:59 |
|
wjr joined #evergreen |
| 14:59 |
|
_bott_ joined #evergreen |
| 14:59 |
|
dbs joined #evergreen |
| 14:59 |
|
ningalls joined #evergreen |
| 14:59 |
|
jl- joined #evergreen |
| 14:59 |
|
paxed joined #evergreen |
| 14:59 |
|
bradl joined #evergreen |
| 14:59 |
|
rangi joined #evergreen |
| 14:59 |
|
jventuro_ joined #evergreen |
| 15:02 |
hopkinsju |
We're seeing a really puzzling situation after upgrading to 2.6.1 - vandelay isn't allowing us to import records. After uploading a marc file, we are taken to the import queue, which is empty (shows 0 records). We see this in the postgres logs: http://paste.evergreen-ils.org/68 |
| 15:02 |
hopkinsju |
Strangely, if I don't supply a queue name, it *does* work - the import queue appears with the imported records. |
| 15:02 |
hopkinsju |
Unfortunately we've found this and one more issue since yesterday bshum |
| 15:03 |
|
rangi joined #evergreen |
| 15:03 |
|
rangi joined #evergreen |
| 15:03 |
|
paxed joined #evergreen |
| 15:04 |
hopkinsju |
Looking at the functions involved, vandelay.match_bib_record() calls oils_xpath_string(). When we did the database upgrade we actually just did a pg_dump of our 9.1 database, then 'psql < 'd it into our empty 9.2 database. |
| 15:04 |
bshum |
hopkinsju: Maybe a search path problem |
| 15:04 |
hopkinsju |
We had a couple errors during that apparently. they went to the screen but didn't get piped into the output log |
| 15:04 |
hopkinsju |
bshum: Yeah, we've run into that before. Since our db has it's roots in a 1.6.9 database, something like this comes up again and again. |
| 15:04 |
hopkinsju |
\df+ shows oils_xpath_string() 4 times |
| 15:05 |
hopkinsju |
db import errors http://paste.evergreen-ils.org/69 |
| 15:05 |
bshum |
hopkinsju: What we did when we copied our DB from 9.1 to 9.3 was to create the base DB and then set search_path, etc. prior to running the restore. |
| 15:15 |
|
shadowspar joined #evergreen |
| 15:15 |
|
akilsdonk joined #evergreen |
| 15:15 |
|
ktomita joined #evergreen |
| 15:15 |
|
tsbere joined #evergreen |
| 15:15 |
|
b_bonner joined #evergreen |
| 15:15 |
|
paxed joined #evergreen |
| 15:15 |
|
rangi joined #evergreen |
| 15:15 |
|
jventuro_ joined #evergreen |
| 15:15 |
|
bradl joined #evergreen |
| 15:15 |
|
jl- joined #evergreen |
| 15:15 |
|
ningalls joined #evergreen |
| 15:15 |
|
dbs joined #evergreen |
| 15:15 |
|
_bott_ joined #evergreen |
| 15:15 |
|
wjr joined #evergreen |
| 15:15 |
|
egbuilder joined #evergreen |
| 15:15 |
|
JLDAGH joined #evergreen |
| 15:15 |
|
pmurray_away joined #evergreen |
| 15:15 |
|
graced joined #evergreen |
| 15:15 |
|
phasefx2 joined #evergreen |
| 15:15 |
|
jeffdavis joined #evergreen |
| 15:15 |
|
berickm joined #evergreen |
| 15:15 |
|
artunit joined #evergreen |
| 15:15 |
|
RBecker joined #evergreen |
| 15:15 |
|
dconnor joined #evergreen |
| 15:15 |
|
book` joined #evergreen |
| 15:15 |
|
DPearl1 joined #evergreen |
| 15:15 |
|
pastebot joined #evergreen |
| 15:15 |
|
jeff_ joined #evergreen |
| 15:15 |
|
dkyle joined #evergreen |
| 15:15 |
|
bshum joined #evergreen |
| 15:15 |
|
eeevil joined #evergreen |
| 15:15 |
|
gmcharlt joined #evergreen |
| 15:15 |
|
hopkinsju joined #evergreen |
| 15:15 |
|
Bmagic joined #evergreen |
| 15:15 |
|
sseng joined #evergreen |
| 15:15 |
|
eby__ joined #evergreen |
| 15:15 |
|
mtcarlson_away joined #evergreen |
| 15:15 |
|
jwoodard joined #evergreen |
| 15:15 |
|
mmorgan joined #evergreen |
| 15:15 |
|
kbeswick joined #evergreen |
| 15:15 |
|
yboston joined #evergreen |
| 15:15 |
|
Callender joined #evergreen |
| 15:15 |
|
kitteh_ joined #evergreen |
| 15:15 |
|
vlewis joined #evergreen |
| 15:15 |
|
gsams joined #evergreen |
| 15:15 |
|
frank____ joined #evergreen |
| 15:15 |
|
bmills joined #evergreen |
| 15:15 |
|
ldw joined #evergreen |
| 15:15 |
|
dreuther joined #evergreen |
| 15:15 |
|
ericar joined #evergreen |
| 15:15 |
|
phasefx joined #evergreen |
| 15:15 |
|
mceraso joined #evergreen |
| 15:15 |
|
mtj_ joined #evergreen |
| 15:15 |
|
jboyer-isl joined #evergreen |
| 15:15 |
|
csharp joined #evergreen |
| 15:15 |
|
pinesol_green joined #evergreen |
| 15:15 |
|
berick joined #evergreen |
| 15:15 |
|
jeff joined #evergreen |
| 15:15 |
|
jcamins joined #evergreen |
| 15:18 |
|
kmlussier joined #evergreen |
| 15:19 |
eeevil |
frank____: you only need to use autogen at all when you change the hierarchy or name of an OU or the like. you never need -u ever anymore (assuming modern evergreen) |
| 15:21 |
frank____ |
ok ok, thanks :D |
| 15:22 |
eeevil |
bshum: right. you're just putting up a fence to stop the 2.5 version from leaking forward |
| 15:23 |
bshum |
Calling 0882 and 0883 then |
| 15:24 |
bshum |
Also, eeevil++ # people here have been super happy today when I pushed the fix to production :) |
| 15:29 |
eeevil |
bshum: great! if only I had tuits to look for the most direct fix for /all/ the db bugs... ;) |
| 15:29 |
eeevil |
(not that I'd always find such, but I do wish I could bury myself in the db and just clean stuff up) |
| 15:46 |
pinesol_green |
[evergreen|Mike Rylander] LP#925776: Recheck located uri visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a61c0c4> |
| 15:46 |
pinesol_green |
[evergreen|Mike Rylander] LP#925776 Adding upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=55520fd> |
| 15:46 |
pinesol_green |
[evergreen|Ben Shum] LP#925776 Stamping upgrade script for staff uri visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c2df1e> |
| 15:46 |
pinesol_green |
[evergreen|Ben Shum] LP#925776 Add placeholder script for backport to 2.5 for function staff uri visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b4af2fb> |
| 15:49 |
hopkinsju |
On another topic - one of our users believes that some parts have disappeared from her items. That is, she recalls cataloging the magazines with parts, but now that she goes back to it most of the parts (but not all) are missing. |
| 15:50 |
hopkinsju |
Turns out, what seems to have happened, is that a user at another library decided (since they didn't have any issues of Better Homes & Gardens older than Jan 2014) to go into Manage Parts and delete the "unneeded" ones. |
| 15:50 |
hopkinsju |
That of course, stripped the parts from already cataloged items at other libraries. |
| 15:50 |
pinesol_green |
Showing latest 5 of 8 commits to Evergreen... |
| 15:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1301599 TPAC add missing metabib filter label - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e26df3d> |
| 15:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1301599 TPAC replace aria-label with title - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7f7ed3c> |
| 15:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1301599 Additional TPAC facets structure markup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d8d6a52> |
| 15:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1301599 Remove duplicate title attributes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=189be48> |
| 15:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1301599 improved TPAC jacket alt text - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5131474> |
| 15:51 |
hopkinsju |
I'd like to submit this to launchpad, but I wanted to bring it up here first: Shouldn't we put a permission in place to keep users from deleting parts when they are in use? |
| 15:55 |
phasefx2 |
an overridable event (with associated password) |
| 15:57 |
hopkinsju |
Absolutely. |
| 15:57 |
tsbere |
I would prefer that parts get a "deleted" flag - at least then part holds don't break every interface that loads them when someone does wipe a part out. <_< |
| 15:57 |
tsbere |
That would also let us "undelete" them |
| 15:57 |
hopkinsju |
That's true, I did notice that bug tsbere |
| 15:57 |
phasefx2 |
oh, we you said strip, I thought it was deleting the copy part maps too |
| 15:57 |
jeff |
You do NOT want to lose this item: http://i.imgur.com/1Wmcju2.png |
| 15:58 |
hopkinsju |
But I think that even then - with a deleted flag - we should still require elevation |
| 15:58 |
hopkinsju |
or confirmation |
| 15:59 |
hopkinsju |
phasefx2: I'm not sure whether it deletes it from the map or not - I just assumed that a trigger would fire to clean that up after the part was blown away, but in any case, the *display* of the part is stripped from the item |
| 15:59 |
tsbere |
phasefx2 / hopkinsju: Due to foreign key relationships I believe the maps go away as well when the part gets deleted |
| 15:59 |
hopkinsju |
jeff: Imagine what that'd be worth if it were in mint condition |
| 16:02 |
phasefx2 |
but holds don't have f/k so yeah, bro-ack |
| 16:02 |
pinesol_green |
[evergreen|Dan Scott] LP#1326149 Use a TPAC-settable TIME_FORMAT for local time formats - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e5d269> |
| 16:04 |
egbuilder |
build #637 of evergreen-master-ubuntu-12.04-x86 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/637 blamelist: Bill Erickson <berick esilibrary.com> |
| 16:04 |
egbuilder |
build #605 of evergreen-master-fedora-18 is complete: Failure [failed test] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/605 blamelist: Bill Erickson <berickesilibrary.com> |
| 16:05 |
bshum |
Uh oh |
| 16:06 |
tsbere |
Looks like a missing %] on the multiple line in filter_group_selector.tt2 |
| 16:06 |
bshum |
Doh |
| 16:06 |
tsbere |
Or rather, that someone put a ; instead of a %] |
| 16:07 |
|
tspindler left #evergreen |
| 16:08 |
* tsbere |
doesn't know what the changeset is and supposes it could have been a removed line that used to contain the %] |
| 16:12 |
dbwells |
looks like 7e4e9d669 is the culprit |
| 16:12 |
pinesol_green |
[evergreen|Bill Erickson] LP#1301599 TPAC advanced search additional labels - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e4e9d6> |
| 16:14 |
tsbere |
Hmmm. Multiple ways to fix that one. |
| 16:18 |
|
jwoodard joined #evergreen |
| 16:19 |
bshum |
Hmm |
| 16:28 |
|
akilsdonk_ joined #evergreen |
| 16:35 |
yboston |
I would like a small code change to make it into 2.6.x ( bug 1152863 ) is dbwells the only person I should be talking to? |
| 16:35 |
pinesol_green |
Launchpad bug 1152863 in Evergreen "Support for traditional Boolean operators" (affected: 4, heat: 26) [Wishlist,Triaged] https://launchpad.net/bugs/1152863 |
| 16:35 |
kmlussier |
yboston: It's too late for 2.6 |
| 16:35 |
kmlussier |
It's a new feature. |
| 16:35 |
kmlussier |
yboston: We hope to get that code worked out in time for 2.7, though. |
| 16:35 |
yboston |
wrong bug number; bug 1327284 |
| 16:35 |
pinesol_green |
Launchpad bug 1327284 in Evergreen "Display "Imported As" in Vandelay queue" (affected: 7, heat: 36) [Undecided,New] https://launchpad.net/bugs/1327284 |
| 16:36 |
yboston |
(sorry) |
| 16:36 |
tsbere |
Ok, that latter bug is a small change. The other one is not. ;) |
| 16:37 |
kmlussier |
Heh |
| 16:42 |
bshum |
It's not a big change. But personally I still favor that towards 2.7 and not to be backported because it's a string change. |
| 16:42 |
bshum |
But that's just my opinion. |
| 16:43 |
* bshum |
defers to the wisdom of the 2.6 RM though to make that call. |
| 16:44 |
yboston |
bshum: thanks for the feedback, but that little string change is something that was sorely needed by many catalogers |
| 16:48 |
yboston |
bshum: what can I do to lobby to get it in 2.7? I don't think it is in master yet, unless my Git searching skills are not good enough |
| 16:48 |
bshum |
Well, like I said, I'm just one opinion. But no matter how small a change it is, exceptions to adding features after a major series has been released ought to be considered super carefully. |
| 16:48 |
bshum |
yboston: Oh if you want it in 2.7, I can pick it into master right now ;) |
| 16:48 |
yboston |
bshum: oh, for the record, we consider this a bug |
| 16:48 |
bshum |
It hasn't been pushed yet |
| 16:49 |
yboston |
not a new feature |
| 16:50 |
bshum |
Well, I view it as a new feature since it wasn't there before (broken or otherwise). |
| 16:50 |
bshum |
Bugs I generally classify as stuff that was there but broken :) |
| 16:50 |
yboston |
bshum: that is fine defintiion to follow |
| 16:50 |
yboston |
*is a fine |
| 16:51 |
yboston |
bshum: I will follow this approach, can we put it in 2.7 when you have time (since you are the 2.7 RM)? |
| 16:52 |
bshum |
yboston: Sure, I was going to work on reviewing new feature LP bugs after I got back from ALA next week. |
| 16:52 |
yboston |
bshum: cool |
| 16:52 |
kmlussier |
FWIW, any core committer could put it in 2.7. Not just the RM. |
| 16:53 |
bshum |
The first 2.7 alpha is scheduled for July 10 |
| 16:53 |
bshum |
So we have to poke at the new features soon anyways. |
| 16:53 |
bshum |
And yes, kmlussier is correct that any core committer can push reviewed work. |
| 16:54 |
yboston |
kmlussier: thanks, I got myself mixed up becuase it was a core committer that created the change and he did nto add it immediatly. made me think he had to wait for someone else. |
| 16:55 |
yboston |
I think the problem was that I took to long to create the sign-off branch at the time |
| 16:55 |
yboston |
*too |
| 16:55 |
bshum |
Eh, not necessarily yboston. It probably just got buried in the mix of all the other stuff going on. |
| 16:56 |
bshum |
Plus, for "new features" my general feeling was always to wait 7 days before committing the code anyways. |
| 16:56 |
yboston |
good to know |
| 16:56 |
bshum |
To give some review time for other community member input. |
| 16:57 |
yboston |
thabks for the explenation, makes total sense, specially for more complex changes |
| 17:02 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:05 |
bshum |
I have to run along home, but I'll try and see what we can do to fix that broken syntax later :\ |
| 17:14 |
|
mmorgan left #evergreen |
| 17:19 |
hopkinsju |
Has anyone here encountered a 500 server error when trying the "Show More Details" button in the OPAC? |
| 17:19 |
hopkinsju |
2014-06-26 16:18:40 CDT ERROR: invalid input syntax for integer: "" at character 64 |
| 17:19 |
hopkinsju |
2014-06-26 16:18:40 CDT STATEMENT: SELECT * FROM actor.org_unit_ancestor_setting( 'lib.info_url', '' ) AS "actor.org_unit_ancestor_setting" ; |
| 17:31 |
bshum |
hopkinsju: It looks like a problem with some of your org units |
| 17:31 |
bshum |
Like 150 - Carthage Public Library |
| 17:34 |
bshum |
Funny though, it's not consistently borked, cause record looks like it works |
| 17:34 |
bshum |
It reminds of what we were trying to fix with 462a352a44553f4815536c9de595570685bfcd83 where the variables in the template were goofy |
| 17:34 |
pinesol_green |
[evergreen|Ben Shum] Fix copy_info variables one last time for library_name_link purposes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=462a352> |
| 17:35 |
bshum |
Either it's a problem with the actual org unit settings, or there's something else awry |
| 17:35 |
jeffdavis |
If I had a Carthage Public Library in my consortium, I would want them to leave, so that I could make Roman history jokes about removing their data. |
| 17:37 |
bshum |
Interesting |
| 17:37 |
bshum |
Maybe it's transcendent records |
| 17:38 |
bshum |
Nope |
| 17:38 |
bshum |
Just random |
| 17:38 |
bshum |
Okay, really running home :) |
| 17:39 |
bshum |
hopkinsju: Good luck, you got a head scratcher there... I'd dig deeper at your apache logs and see what the internal server error says. Maybe it'll offer some pointers. |
| 17:45 |
* hopkinsju |
returns! |
| 17:51 |
pinesol_green |
[evergreen|Dan Wells] Fix syntax in filter_group_selector.tt2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=00aa874> |
| 17:54 |
|
akilsdonk joined #evergreen |
| 18:04 |
egbuilder |
build #639 of evergreen-master-ubuntu-12.04-x86 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-ubuntu-12.04-x86/builds/639 |
| 18:04 |
egbuilder |
build #607 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/607 |
| 18:51 |
RBecker |
Of course. |
| 19:22 |
|
edoceo joined #evergreen |
| 19:43 |
|
gsams joined #evergreen |
| 20:00 |
|
bmills joined #evergreen |
| 20:49 |
|
gsams joined #evergreen |
| 21:10 |
|
ldw joined #evergreen |
| 21:10 |
ldw |
1dge |
| 22:19 |
|
RBecker joined #evergreen |
| 23:30 |
|
RBecker joined #evergreen |
