| Time |
Nick |
Message |
| 00:58 |
phasefx |
@later tell Dyrcona the live tests happen on a near pristine snapshot of wheezy and runs all the tests |
| 00:58 |
pinesol_green |
phasefx: The operation succeeded. |
| 02:53 |
|
sarabee joined #evergreen |
| 03:27 |
|
gsams joined #evergreen |
| 06:30 |
|
b_bonner_ joined #evergreen |
| 06:32 |
|
gdunbar joined #evergreen |
| 06:41 |
* kmlussier |
yawns |
| 06:49 |
|
b_bonner joined #evergreen |
| 06:49 |
|
remingtron joined #evergreen |
| 06:49 |
|
jcamins joined #evergreen |
| 06:49 |
|
BigRig joined #evergreen |
| 06:49 |
|
rashma joined #evergreen |
| 06:49 |
|
csharp joined #evergreen |
| 07:20 |
kmlussier |
heh...half the 2.8 documentation I was signed up for has already been done by other people. :) |
| 07:21 |
kmlussier |
other_people++ |
| 07:39 |
|
mrpeters joined #evergreen |
| 07:45 |
|
ericar joined #evergreen |
| 07:57 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
rlefaive joined #evergreen |
| 08:29 |
|
Shae joined #evergreen |
| 08:31 |
|
rlefaive joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 08:37 |
|
Dyrcona joined #evergreen |
| 08:45 |
|
maryj joined #evergreen |
| 08:51 |
kmlussier |
This is why documentation always takes me so long. I start with the intent of making two simple tweaks to one file and then end up spending my morning reducing line lengths, updating stale information, replacing screenshots, etc. |
| 08:53 |
mmorgan |
kmlussier: Like shelving books in the Children's Room ;-) |
| 08:53 |
kmlussier |
mmorgan: Yes, exactly! |
| 08:58 |
|
rlefaive joined #evergreen |
| 08:58 |
kmlussier |
@coffee [someone] |
| 08:58 |
* pinesol_green |
brews and pours a cup of Guatemala El Injerto, and sends it sliding down the bar to bshum |
| 08:58 |
kmlussier |
pinesol_green: bshum doesn't drink coffee. Give it to me! |
| 08:58 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 08:58 |
pinesol_green |
kmlussier: http://images.cryhavok.org/d/1291-1/Computer+Rage.gif |
| 08:59 |
mmorgan |
@coffee kmlussier |
| 08:59 |
* pinesol_green |
brews and pours a cup of Kenya Ndaroini Microlot, and sends it sliding down the bar to kmlussier |
| 08:59 |
kmlussier |
mmorgan: Thank you! |
| 09:00 |
mmorgan |
@weather 01923 |
| 09:00 |
pinesol_green |
mmorgan: The current temperature in Danvers, Danvers, Massachusetts is 74.3°F (8:59 AM EDT on August 07, 2015). Conditions: Partly Cloudy. Humidity: 61%. Dew Point: 60.8°F. Pressure: 29.94 in 1014 hPa (Falling). |
| 09:00 |
mmorgan |
I don't see any clouds. It's too nice to be inside. :-( |
| 09:04 |
kmlussier |
It is, but I get to spend all of next week outside, so I'm happy to suffer through today. :) |
| 09:05 |
kmlussier |
It better not rain next week. |
| 09:05 |
mmorgan |
vacation++ |
| 09:05 |
kmlussier |
And I see rain in the forecast for Tuesday and Wednesday. Figures. |
| 09:13 |
Stompro |
mmorgan, have you started on the release notes for bug 1124498, I also started on that but forgot to assign it. |
| 09:14 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 6, heat: 40) [Wishlist,Confirmed] https://launchpad.net/bugs/1124498 - Assigned to Michele Morgan (mmorgan) |
| 09:15 |
mmorgan |
Stompro: I was actually working on final testing to sign off. You are welcome to the release notes :) |
| 09:18 |
Stompro |
mmorgan, Wonderful, I hope your testing goes well. |
| 09:18 |
kmlussier |
mmorgan++ Stompro++ |
| 09:19 |
kmlussier |
Stompro: I think MVLC might do some of the things you described in your email with staff clients for test servers. tsbere might be able to answer your questions. I don't think he's around this week. |
| 09:21 |
* mmorgan |
is also interested in that info. I often find a need to run 2 clients simultaneously on the same workstation. |
| 09:21 |
kmlussier |
I use MVLC's servers quite a bit for testing. Icons for the clients that access the test servers are a different color and they don't share settings with the other clients on my local machine. |
| 09:21 |
* kmlussier |
has many, many clients on her local machine. |
| 09:22 |
Stompro |
kmlussier, great, any guidance would be appreciated. I'll send him an email if I don't hear from him. |
| 09:22 |
kmlussier |
mmorgan: Yes, that's what I like about testing on MVLC's servers. I can have two or more clients at the same time. tsbere also configured the clients for the MassLNC VMs to work the same way. |
| 09:23 |
kmlussier |
tsbere++ #for general wizardry |
| 09:24 |
mmorgan |
Yes, I noticed that. I can run a MassLNC client concurrently with a NOBLE client, but not a NOBLE Production along with a NOBLE training client. |
| 09:25 |
mmorgan |
Stompro: We will just change the hostname when the different servers are running the same version of Evergreen, but often our servers are on different versions. |
| 09:27 |
Stompro |
mmorgan, I think you can run multiple instances at the same time by enabling multi profile mode and multi-instance mode - http://wiki.evergreen-ils.org/doku.php?id=mozilla-devel:building_the_staff_client#multiple_workstations_on_one_install |
| 09:28 |
Stompro |
Add -P and -no-remote to your client shortcut. |
| 09:30 |
mmorgan |
Stompro: we use -profilemanager all the time. I'll have a look at -no-remote, though. |
| 09:34 |
Stompro |
I just wanted to make it super easy for staff to connect to the training/testing server, without needing to change the hostname, to take out a step where mistakes can be made. I'm just worried about staff accidently thinking they are are production when they are on testing and vice versa. Maybe adding a prefix to all usernames on the test system would help. |
| 09:35 |
mmorgan |
Stompro++ You made my day! |
| 09:42 |
Stompro |
Did the -no-remote work? |
| 09:44 |
mmorgan |
Yes! I now have 2 clients open at the same time :) Not sure how I missed that detail, but am happy to know it now! |
| 09:44 |
kmlussier |
Stompro: I don't know if it helps to see one of those clients in action, but the one we make available on the community demo page does just that. http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers |
| 09:50 |
Stompro |
kmlussier++, that does help, that is exactly what I want to happen. It has it's own install directory, and it's own profile directory under %appdata%/openils/. I'll definately check back in with tsbere when he gets back. |
| 10:12 |
Dyrcona |
So, "Show Last Few Circulations" is actually sel_patron.... Yeah, that makes sense. |
| 10:12 |
* Dyrcona |
is feeling bitchy today, so don't pay any attention to him. |
| 10:14 |
kmlussier |
@bartender Dyrcona |
| 10:14 |
* pinesol_green |
fills a pint glass with Anchor Summer Beer, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/28/2550/) |
| 10:16 |
Bmagic |
Has anyone out there moved a branch from one system to another after years of history? |
| 10:19 |
Bmagic |
Is it better to create a new branch under the new system and move all of the call numbers? |
| 10:23 |
Dyrcona |
kmlussier: Thanks. |
| 10:24 |
Dyrcona |
The pizza joint across the street sells beer. I may just have my lunch on their premises today. |
| 10:25 |
Dyrcona |
Bmagic: So, your call numbers are owned at the system level? |
| 10:26 |
Dyrcona |
Bmagic: Just changing the parent ou in the org tree and then running autogeh.sh -u should work. If call numbers are owned at the system level, you'll want to do something about moving copy call numbers and creating new ones when necessary. |
| 10:40 |
|
maryj joined #evergreen |
| 10:41 |
Bmagic |
Call numbers are owned by the branch |
| 10:41 |
Bmagic |
Ok, that is whay I thought, just changing the parent OU should do it with autogen. Sounds easy enough |
| 10:42 |
Bmagic |
/whay/what |
| 10:42 |
Dyrcona |
You might have some memcached issues, so I'd wait and do it in the middle of the night when you can restart memcached without wrecking too much. |
| 10:45 |
Dyrcona |
I'd also suggest trying it on a test/training system first, just to make sure. |
| 10:50 |
* kmlussier |
is spending more time re-learning AsciiDoc conversion than writing documentation. |
| 10:50 |
csharp |
Bmagic: yes, we've moved a branch from one parent to another - it's not a big deal - just move it and run autogen (though you might schedule it after business hours) |
| 10:51 |
csharp |
all holdings and patrons, etc. remain intact |
| 10:51 |
Bmagic |
csharp++ Dyrcona++ |
| 10:53 |
Bmagic |
Another unrelated question. I am wrestling with search indexes. We have the stock indexes which I am having trouble wrapping my head around. It looks like the four author entries in config.metabib_field would include authors found in the 700a |
| 10:54 |
Bmagic |
based on this line "author";"other";"Other Author";"//mods32:mods/mods32:name[@type='personal' and not(mods32:role/mods32:roleTerm[text()='creator'])]" |
| 10:54 |
|
RoganH joined #evergreen |
| 10:54 |
Bmagic |
I think that would match this xsl: <xsl:for-each select="marc:datafield[@tag='700'][not(marc:subfield[@code='t'])]"> |
| 10:55 |
Bmagic |
<name type="personal"> |
| 11:00 |
Bmagic |
So I just learned something - It appears that if the 700 contains a subfield "t" then NONE of the other subfields are indexed! |
| 11:02 |
Dyrcona |
Based on that predicate, I would agree with you. |
| 11:03 |
Dyrcona |
But, I could be wrong, too. ;) |
| 11:03 |
Bmagic |
Is there a practical reason that we don't author index any other subfields in the 700 when there is a "t" present ? |
| 11:03 |
kmlussier |
Bmagic: Ah, is that what's happening? |
| 11:03 |
Dyrcona |
My guess is that might be a mistake. |
| 11:04 |
kmlussier |
Yes, I don't think that was the intent at all. |
| 11:04 |
Dyrcona |
But, I'd need to play with with some samples and don't have time at the moment. |
| 11:04 |
Bmagic |
kmlussier: yep! That's what it looks like. I created a new 700 field on a test record and only created a subfield "a" and violla it was indexted |
| 11:05 |
Bmagic |
I am assuming that the contents of config.xml_transform are lifted from some global standard? |
| 11:11 |
Dyrcona |
Bmagic: http://www.loc.gov/standards/mods/ |
| 11:11 |
Bmagic |
Dyrcona: right, and the xsl structure was downloaded somewhere or did the EG community create it from their guideline? |
| 11:14 |
Dyrcona |
Bmagic: Think it was downloaded, but modified. LoC has xsl for marc2mods and a couple of other formats. |
| 11:15 |
Bmagic |
I found xsd but not xsl, I know very little about the language, so for all I know it was a search and replace http://www.loc.gov/standards/mods/v3/mods-3-2.xsd |
| 11:16 |
Dyrcona |
Bmagic: http://www.loc.gov/standards/mods/mods-conversions.html |
| 11:16 |
Bmagic |
oh! There we go |
| 11:17 |
Bmagic |
It seems to me that a change in xml_transform is required as opposed to a change in metabib_field |
| 11:17 |
Dyrcona |
I tinkered with newer mods versions in my dev system a year or more ago. |
| 11:17 |
Dyrcona |
That what it looks like. |
| 11:18 |
Bmagic |
I think I would like to do it for our system, can anyone suggest a change to <xsl:for-each select="marc:datafield[@tag='700'][not(marc:subfield[@code='t'])]"> |
| 11:19 |
Dyrcona |
I'd need more context and have other things to do at the moment. |
| 11:19 |
Bmagic |
that would result in including all subfields except "t" ? |
| 11:19 |
Bmagic |
Dyrcona: no problem, I really appreciate your time! |
| 11:20 |
Dyrcona |
possibly: marc:datafield[@tag='700']/marc:subfield[not @code='t'] |
| 11:20 |
Dyrcona |
off the top of my head and not sure the syntax is even correct. |
| 11:20 |
pinesol_green |
[evergreen|Kathy Lussier] Documentation: Add 2.8 docs for void on claims returned - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6177e5d> |
| 11:21 |
|
RoganH joined #evergreen |
| 11:24 |
Bmagic |
Dyrcona++ |
| 11:25 |
Dyrcona |
That worked? |
| 11:25 |
Bmagic |
no, Just karma for helping when you are so busy. I will try that on a dev server |
| 11:25 |
Bmagic |
it will take me a few minutes to get all the ducks aligned |
| 11:25 |
Dyrcona |
ok. I would be surprised if that actually worked. |
| 11:26 |
Dyrcona |
I don't remember if the not works in that location, and I'm not sure the xsl takes actual xpath at that point, but I think it does. |
| 11:37 |
|
jihpringle joined #evergreen |
| 11:39 |
Bmagic |
Dyrcona: your suggested lead me to the answer. This looks like it's working <xsl:for-each select="marc:datafield[@tag='700'][not(marc:subfield[@code='t'])]"> |
| 11:40 |
Bmagic |
oops that is the original |
| 11:40 |
Bmagic |
here is the fix |
| 11:40 |
Bmagic |
<xsl:for-each select="marc:datafield[@tag='700'][marc:subfield[not (@code='t')]]"> |
| 11:40 |
Dyrcona |
I was about to say.... |
| 11:40 |
Dyrcona |
:) |
| 11:40 |
Bmagic |
needs brackets and parens |
| 11:41 |
Dyrcona |
maybe that's xpath 2? maybe not? |
| 11:41 |
Dyrcona |
glad you found something that works. |
| 11:41 |
Bmagic |
so, is this a loc issue? |
| 11:42 |
Dyrcona |
Well, you'd have to look at the original xsl from LoC, 'cause I know one or two have been modified by Evergreen, but I'm not certain how. |
| 11:42 |
miker |
Bmagic: it's following AACR2 rules ... author /with/ title isn't an added author, it's something like "related title" |
| 11:42 |
Dyrcona |
Also, if was a LoC issue they may have fixed it by now. |
| 11:42 |
miker |
we did not modify that rule in the xslt |
| 11:42 |
Dyrcona |
Also, what miker said. |
| 11:42 |
Bmagic |
miker: ok, so really, it is by design |
| 11:43 |
miker |
Bmagic: yes, it's how 700 with 't' is supposed to be interpreted |
| 11:43 |
Bmagic |
miker: I should tell my libraries to exclude the t if they want the alternat authors to be indexed? |
| 11:44 |
miker |
for instance, looking at the movie for harry potter and the soceror's stone, you shouldn't have rowling as an "added author" but the book is a related title |
| 11:44 |
Bmagic |
miker: that makes sense |
| 11:44 |
miker |
it's available in other parts of the mods |
| 11:44 |
miker |
under, IIRC, relatedItem |
| 11:45 |
* miker |
disappears into the aether **poof** |
| 11:48 |
Bmagic |
miker: that was the other question that I was asked, can we get the 700t's indexed for title? |
| 11:52 |
miker |
http://www.loc.gov/standards/mods/v3/mods-mapping.html#relateditem |
| 11:56 |
|
Christineb joined #evergreen |
| 11:57 |
* Bmagic |
waves at Christineb |
| 11:59 |
mmorgan |
Is there currently a way to set up a circulation duration rule to make an item due "tomorrow at noon"? |
| 12:00 |
* Christineb |
waves Hello :) |
| 12:01 |
Bmagic |
miker++ |
| 12:01 |
Bmagic |
mmorgan: not that I know of |
| 12:05 |
|
bmills joined #evergreen |
| 12:08 |
* mmorgan |
was hoping someone found a creative way of doing something like that. |
| 12:08 |
mmorgan |
It's cumbersome for staff to need to set the date and time at checkout. |
| 12:08 |
kmlussier |
That's interesting. What's the use case? |
| 12:09 |
mmorgan |
A museum pass that actually has to be returned. |
| 12:09 |
kmlussier |
mmorgan: ah, yes, of course! |
| 12:09 |
* kmlussier |
wishes every museum did the throwaway passes. |
| 12:10 |
bshum |
I can't remember if hard due dates allow for time as well. |
| 12:10 |
kmlussier |
bshum: That's a thought! |
| 12:10 |
bshum |
Though that'd be a terrible thing to setup... one hard due date per day, that rolls |
| 12:10 |
mmorgan |
Yeah. Makes it much easier for those of us that need to set up circ rules ;-) |
| 12:10 |
bshum |
But it could be automated to constantly switch to a newer hard due dat every day. |
| 12:10 |
* mmorgan |
was just looking at hard due dates and thinking the same thing as bshum suggests |
| 12:11 |
mmorgan |
Can't enter the hard date values with a time in the client, but maybe directly in the database... |
| 12:12 |
bshum |
Yep, the ceiling dates in the DB are timestamp |
| 12:12 |
bshum |
So they could have hours in there too |
| 12:12 |
bshum |
In theory |
| 12:12 |
* bshum |
wanders away to go get on his plane. |
| 12:13 |
* mmorgan |
and bshum are on the same wavelength :) |
| 12:13 |
kmlussier |
bshum: Have a nice trip! |
| 12:13 |
mmorgan |
Safe travels! |
| 12:13 |
kmlussier |
Since we've has so many discussions lately around deleted items that aren't really deleted, I'll throw another question out there. |
| 12:13 |
kmlussier |
The messages in the new message center don't really delete. They have a deleted column in the database. |
| 12:14 |
kmlussier |
Is there any reason it would be a problem to purge those messages on a regular basis once they reach a certain age? |
| 12:15 |
kmlussier |
I heard a concern from somebody that they might begin to pile up on a patron's records depending on the number of action trigger messages we choose to create. |
| 12:18 |
bshum |
kmlussier: Don't messages contain circ related data sometimes? |
| 12:19 |
bshum |
If so, I think deleting those at some point seems like a good plan. |
| 12:19 |
kmlussier |
bshum: Yes, if they're generated by an overdue action/trigger or something like that. |
| 12:19 |
* bshum |
hates flight delays... |
| 12:20 |
kmlussier |
I imagine people do similar purges with the output from action trigger notices? |
| 12:21 |
mmorgan |
We haven't done that type of purge yet, but it seems like we'll need to at some point, otherwise the tables just keep growing. |
| 12:21 |
* kmlussier |
just remembered she's supposed to be doing some hack-a-way planning before going on vacation. |
| 12:22 |
kmlussier |
mmorgan: Do you anonymize your circ transactions? |
| 12:24 |
mmorgan |
Not currently. |
| 12:28 |
bshum |
Sigh, 30 minutes delay so far. I hate it when this happens. |
| 12:29 |
bshum |
mmorgan: I think once a hard due date entry is no longer referenced, it can be deleted from the table. |
| 12:29 |
bshum |
Just in case you don't want 365 entries every year (roughly) |
| 12:29 |
|
RoganH joined #evergreen |
| 12:29 |
mmorgan |
bshum: Yes, I have done that. The old hard due dates can pile up even if there isn't one for every day :) |
| 12:31 |
bshum |
Hehe, true. |
| 12:36 |
mmorgan |
Hmm. Set up a hard due date with a ceiling date of 2015-08-08 12:00:00-04 and my due date is 2015-08-08 23:59:59-04 |
| 12:36 |
mmorgan |
I can't even edit the due date to noon :-( |
| 12:38 |
bshum |
Maybe it's some trigger that pushes the dates to end/start |
| 12:38 |
mmorgan |
Oh wait! |
| 12:39 |
mmorgan |
I had a rule set in the circ policy table that wasn't hourly. I just switched that to an hourly rule, and now the due date is 8/8 at noon! |
| 12:40 |
mmorgan |
So an hourly duration rule AND a hard due date that specifies a due time of noon works. |
| 12:41 |
mmorgan |
Now to figure out how to update the hard due date every day... |
| 12:41 |
mmorgan |
Anyway - progress :) |
| 12:41 |
mmorgan |
bshum++ |
| 12:42 |
bshum |
mmorgan++ # let us know how it all works out |
| 12:49 |
bshum |
Boarding time, whee! |
| 12:58 |
|
akilsdonk joined #evergreen |
| 13:07 |
|
buzzy joined #evergreen |
| 13:14 |
Dyrcona |
So, what state should a purchase order be in if the EDI order was sent? on order? |
| 13:15 |
kmlussier |
Dyrcona: Yes. As soon as you activate the PO, it sets it to on order and is then sent in the EDI order message. |
| 13:16 |
kmlussier |
Or, I should say, it is sent when the EDI pusher next runs. But you already knew that part. |
| 13:16 |
Dyrcona |
And, does anything happen to EDI info if a purchase order is subsequently canceled? |
| 13:17 |
Dyrcona |
Apparently, not. |
| 13:21 |
kmlussier |
Dyrcona: No. |
| 13:22 |
kmlussier |
Bmagic: I added a comment to https://bugs.launchpad.net/evergreen/+bug/1331174/comments/15 |
| 13:22 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 13:23 |
kmlussier |
Bmagic: I don't know what kind of time you have today, but if you were able to get that branch ready today, I could load it on a test server before I leave for vacation. |
| 13:23 |
kmlussier |
mmorgan is interested in testing it. |
| 13:25 |
* kmlussier |
is trying to get various billing bits in before she tackles billing documentation for 2.9. |
| 13:25 |
kmlussier |
Which brings me to bug 1436797. Maybe that's one I can handle. |
| 13:25 |
pinesol_green |
Launchpad bug 1436797 in Evergreen ""grocery" term confuses frontline staff and patrons" (affected: 11, heat: 48) [Undecided,New] https://launchpad.net/bugs/1436797 |
| 13:41 |
Stompro |
dyrcona++ Thanks for enlightening me about the STAFF_CLIENT_NAME variable, that is just what I needed. I'll add that to the buidling the staff client wiki page. |
| 13:42 |
Stompro |
Dyrcona++ (getting the caps right) |
| 13:42 |
Dyrcona |
Stompro: You can also change it after the fact in application.ini, btw. |
| 13:42 |
Dyrcona |
I don't think karma is case-sensitive. :) |
| 14:02 |
|
rlefaive joined #evergreen |
| 14:07 |
Stompro |
Dyrcona, is there staff client make command that sets the install directory? Or is that customized in windowssetup.nsi? |
| 14:11 |
Dyrcona |
Sompro: I think it |
| 14:11 |
Dyrcona |
heh. |
| 14:12 |
csharp |
@eightball does Dyrcona *actually* think it? |
| 14:12 |
pinesol_green |
csharp: It is possible. |
| 14:12 |
Dyrcona |
Stompro: I think it might use the stamp id as the product tag in windowssetup.nsi, but I never actually install the Windows staff client, so I don't know for sure. |
| 14:14 |
Stompro |
I don't thinks so, my STAMP_ID is set to rel_2_8_2 and the PRODUCT_TAG is set to '2.8' which gets combined with "Evergreen Staff Client" to set the default install. |
| 14:17 |
Stompro |
Dyrcona, I just tested it out, and setting a custom PRODUCT_TAG in windowssetup.nsi does set the default install directory. So I think I've got all the pieces figured out. Thanks for your help. |
| 14:18 |
Stompro |
I love having all the various options on how this stuff can work. |
| 14:18 |
Stompro |
iii-- |
| 14:21 |
Dyrcona |
Stompro: Cool! Glad you find my ramblings useful. |
| 14:21 |
* Dyrcona |
gets lost in the staff client code, again. |
| 14:21 |
* Dyrcona |
thinks he's looking at one thing, turns out it is something else. |
| 14:25 |
Bmagic |
kmlussier: I will take a look |
| 14:36 |
|
akilsdonk joined #evergreen |
| 15:00 |
|
rlefaive joined #evergreen |
| 15:13 |
kmlussier |
mmorgan: When we were talking about bug 1436797 a few weeks back, you suggested that if we did remove the xact_type from the column picker options, that we might want to display billing type and billing note by default. |
| 15:13 |
pinesol_green |
Launchpad bug 1436797 in Evergreen ""grocery" term confuses frontline staff and patrons" (affected: 11, heat: 48) [Undecided,New] https://launchpad.net/bugs/1436797 |
| 15:13 |
kmlussier |
mmorgan: Where would you want to see those as defaults? In the main bill interface and the bill history? |
| 15:16 |
mmorgan |
kmlussier: Yes, both of those places. |
| 15:20 |
kmlussier |
Oops. Accidentally made the payment note display by default. Not as useful. |
| 15:28 |
|
jlitrell joined #evergreen |
| 15:59 |
* csharp |
decides to stop letting end users use software |
| 16:00 |
jlitrell |
+1 |
| 16:03 |
kmlussier |
Well, I guess there would be no point to the software then. We can all go home! |
| 16:07 |
csharp |
I've spent much of this week cleaning up messes, so I'm just grumpy :-/ |
| 16:10 |
kmlussier |
csharp: Sorry to hear that. :( |
| 16:11 |
kmlussier |
On a more positive note, weekend is almost here. |
| 16:13 |
mmorgan |
@dessert csharp |
| 16:13 |
* pinesol_green |
grabs some of kmlussier's cookies for csharp |
| 16:13 |
kmlussier |
Did I know my cookies had made into the dessert plugin? |
| 16:13 |
kmlussier |
Y'all can have those for real if you go to the hack-a-way. |
| 16:15 |
* mmorgan |
likes the ones made with saltines, butter, and chocolate. |
| 16:15 |
mmorgan |
Though technically, I guess, those aren't really cookies. |
| 16:16 |
kmlussier |
I should find something to bring that csharp could eat. |
| 16:16 |
kmlussier |
mmorgan: They count. I'm bringing them. |
| 16:16 |
kmlussier |
I couldn't bring them to Hood River because you need to keep them cold. |
| 16:17 |
kmlussier |
mmorgan: I was surprised we hadn't filed that Located URI bug before. I remember having a conversation about it ages ago. |
| 16:19 |
mmorgan |
Yeah. We've discussed it before, but it never made it to launchpad. |
| 16:20 |
mmorgan |
I was just looking at the call number table today. We have 3.7 million deleted URI call numbers and 1.5 million undeleted URI call numbers. |
| 16:20 |
mmorgan |
and the numbers keep going up because we keep loading records. |
| 16:30 |
kmlussier |
Ouch! |
| 16:47 |
kmlussier |
Heading out for the week. Have a nice week everyone! |
| 16:48 |
mmorgan |
Have a great vacation! |
| 16:49 |
|
kmlussier left #evergreen |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 |
|
mmorgan left #evergreen |
| 17:17 |
|
mrpeters left #evergreen |
| 18:09 |
|
rlefaive joined #evergreen |
| 18:57 |
|
jlitrell joined #evergreen |
| 20:36 |
|
jboyer-isl joined #evergreen |
