| Time |
Nick |
Message |
| 00:47 |
|
dcook__ joined #evergreen |
| 03:34 |
|
sbrylander joined #evergreen |
| 03:34 |
|
dcook joined #evergreen |
| 05:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:21 |
rangi |
wtaf |
| 07:22 |
rangi |
i wish someone had told me 16 years ago that if you open source something, you are not allowed to work on it or maintain it anymore, ive been doing it wrong for 16 years |
| 07:24 |
rangi |
thats too much new info for me, im going to go bed, unless that is politically correct also |
| 07:26 |
|
collum joined #evergreen |
| 07:37 |
|
graced joined #evergreen |
| 07:49 |
|
mrpeters joined #evergreen |
| 07:50 |
|
jboyer-isl joined #evergreen |
| 07:55 |
|
jeff__ joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 08:12 |
|
darshana joined #evergreen |
| 08:24 |
|
Newziky1 left #evergreen |
| 08:29 |
|
Newziky1 joined #evergreen |
| 08:30 |
jboyer-isl |
@coffee |
| 08:30 |
* pinesol_green |
brews and pours a cup of El Salvador Los Planes Cup of Excellence 2006, and sends it sliding down the bar to jboyer-isl |
| 08:30 |
jboyer-isl |
Nothing quite takes the edge off the morning like 9 year old coffee. |
| 08:36 |
|
akilsdonk joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
krvmga joined #evergreen |
| 08:50 |
|
ericar joined #evergreen |
| 08:52 |
|
RoganH joined #evergreen |
| 08:58 |
|
Shae joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:01 |
|
maryj joined #evergreen |
| 09:16 |
|
tsbere joined #evergreen |
| 09:19 |
|
jwoodard joined #evergreen |
| 09:25 |
gmcharlt |
jboyer-isl: indeed, I've always found that being chased by coffee old enough to be sentient lends a special zest to the day |
| 09:26 |
jboyer-isl |
Definitely. Once coffee can walk on it's own it's time to let it go off into the world. |
| 09:28 |
|
yboston joined #evergreen |
| 09:29 |
* jeff |
eyes the day-old half-cup on his desk with renewed suspicion |
| 09:39 |
krvmga |
Jeff has grounds for suspicion. |
| 09:41 |
* jeff |
winces |
| 09:41 |
jeff |
(because of the pun, not the cold coffee) |
| 09:41 |
krvmga |
too early? |
| 09:41 |
jeff |
relevant, especially to gmcharlt's coffee-related tweet of this morning: http://en.wikipedia.org/wiki/Black_start |
| 09:42 |
gmcharlt |
jeff++ |
| 09:44 |
jboyer-isl |
krvmga++ |
| 09:44 |
jboyer-isl |
jeff++ |
| 09:45 |
jeff |
I have done the "insert k-cup, press button, walk back to desk, stare blankly at coffee cup on desk for a few seconds, DASH back to keurig..." |
| 09:46 |
kmlussier |
heh |
| 09:46 |
kmlussier |
I quite often re-warm my cup of coffee in the microwave, forget about it until it cools down again, then re-warm it again. |
| 09:46 |
kmlussier |
Then I repeat |
| 09:46 |
* mmorgan |
always says one can't make coffee in the morning unless one has had coffee |
| 09:47 |
krvmga |
mmorgan: the coffee catch-22 |
| 09:47 |
jeff |
keurig as blackstart capability for your more advanced coffee preparation device... |
| 09:48 |
kmlussier |
That's why I start with tea. It much easier to pour boiling water into a cup with a teabag. As long as you remember to boil the water. |
| 09:48 |
jeff |
but of course, as shown in the above examples even that can have its... challenges. |
| 09:48 |
krvmga |
my keurig machine conked out, much to my dismay and surprise. have to get a new one. |
| 09:49 |
krvmga |
jeff++ |
| 09:50 |
jeff |
So yesterday I hacked up Missing Pieces to check the item in question back out to the patron with a due date some fixed time in the future (could be an org unit setting, probably wouldn't make sense to have it go through the full circ policy set with some special flag), zero renewals, MAXFINES set and stop_fines_time equal to xact_start. |
| 09:50 |
jeff |
Notification goes out to patron of a fairly vague nature ("please contact the library for more info on what's missing/etc") |
| 09:51 |
jeff |
Then the idea is that staff will get a report of any items marked Missing Pieces in a given day, and they have a week to either 1) manually add a billing to the circ for a disc replacement fee, etc or 2) adjust the asset.copy.price to reflect the desired full amount that will be automatically billed at the end of the week. |
| 09:53 |
jeff |
Part of the idea is to not hit patrons immediately with the price (which would prevent them from checking items out, etc). |
| 09:54 |
jeff |
Of course, in the case of a $10 disc replacement fee being added somewhere between 0 and 7 days after marked Missing Pieces, that will prevent checkout. I guess we'll need to have procedure that permits staff to override/allow the checkout as long as the week hasn't passed. |
| 09:54 |
jeff |
Because short of staging the billing in an external fashion or having staff not manually add the replacement disc fee until the last minute, I don't have a way of having a "pending" bill. |
| 09:55 |
jeff |
Does this kind of workflow compare to other libraries present, or are we going far afield? |
| 10:01 |
mmorgan |
jeff: so all items marked "missing pieces" on days 0 - 7 are billed at the end of the week? Or did I read that wrong? |
| 10:02 |
jeff |
mmorgan: any circs with copies in a Missing Pieces status that have not had a manual bill added would be auto-billed the full price on or after day 7. Staff have a week to adjust the copy's price or to manually add a (usually partial) billing. |
| 10:04 |
mmorgan |
ok, I see. We don't have a formal Missing Pieces procedure in place. |
| 10:05 |
jeff |
We've been trying to move from a very manual process, involving hand-filled slips with checkboxes for each time staff attempts to contact a patron, etc. |
| 10:07 |
jeff |
Much simplification of the process, but we still find ourselves looking to adjust the Evergreen side of things a little bit. |
| 10:07 |
mmorgan |
Makes sense. The thing that bothers me about the Missing Pieces process, though, is that an item can be sitting on the shelf for quite some time, then get marked Missing Pieces. That checks it out to a patron who may have returned it some time ago. |
| 10:08 |
jeff |
Ah. Interesting. I don't think we have that often, but I'll now inquire as to what we do in that case. |
| 10:09 |
jeff |
We inspect the items for missing pieces when returned. If discovered later, I suspect that the way we handle it is different, but I've not explicitly asked. |
| 10:09 |
jeff |
mmorgan++ |
| 10:14 |
mmorgan |
Would an org unit setting that limits how long after checkin an item can be marked missing pieces make sense? |
| 10:15 |
jeff |
Probably! |
| 10:16 |
|
abowling joined #evergreen |
| 10:16 |
jeff |
I probably lack time to take it this far, but I can even see it being helpful to have a confirmation screen that includes the patron you're about to stick with the blame. |
| 10:16 |
* mmorgan |
will file a launchpad bug. |
| 10:18 |
mmorgan |
I agree that a confirmation that it's being rechecked out to a patron would be helpful. |
| 10:23 |
jeff |
Some of the things we're keeping in mind with Missing Pieces include: 1) the patron in most cases thinks that they have returned the item in question, 2) the existing behavior can result in someone ending up with many more or many fewer days before they start getting fines |
| 10:24 |
jeff |
an example of 2, a patron may return an item a week early, have it marked Missing Pieces, and since the item is needed for a hold the current code will make it immediately due, and it will start getting daily fines. |
| 10:24 |
jeff |
That doesn't work well for us. |
| 10:24 |
jeff |
Which is why we're experimenting. :-) |
| 10:25 |
jeff |
And for 1, "the patron thinks that they've returned it", we're probably going to exclude Missing Pieces from any courtesy/overdue notification, since those notices typically also include the "if you've recently returned this items, please disregard this notice" style wording. :-) |
| 10:30 |
mmorgan |
jeff: are you building in an automatic notification? Instead of the missing pieces letter that opens in a text editor? |
| 10:31 |
|
wjr joined #evergreen |
| 10:31 |
|
ericar_ joined #evergreen |
| 10:36 |
|
ericar joined #evergreen |
| 10:43 |
jeff |
mmorgan: We're not using the letter, though I was happy to see how well it worked in the web client. Hrm. Input is labeled incorrectly, though... |
| 10:44 |
jeff |
Hrm. Web client also doesn't bring up the copy editor. |
| 10:45 |
|
dreuther joined #evergreen |
| 10:46 |
bshum |
jeff: Should it? Wouldn't copy editor be part of sprint2 - cataloging? Or you using something fancy on your end of things? |
| 10:47 |
jeff |
bshum: nope, you're right! |
| 10:47 |
jeff |
bshum: it should eventually, but since there's no editor for it to bring up yet... it makes sense that it doesn't. :-) |
| 10:47 |
* jeff |
eyes coffee |
| 10:48 |
jeff |
bshum++ |
| 11:13 |
jeff |
ah, and the label is fixed in commit 21e13fd |
| 11:13 |
pinesol_green |
[evergreen|Mike Rylander] LP#1402797 Fix "scan item for missing pieces" label to say Item instead of Patron - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=21e13fd> |
| 11:26 |
|
vlewis joined #evergreen |
| 11:42 |
pinesol_green |
[evergreen|Ben Shum] Docs: Minor edits to 2.8 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a13a707> |
| 12:03 |
|
bmills joined #evergreen |
| 12:09 |
|
ericar_ joined #evergreen |
| 12:32 |
|
sandbergja joined #evergreen |
| 12:45 |
mmorgan |
Re: the Missing Pieces discussion earlier: lp 1441245 |
| 12:45 |
pinesol_green |
Launchpad bug 1441245 in Evergreen "Mark item as Missing Pieces should not always checkout the item to the last patron" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1441245 |
| 12:51 |
|
dreuther_ joined #evergreen |
| 13:01 |
bshum |
kmlussier++ # ridesharing info |
| 13:02 |
kmlussier |
I'm thinking it might be useful for other conferences, even if it's closer to an airport. Because there are always nearby people who are driving to the conference or even people who might want to share a taxi. |
| 13:13 |
jeff |
mmorgan: I checked, and we handle "found on shelf missing pieces" without making use of Mark Item Missing Pieces. |
| 13:14 |
jeff |
mmorgan: not a perfect analogy, but consider the difference between "Lost (by patron)" as opposed to "Missing" |
| 13:15 |
* kmlussier |
wonders if a 12:30 p.m. Saturday shuttle is cutting it too close to make a 1:52 p.m. flight. |
| 13:15 |
bshum |
that's too close. |
| 13:15 |
jeff |
mmorgan: If it's found to be missing pieces when returned by a patron, we'll use Mark Item Missing Pieces, and attempt to recover the pieces or bill the patron. If it's found on the shelf missing pieces, we mark the material damaged, pull, and consider re-ordering. |
| 13:15 |
bshum |
kmlussier: Well.... maybe |
| 13:16 |
bshum |
I mean, it's an hour to go from Hood River to Portland right? |
| 13:16 |
bshum |
So 12:30 means arriving at 1:30 at best. |
| 13:16 |
kmlussier |
Oh, wait. I'm arriving too late for the Tuesday night shuttle too. I thought I was all set on that. :( |
| 13:16 |
mmorgan |
jeff: gotcha, so if found on shelf, use the "mark damaged" function as opposed to the "missing pieces" function. |
| 13:16 |
bshum |
If you had really fast security check, then maybe? :) |
| 13:17 |
bshum |
But that is really close. |
| 13:17 |
jeff |
mmorgan: That's my understanding, yes. |
| 13:30 |
csharp |
kmlussier: I have a 1:38pm flight on Saturday too, so perhaps we could arrange shared transportation |
| 13:31 |
kmlussier |
csharp: That would be great! There is a 10 a.m. shuttle, but I was hoping to stick around at the conference a little longer than that. |
| 13:32 |
csharp |
so... anyone have any scripts for outputting data for Gale Analytics? |
| 13:32 |
csharp |
looks like one of our libraries has already purchased this and now wants it to "interface with PINES" |
| 13:32 |
bshum |
Typical. |
| 13:32 |
csharp |
yep :-( |
| 13:33 |
collum |
My flight is also at 1:30 on Saturday, maybe the same flight as kmlussier, but you can add my name to the shared transportation. |
| 13:33 |
kmlussier |
Looks like we have a car pool! :) |
| 13:33 |
csharp |
yep |
| 13:34 |
* csharp |
assumes the Gale thing will need something similar to collectionhq |
| 13:34 |
bshum |
Probably. |
| 13:38 |
collum |
Oh. Not the same flight. The 1:30 I saw was bshum's statement. |
| 13:39 |
* collum |
needs to read more closely, instead of scanning. |
| 13:41 |
csharp |
the 10:00 a.m. shuttle might be the best option - allow 1.5 hours to get from Hood River to PDX = 11:30 - 2 hours in advance of my flight time |
| 13:43 |
* kmlussier |
was hoping to catch a bit of gmcharlt's linked data talk. :( |
| 13:44 |
kmlussier |
I missed dbs' talk last year. |
| 13:44 |
gmcharlt |
kmlussier: I'll very likely be participating in the ride-sharing pool, FWIW |
| 13:44 |
gmcharlt |
and since I can't very well miss my own talk... |
| 13:45 |
bshum |
What? No Skype in the car on the way back to the airport? |
| 13:45 |
bshum |
:P |
| 13:45 |
* bshum |
has done Google Hangout with the Docs on his way to the Hackfest before. So, don't listen to him. |
| 13:45 |
gmcharlt |
bshum: I like living more than I like giving Linked Data talks ;) |
| 13:46 |
bshum |
I think they enjoyed watching my phone's video feed of the road as I was driving? :) |
| 13:46 |
bshum |
gmcharlt: But yes, living is good.... |
| 13:46 |
collum |
living++ |
| 13:52 |
* kmlussier |
remembers bshum doing that Google Hangout with DIG |
| 13:53 |
kmlussier |
bmills++ #Offering 4 seats on ride share |
| 13:55 |
kmlussier |
bmills: If we left Hood River at 11 a.m. on a Saturday morning, should we expect traffic? I'm thinking getting to the airport at 12 p.m. would be plenty of time to make a 1:52 p.m. flight. |
| 13:55 |
* kmlussier |
likes living dangerously for the sake of seeing linked data talks. |
| 13:55 |
csharp |
kmlussier: I would imagine 11a would be fine for my flight too |
| 13:56 |
* kmlussier |
agrees |
| 13:58 |
bmills |
i'd allow at least an hour and a half to get there. the turn off for the airpot can get real congested with people coming/going to Seattle |
| 13:59 |
bmills |
leaving at noon should allow you to get to the airport with a little breathing room |
| 14:00 |
bmills |
or sorry, 11am |
| 14:00 |
kmlussier |
Yeah, noon would be a little tight. :) |
| 14:04 |
csharp |
bmills++ # awesome |
| 14:05 |
Bmagic |
What are folks doing with metarecord holds on metarecords that don't exist anymore? |
| 14:05 |
csharp |
Bmagic: eww - in our case they're probably just sitting there abandoned and unloved |
| 14:06 |
bshum |
Wouldn't those die with untargeted expiration eventually? |
| 14:06 |
Bmagic |
csharp: in our case, it throws a nasty error on the staff client when that hold is getting fleshed |
| 14:06 |
bshum |
I guess it depends on how your holds setup is configured. |
| 14:06 |
Bmagic |
This is simliar to the part level holds on parts that have since been deleted |
| 14:06 |
bshum |
Oh awesome Bmagic.... yeah |
| 14:07 |
Bmagic |
which is a bug |
| 14:07 |
kmlussier |
Ugh. bug 937789 |
| 14:07 |
pinesol_green |
Launchpad bug 937789 in Evergreen 2.4 "Deleting parts breaks hold interfaces" (affected: 11, heat: 68) [Medium,Confirmed] https://launchpad.net/bugs/937789 |
| 14:07 |
bshum |
Yeah |
| 14:07 |
* bshum |
hates on bug 937789 |
| 14:07 |
Bmagic |
937789-- |
| 14:08 |
Bmagic |
ok, just thought I would check. It sounds like everyone is having the same problem |
| 14:08 |
bshum |
With parts, sure. |
| 14:08 |
bshum |
But metarecords, unfortunately we've not tested that extensively. |
| 14:08 |
bshum |
For our consortium, that is still disabled. |
| 14:08 |
Bmagic |
metarecord holds = part level holds in this context |
| 14:08 |
bshum |
Until we get more time to sort out the fingerprints |
| 14:10 |
Bmagic |
We handle the part level holds with a cron job that deletes them and reports the deletes in an email to the consortium email list |
| 14:10 |
Bmagic |
perhaps the metarecord holds need to be included in this cron |
| 14:13 |
dbs |
kmlussier: my linked (structured, really) data talk missed you! |
| 14:34 |
|
Newziky1 joined #evergreen |
| 14:36 |
|
mglass_ joined #evergreen |
| 14:54 |
csharp |
@quote random |
| 14:54 |
pinesol_green |
csharp: Quote #83: "< jboyer-isl> PEBCAKEs, while delicious, rarely yield fruitful discussions." (added by csharp at 03:54 PM, April 16, 2014) |
| 15:14 |
jeff |
interesting: various docs filenames have uppercase filename extensions in an evergreen release tar file, lowercase in git. |
| 15:44 |
jeff |
i wonder why that is. |
| 15:45 |
kmlussier |
jeff: Are they images? |
| 15:47 |
jeff |
yes. jpg vs JPG |
| 15:47 |
kmlussier |
I remember there were a few git commits a while back changing some image files with uppercase extensions to lowercase. They're probably the same files. |
| 15:48 |
bshum |
Like 703a9b04311895af251c31170629e4fc4cebfc0a |
| 15:48 |
pinesol_green |
[evergreen|Remington Steed] Docs: Fix filenames to match references in the docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=703a9b0> |
| 15:48 |
jeff |
yup, first one is affected by commit 83c1981 |
| 15:48 |
pinesol_green |
[evergreen|Josh Stompro] Docs: Fix filenames to match references in the docs - second time - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=83c1981> |
| 15:50 |
jeff |
but that commit it contained within master, rel_2_7, and tags/rel_2_7_4 |
| 15:50 |
jeff |
s/it contained/is contained/ |
| 15:50 |
bshum |
Yep |
| 15:50 |
bshum |
It looks like that second commit |
| 15:50 |
bshum |
Created new files |
| 15:50 |
bshum |
That were lowercase .jpg |
| 15:51 |
bshum |
But didn't remove the older .JPG uppercaes |
| 15:51 |
bshum |
*uppercase |
| 15:52 |
bshum |
So they're duplicates I guess |
| 15:53 |
Dyrcona |
Looks like it in the git history and in a clean repo. |
| 15:54 |
bshum |
There's still references to uppercase .JPG in the docs themselves too. |
| 15:54 |
bshum |
So we could probably clean up all of this stuff. |
| 15:54 |
Dyrcona |
Sounds like a job for DIG! ;) |
| 15:55 |
jeff |
oh neat. the issue for me is that my local filesystem is Mac OS Extended (journaled) |
| 15:55 |
jeff |
which isn't case sensitive. |
| 15:56 |
Dyrcona |
jeff: It can be if you reformat and check a box, but then several Mac OS X applications stop working correctly. :) |
| 15:56 |
* bshum |
is putting together a patch to fix what he sees. |
| 15:57 |
Dyrcona |
HFS+ is case preserving, but not case sensitive by default. |
| 15:57 |
jeff |
so my git working copy has docs/media/Added_User_to_Routing_Slip.jpg, while my extracted copy from Evergreen-ILS-2.7.4.tar.gz contains docs/media/Added_User_to_Routing_Slip.JPG |
| 15:57 |
Dyrcona |
And, you should have both in both, actually. |
| 15:57 |
Dyrcona |
I have both in my git repo. |
| 15:58 |
jeffdavis |
Filename case sensitivity issues in 2015. *shakes head sadly* |
| 15:59 |
jeff |
right, but what happens in the git working directory is the first file (commit ordering) docs/media/Added_User_to_Routing_Slip.JPG is overwritten by the later docs/media/Added_User_to_Routing_Slip.jpg |
| 15:59 |
jeff |
and in the tar archive, the first (in order of tar archive contents) file Evergreen-ILS-2.7.4/docs/media/Added_User_to_Routing_Slip.jpg is overwritten by the later Evergreen-ILS-2.7.4/docs/media/Added_User_to_Routing_Slip.JPG |
| 15:59 |
Dyrcona |
jeff: Just use a real filesystem. |
| 15:59 |
Dyrcona |
;) |
| 16:00 |
Dyrcona |
@blame 11 HFS+ |
| 16:00 |
pinesol_green |
Dyrcona: HFS+ musta been an Apple employee. |
| 16:00 |
jeff |
Now that I've figured this out, I'm pretty sure I've stumbled on this before. Strong deja vu. :P |
| 16:01 |
dbs |
I know dfiander stumbled on this back in the days of OpenSRF.js vs. opensrf.js |
| 16:01 |
jeff |
Ugh. |
| 16:01 |
jeff |
Yeah, doing something like "git rm docs/media/Added_User_to_Routing_Slip.JPG" touches on the tip of a dangerous iceburg. |
| 16:02 |
jeff |
(in a working copy that's on a case-insensitive fs) |
| 16:02 |
Dyrcona |
jeff: Switch to zfs and problem solved. :) |
| 16:02 |
jeff |
anyway, I stubled across this TIME time because I was diffing a working copy against an extracted tarball. |
| 16:02 |
jeff |
stumbled. |
| 16:03 |
Dyrcona |
Stubble in the file system, eh? :) |
| 16:07 |
jeff |
hah, yup. thought i remembered the djfiander convo from 2008. |
| 16:07 |
jeff |
from that same log: |
| 16:07 |
jeff |
<jeff> error.locale = (en_SMS) |
| 16:07 |
jeff |
<jeff> UR QRY RT 0 RSLTS. PLZ TRY AGN |
| 16:07 |
jeff |
<jeff> GTG CUL8R |
| 16:15 |
bshum |
Alrighty then. |
| 16:15 |
pinesol_green |
[evergreen|Ben Shum] Docs: Change all .JPG to .jpg - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1edb4eb> |
| 16:15 |
pinesol_green |
[evergreen|Ben Shum] Docs: Delete remnant .JPG files that had already been converted to .jpg - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cfa3d11> |
| 16:17 |
bshum |
I backported those to rel_2_8, rel_2_7, and rel_2_6. With minor conflict changes since docs were different from 2.7 and backwards |
| 16:18 |
jeff |
amusingly, i was right in guessing that after a fetch and merge, my local working copy is now missing several files from docs/media :-) |
| 16:19 |
jeff |
(because in the process of merging, git deleted the .JPG files) |
| 16:19 |
bshum |
Special. |
| 16:19 |
jeff |
easily fixed by confirming that i have no local changes to the docs dir that i care about, then running "git checkout docs" |
| 16:22 |
bshum |
Bleh :( |
| 16:25 |
bshum |
You know, I wonder if maybe because yboston has a Mac, that's why that second commit didn't actually fix any of the extension names. |
| 16:25 |
bshum |
Since he would have been the one to push Stompro's patch |
| 16:26 |
yboston |
hola |
| 16:26 |
yboston |
I have only been lurking |
| 16:26 |
yboston |
but I remember having to cahnge a git valeu to reconize the file name changes when I pushed some Josh commits at home on my mac laptop |
| 16:27 |
yboston |
(sorry for spelling, typing too fast) |
| 16:27 |
yboston |
not sure if I later on pushed soemthing on my work iMac where I did not have that same git config value updated |
| 16:28 |
Dyrcona |
Seriously, just use a real filesystem, like zfs. |
| 16:28 |
bshum |
It's alright yboston. Jeff's little (re)discovery about Mac's filesystem does make me wonder what other quirks could occur like that. |
| 16:35 |
yboston |
bshum: cool, just wanted to confirm that I did have issues with the Mac in pushing that renaming commit |
| 16:38 |
|
maryj joined #evergreen |
| 17:05 |
|
mglass joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:08 |
bshum |
Hmm |
| 17:08 |
bshum |
Think something like <copy_location>[% escape_xml(circ.target_copy.location.name) %]</copy_location> might work to define that in an overdue template? |
| 17:08 |
* bshum |
has to dig deeper to try remembering how these silly XML thingies work |
| 17:09 |
berick |
bshum: it might be helpers.escape_xml(...) |
| 17:09 |
berick |
but, yes, that's basically what you want |
| 17:10 |
bshum |
I'm just not sure if there's any special pathing considerations that I need to be thinking of. |
| 17:10 |
bshum |
I know in A/T, those are all handled in the environment params or something |
| 17:10 |
bshum |
But I don't know how generate_circ_notices.pl works . |
| 17:11 |
berick |
you're using generate_circ_notices.pl? |
| 17:11 |
bshum |
I suppose it probably wouldn't even know about it unless it was defined. |
| 17:11 |
bshum |
Yes, these are our legacy (read, terribly implemented) print notices. |
| 17:12 |
bshum |
We haven't adjusted the process for generating the content yet to make use of A/T since that process hasn't been well fleshed out anywhere yet. Though I keep thinking about it... on and off. |
| 17:12 |
bshum |
Like I know it's possible, I just don't feel like touching things if it "works" for now. |
| 17:13 |
berick |
i feel ya |
| 17:13 |
berick |
so, escape_xml is what you want (no helpers...) |
| 17:13 |
berick |
but looks like it's not fleshing the copy location by defualt |
| 17:13 |
berick |
for that, you'd have to modify the script |
| 17:14 |
bshum |
right on. So around line 425 or so, I see some things getting put together |
| 17:14 |
bshum |
I assume that might be where I might need to define how location gets connected with the circulations. |
| 17:15 |
pastebot |
"berick" at 64.57.241.14 pasted "copy loc" (14 lines) at http://paste.evergreen-ils.org/48 |
| 17:15 |
berick |
yep |
| 17:15 |
bshum |
berick++ # thanks muchly |
| 17:15 |
bshum |
We shall test and hopefully not crash everything :) |
| 17:16 |
berick |
heh, so by "test" you mean "deploy" :) |
| 17:16 |
berick |
AKA the developer's "test" |
| 17:16 |
bshum |
Uh... yes. :) |
| 17:18 |
bshum |
If it breaks, we can always just manually re-run generating the XML |
| 17:19 |
bshum |
In theory. |
| 17:19 |
bshum |
:) |
| 17:24 |
csharp |
@who tests all their fixes in production? |
| 17:24 |
pinesol_green |
tsbere tests all their fixes in production. |
| 17:24 |
bshum |
Lucky shot. |
| 17:24 |
berick |
heh |
| 17:25 |
csharp |
@roulette |
| 17:25 |
pinesol_green |
csharp: *click* |
| 17:25 |
berick |
@who tests [someone]'s fixes in production |
| 17:25 |
pinesol_green |
collinanderson tests collinanderson 's fixes in production. |
| 17:25 |
csharp |
@developer |
| 17:25 |
pinesol_green |
csharp: Communication:16, BigPicture:12, DetailOriented:14, KungFu:12, GetsStuffDone:8, FlakeFactor:9, JavaAvoidance:11 |
| 17:25 |
bshum |
Now that's just spooky berick... |
| 17:26 |
csharp |
@bartender [someone] |
| 17:26 |
berick |
glad I'm not playing... |
| 17:26 |
* pinesol_green |
fills a pint glass with Samuel Smith's Winter Welcome Ale, and sends it sliding down the bar to jonadab (http://beeradvocate.com/beer/profile/113/577/) |
| 17:26 |
berick |
@roulette |
| 17:26 |
pinesol_green |
berick: *click* |
| 17:26 |
pinesol_green |
[evergreen|Ben Shum] Docs: Change all .PNG to .png - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8598e7a> |
| 17:26 |
csharp |
@praise [someone] |
| 17:26 |
* pinesol_green |
hopkinsju is one of the few who deserves to be praised |
| 17:30 |
bshum |
Well actually I can test right now if the template worked. |
| 17:31 |
* bshum |
tests generating some circ overdue files. |
| 17:31 |
csharp |
@test |
| 17:31 |
pinesol_green |
csharp: You probably want hard-boiled eggs. |
| 17:31 |
bshum |
~test |
| 17:31 |
bshum |
Nope. |
| 17:31 |
csharp |
s'ok |
| 17:34 |
bshum |
@roulette |
| 17:34 |
pinesol_green |
bshum: *click* |
| 17:35 |
bshum |
At some point down the road, I know we have to re-evaluate how we do print notice generation. |
| 17:35 |
bshum |
With 12.04 at least, the thing that converts it to PDF complains all the time about template syntax errors. |
| 17:35 |
bshum |
I haven't dared try building everything out on a 14.04 yet... |
| 17:36 |
|
abowling left #evergreen |
| 17:36 |
csharp |
bshum: I'm working on 14.04 issues right now - trying to get the remaining issues ironed out |
| 17:37 |
csharp |
building opensrf and evergreen debs is actually a pretty good way to flush out issues |
| 17:37 |
bshum |
Well, in general, most everything seemed to work fine when I installed it. |
| 17:38 |
bshum |
I'm just worried about these little dangling bits. |
| 17:38 |
csharp |
you may have seen I'm trying to hack around the busted ruby deps |
| 17:38 |
* bshum |
still has to finish adapting all the apache config over for 2.4 |
| 17:38 |
bshum |
Yeah, we're planning to give that a poke in the coming weeks. |
| 17:38 |
bshum |
I have that bug bookmarked for review. |
| 17:38 |
csharp |
yeah, just saw that our deb-building scripts don't account for apache 2.4 either :-/ |
| 17:39 |
bshum |
Not this week though... one upgrade at a time. |
| 17:39 |
csharp |
yep |
| 17:39 |
bshum |
We're going up to 2.8.0 on Saturday. |
| 17:39 |
csharp |
it's high on my list because I want to move to 14.04 for my next upgrade |
| 17:39 |
csharp |
ooh - good luck |
| 17:39 |
bshum |
But our move to 14.04 will probably occur during Memorial Day weekend. |
| 17:39 |
bshum |
Next month. |
| 17:39 |
csharp |
I'm sure it will be fine |
| 17:39 |
bshum |
If we can iron out all the remaining kinks. |
| 17:40 |
bshum |
At the very least, I expect to be able to deploy app servers at 14.04. Just have to keep testing out all the utility stuff. |
| 17:40 |
csharp |
yeah |
| 17:44 |
bshum |
Yay, berick++ # it worked in my testing :) |
| 17:45 |
bshum |
Now to add it onto the giant .xml that controls everything... |
| 17:50 |
|
dcook__ joined #evergreen |
| 17:51 |
berick |
bshum: cool! |
| 18:52 |
|
dmoses joined #evergreen |
| 19:36 |
|
sarabee joined #evergreen |
| 20:27 |
|
bbqben joined #evergreen |
| 22:00 |
|
akilsdonk joined #evergreen |
| 22:03 |
|
mceraso joined #evergreen |
