| Time |
Nick |
Message |
| 03:00 |
|
ejk joined #evergreen |
| 07:01 |
|
TARA joined #evergreen |
| 07:20 |
|
Callender joined #evergreen |
| 07:27 |
|
rjackson_isl joined #evergreen |
| 07:29 |
graced |
Happy Wednesday #evergreen |
| 07:29 |
graced |
@coffee |
| 07:29 |
* pinesol_green |
brews and pours a cup of Sumatra Golden Mandheling, and sends it sliding down the bar to graced |
| 07:29 |
graced |
mmmmm |
| 07:40 |
|
rlefaive joined #evergreen |
| 07:43 |
|
JBoyer joined #evergreen |
| 08:00 |
|
artunit_away joined #evergreen |
| 08:01 |
rhamby_ |
@brains |
| 08:01 |
pinesol_green |
rhamby_: Message root @ server God....Universe going down for reboot.... |
| 08:01 |
|
terranmc joined #evergreen |
| 08:01 |
rhamby_ |
We need an @brains |
| 08:05 |
|
krvmga joined #evergreen |
| 08:25 |
|
sam_l joined #evergreen |
| 08:41 |
|
rlefaive_ joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:46 |
|
collum joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 08:57 |
|
maryj joined #evergreen |
| 09:03 |
|
mtj_ left #evergreen |
| 09:16 |
|
ericar joined #evergreen |
| 09:19 |
|
awitter joined #evergreen |
| 09:28 |
|
kmlussier joined #evergreen |
| 09:40 |
|
mllewellyn joined #evergreen |
| 09:45 |
kmlussier |
rhamby_: I'm not sure about the @brains plugin. Since coffee is what gets my brain working, I was thinking it would suffice. |
| 09:46 |
rhamby_ |
kmlussier: I had a sleepless night of a child coughing and feeling miserable. I think zombie like enough that I might need the actual brains. |
| 09:47 |
kmlussier |
rhamby_: Ugh, sorry to hear that. |
| 09:48 |
|
awitter joined #evergreen |
| 10:09 |
|
mmorgan1 joined #evergreen |
| 10:16 |
kmlussier |
I've tested the fix for bug 1564079 and it looks good to me. I want to make sure I handle the database bits correctly when I merge it. |
| 10:16 |
pinesol_green |
Launchpad bug 1564079 in Evergreen "Checkout history fails on serials checkouts / deleted copies" [High,Confirmed] https://launchpad.net/bugs/1564079 - Assigned to Kathy Lussier (klussier) |
| 10:16 |
berick |
kmlussier++ |
| 10:16 |
kmlussier |
It looks like the upgrade script was modified directly for most of the changes, and the only upgrade script I need to stamp is schema.fix_circ_history_copy_ref.sql. Is that correct? |
| 10:17 |
* berick |
looks |
| 10:18 |
berick |
kmlussier: yep |
| 10:18 |
kmlussier |
OK, I'm on it. |
| 10:18 |
kmlussier |
berick++ |
| 10:19 |
berick |
well, XXXX.schema.fix_circ_history_copy_ref.sql needs to be renamed and the commented section at the top needs to be uncommanted and given the right number |
| 10:19 |
berick |
and 002.schema.config.sql needs to be updated too |
| 10:20 |
kmlussier |
berick: Yeah, I got that part. Thanks! |
| 10:22 |
berick |
<mrburns>excellent</> |
| 10:26 |
kmlussier |
berick: Somehow, I have a hard time picturing you as a Mr. Burns. You need to up your evil a bit. |
| 10:30 |
berick |
more evil.. okily dokily! |
| 10:32 |
kmlussier |
Calling 0976 |
| 10:34 |
Dyrcona |
:) |
| 10:37 |
csharp |
@quote add <berick> more evil.. okily dokily! |
| 10:37 |
pinesol_green |
csharp: The operation succeeded. Quote #150 added. |
| 10:39 |
miker |
collum (and someone else that pointed it out ... don't recall who): thanks for pointing out the thinko (and typo) in my slide! it's updated for archiving :) |
| 10:41 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564079 Checkout history handles serials - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6479b57> |
| 10:41 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564079 Checkout history skips nonexistent items - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=83c9572> |
| 10:41 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1564079 Stamping upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0938058> |
| 10:42 |
|
awitter joined #evergreen |
| 10:52 |
|
mmorgan1 left #evergreen |
| 10:57 |
|
mmorgan joined #evergreen |
| 11:07 |
rlefaive |
awitter, csharp: y’all were right! apt-get install evergreen ran just fine when i installed Ubuntu from an .iso. |
| 11:10 |
awitter |
rlefaive nice!! |
| 11:11 |
csharp |
rlefaive: we'll look into making it work with vagrant/vbox |
| 11:12 |
rlefaive |
csharp++ awitter++ |
| 11:14 |
awitter |
rlefaive thanks for testing this |
| 11:16 |
Dyrcona |
rlefaive: Did you install to a virtual machine or to actual hardware? |
| 11:17 |
rlefaive |
it was a virtual machine (virtualbox on my mac), but I suffered through the purple-screen install steps instead of using vagrant up. |
| 11:17 |
jeff |
what basebox were you using with vagrant? |
| 11:17 |
Dyrcona |
Thanks. I thought it was a VM, but just wanted to make sure. |
| 11:17 |
jeff |
er, sorry -- "basebox" might be the wrong term. |
| 11:18 |
jeff |
(that might have been a veewee thing -- it's been a while) |
| 11:18 |
rlefaive |
jeff: no it’s right, “ubuntu/trusty64” |
| 11:18 |
jeff |
rlefaive: and when you installed ubuntu from an iso, which iso did you use? |
| 11:18 |
|
mmorgan1 joined #evergreen |
| 11:18 |
Bmagic |
So, when checking in items with anmesty turned on, it looks like the system is both voiding the original billing AND account_adjusting payments in the opposite amount, resulting in a negative balance. |
| 11:19 |
rlefaive |
jeff: “64-bit PC (AMD64) server install image” downloaded from http://releases.ubuntu.com/14.04/ |
| 11:19 |
Dyrcona |
Bmagic: I've not seen that. Did you enable the prohibit negative balances setting(s)? |
| 11:20 |
* mmorgan1 |
has not seen that either |
| 11:20 |
Dyrcona |
I can say that staff manually voiding a billing can/will create a negative balance despite the settings if the bill has been paid. |
| 11:21 |
Bmagic |
Dyrcona: well, that makes me feel better, I need to take a closer look |
| 11:25 |
Bmagic |
Dyrcona: the account_adjustments occurred 2-17 (lost action trigger), and the voiding occurred during the checkin 4-20. So, amnesty did the voiding upon checkin. It acted upon billing rows that were essentially already voided by the account_adjustment payments already |
| 11:26 |
Bmagic |
no, we are not using the prohibit negative balance settings |
| 11:27 |
Dyrcona |
Bmagic: Well, there you go. ;) |
| 11:27 |
Dyrcona |
Bmagic: You will still get negative balances if you don't turn on the settings. |
| 11:27 |
Bmagic |
should amnesty know about the account_adjustments though? It should be smart? |
| 11:28 |
Dyrcona |
Assuming the account adjustments were for overdue fines, I really don't know. |
| 11:28 |
Bmagic |
or perhaps the amnesty setting should be changed (like the rest of the code) to use account_adjustment instead of void |
| 11:28 |
Bmagic |
yeah, 100 overdue fines for .05 |
| 11:29 |
Dyrcona |
We already have staff complaining that account adjustment shows up as a payment, so I'd argue "No" for amnesty using an adjustment. |
| 11:29 |
Dyrcona |
So, the patron has a negative balance of $5.00? |
| 11:29 |
Bmagic |
yep! |
| 11:29 |
* csharp |
is now testing ubuntu/trusty64 on vagrant so we can compare with base ubuntu installs from ISO |
| 11:30 |
awitter |
csharp++ apt-get install evergreen-ils should work in all cases |
| 11:30 |
Dyrcona |
So, lost didn't just void the overdue billings.... |
| 11:31 |
Dyrcona |
dbwells took this branch over from me and added the account adjustments. |
| 11:32 |
Dyrcona |
I totally rearranged billing and turned voids into a form of payment also, so that may have ended up more confusing for staff. |
| 11:32 |
jeff |
Making some UI changes to help prevent some of that confusion might be a worthwhile undertaking. |
| 11:32 |
Dyrcona |
It sounds to me like this is an unintended side effect, i.e. a bug, but I can't really say. |
| 11:33 |
Dyrcona |
jeff: I could move the details from our RT ticket to Launchpad. |
| 11:33 |
jeff |
I know some changes had been discussed, but I suppose they didn't make it into the scope of the (large amount of) work that was undertaken. |
| 11:34 |
* mmorgan |
is confused. Should the account_adjustment payment type get used at all if none of the Prohibit negative balance settings are set? |
| 11:35 |
* Dyrcona |
is not sure. |
| 11:37 |
jeff |
mmorgan: ideally yes (or a similar payment type), likely current reality unknown. |
| 11:37 |
jeff |
billings and payments, debits and credits... however you want to name them. |
| 11:37 |
|
awitter joined #evergreen |
| 11:38 |
|
maryj joined #evergreen |
| 11:42 |
kmlussier |
mmorgan: Yes, account_adjustment payment type is used for something even if Prohibit negative balance settings are not set. I can't remember where they come up. |
| 11:43 |
|
jvwoolf joined #evergreen |
| 11:43 |
kmlussier |
Dyrcona: Also, on still being able to create negative balances if staff void a billing, the resolution we came up with at the time was to provide two separate permissions for voiding and account adjustment. If you don't want negative balances, you probably should take away the void permission. |
| 11:43 |
* kmlussier |
can't remember if she documented that fact or not. |
| 11:44 |
kmlussier |
I know I intended to document it, but best laid plans... |
| 11:45 |
mmorgan |
Some of our libraries intentionally create negative balances by voiding individual billings. In this way they can refund on a case by case basis. |
| 11:47 |
Dyrcona |
kmlussier: Yep, not sure if it was documented, but we adjusted permissions at the time of our upgrade and documented the new feature for our staff. |
| 11:47 |
kmlussier |
Yes, I added it to the release notes. |
| 11:48 |
kmlussier |
I still want to do a better job of revamping the billing documentation overall. I started it around the 2.9 release. I should finish it. |
| 11:49 |
jeff |
maybe it could coincide with billing fixes for the next release. :-) |
| 11:49 |
|
Christineb joined #evergreen |
| 11:49 |
kmlussier |
Also from the release notes: "The account adjustment payment type will also be used for all libraries, regardless of the state of negative balance settings, in cases where overdue fines are adjusted when an overdue item is marked lost." |
| 11:50 |
jeff |
i expect that we're going to be upgrading to 2.10 with some changes to billing. i don't know how extensive those are going to need to be for us. |
| 11:51 |
Dyrcona |
jeff: We should have just sat down over beers at the conference and refactored the whole thing. :p |
| 11:51 |
Dyrcona |
By "whole thing" I mean all of circ, including holds and billing. :) |
| 11:51 |
mmorgan |
Is there a board game for that? ;-) |
| 11:52 |
Dyrcona |
:) |
| 11:52 |
jeff |
Evergreen Hack-a-way Snowpiercer Edition: Sponsored by Amtrak |
| 11:52 |
jeff |
at the end of the next hack-a-way, a group of individuals board an Amtrak train and don't get off the train until it's done. |
| 11:53 |
Dyrcona |
hah |
| 11:53 |
kmlussier |
I think I took that Amtrak train to Raleigh. |
| 11:53 |
Dyrcona |
On Amtrak they may not get off anyway. |
| 11:54 |
bshum |
jeff: When we start eating bugs, I'll be concerned... |
| 11:54 |
berick |
when they finally depart the train, it's a snowy post-apocalyptic wasteland. |
| 11:55 |
Dyrcona |
That reminds me of a Youtube video I watched last night about moving to Canada.... |
| 11:55 |
berick |
heh |
| 11:56 |
Dyrcona |
"How much of this area here is inhabitable? None of it! That's why they call it, Nunavut." |
| 12:00 |
|
bmills joined #evergreen |
| 12:03 |
Dyrcona |
Lunch time! |
| 12:09 |
maryj |
jeff++ # hackaway snowpiercer edition.I laughed really hard at that. |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:19 |
|
brahmina joined #evergreen |
| 12:19 |
|
barbara joined #evergreen |
| 12:33 |
Dyrcona |
So, one of our directors said something at a meeting yesterday that made me curious about Mass. law and overdue library books, and the law is pretty harsh. |
| 12:34 |
Dyrcona |
It turns out that if you don't return a lost item within 30 days of being notified that it is overdue, you can be fined from $100 to $500 per item, in addition to replacement cost and processing fees! |
| 12:35 |
|
jwoodard joined #evergreen |
| 12:35 |
|
awitter joined #evergreen |
| 12:37 |
Dyrcona |
Bmagic's question earlier reminded me of yesterday's conversation. |
| 12:45 |
|
gsams joined #evergreen |
| 12:57 |
|
jihpringle joined #evergreen |
| 13:02 |
gmcharlt |
EvergreenCatalogs++ # http://list.evergreen-ils.org/pipermail/evergreen-catalogers/2016-April/000622.html |
| 13:06 |
bshum |
Should add that to concerto later :) |
| 13:07 |
bshum |
Along with the first book of Evergreen in action |
| 13:10 |
rhamby_ |
If I'd thought about someone cataloging it I would have put in a more cataloger friendly credits page. Next year.... |
| 13:27 |
csharp |
@quote add <jeff> Evergreen Hack-a-way Snowpiercer Edition: Sponsored by Amtrak |
| 13:27 |
pinesol_green |
csharp: The operation succeeded. Quote #151 added. |
| 13:36 |
csharp |
rlefaive: I can confirm the "apache2 instance did not start within 20 seconds" issue on vagrant ubuntu/trusty64 |
| 13:36 |
csharp |
now looking to see what I can find out |
| 13:50 |
jeffdavis |
Conceptually, what is a serial item vs a serial unit? |
| 13:52 |
jeffdavis |
I see in the db that a unit can have one or more items, but I'm not really clear on what an item "is". |
| 13:52 |
tsbere |
jeffdavis: Item or Issuance? |
| 13:52 |
kmlussier |
item |
| 13:53 |
* tsbere |
knows about issuances and units, but apparently never dug in enough to know about items |
| 13:53 |
kmlussier |
jeffdavis: There's an old IRC log that talks about this, but, from memory, I know you can have multiple items in a unit. Think serials binding. |
| 13:53 |
jeffdavis |
kmlussier: ah, of course! that makes perfect sense, thanks |
| 13:54 |
kmlussier |
jeffdavis: I'm glad it makes perfect sense to you. My head hurts whenever anyone asks me the question. :) |
| 13:55 |
jeffdavis |
heh, well, maybe "perfect sense" is an overstatement :P |
| 13:55 |
jeffdavis |
So, to simplify you have a subscription which has issuances (issues), and physical copies of the issues, but multiple issues can circulate as a single copy (unit) so barcodes are attached to units. |
| 13:56 |
Bmagic |
Dyrcona: yes, the lost action trigger added account_adjustments (now instead of void in eg2.9) and slapped the lost fee on top |
| 13:57 |
|
ericar_ joined #evergreen |
| 14:11 |
|
maryj joined #evergreen |
| 14:11 |
jeffdavis |
collum: my replies to your email are being rejected; short answer is you need Client and Patron Authentication, but not Granted |
| 14:15 |
kmlussier |
Hmmm...I often use Google to search old IRC logs. But lately, Google isn't pulling up older content back before 2013 when we moved to the newer logging. I wonder if there's a problem preventing Google from crawling those old logs. |
| 14:15 |
kmlussier |
We still link to them on the IRC page. |
| 14:16 |
|
_bott_ joined #evergreen |
| 14:17 |
bshum |
kmlussier: It wouldn't surprise me if the old logs aren't being indexed cause they're boring raw text or some other reasons. Like maybe how the irc_logs directory isn't defined in the sitemap.xml that's generated for robots.txt |
| 14:18 |
bshum |
kmlussier: Long term project continues to be migrating all that old log content into ilbot's database to be indexed in the "new" (yeah, okay...) IRC log site. |
| 14:19 |
jihpringle |
does anyone know what "Concept URI" is for in the context of Coded Value Maps? It appeared sometime after 2.8 but I don't see anything in the 2.9 or 2.10 release notes |
| 14:21 |
|
awitter joined #evergreen |
| 14:23 |
kmlussier |
I guess that's another reason why it's a bad idea to keep documentation buried in IRC logs. :( |
| 14:25 |
berick |
jihpringle: does this help? http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=73be52e6d2f8fdaa1c0867271b5428a95803a289 |
| 14:25 |
pinesol_green |
berick: [evergreen|Galen Charlton] LP#1442815: teach record attributes about SKOS - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=73be52e> |
| 14:26 |
jihpringle |
yes, thanks berick |
| 14:29 |
|
hbrennan joined #evergreen |
| 14:35 |
csharp |
rlefaive: we're seeing that the ubuntu/trusty64 vagrant vbox image is 512MB RAM - how much RAM are you allocating when you install ubuntu from ISO manually? |
| 14:36 |
awitter |
. |
| 14:36 |
rlefaive |
csharp: a fair bit more than that… 2686 MB (must have dragged the slider...) |
| 14:37 |
csharp |
rlefaive: yeah 2G is more what's actually needed |
| 14:37 |
rlefaive |
csharp: does it work on ubuntu/trusty64 if you bump the RAM? If you haven’t tried, I will. |
| 14:38 |
|
awitter joined #evergreen |
| 14:38 |
* Dyrcona |
finds 2GB generally too small. I go with 4GB or 8GB. |
| 14:39 |
gmcharlt |
agreed; 4GB is the minimum nowadays for a standalone |
| 14:40 |
csharp |
rlefaive: trying that now - gonna start wih 2G |
| 14:40 |
csharp |
I agree that 4G |
| 14:40 |
csharp |
is a good minimum, but that may not be available on a laptop |
| 14:41 |
csharp |
and you *can* run it on 2G, but not super happily ;-) |
| 14:42 |
berick |
i typically build 2G VM's for dev. never been much of an issue. |
| 14:42 |
Dyrcona |
I had services dying all the time when I actually tried to do anything. Had to drop things to minimums. |
| 14:43 |
Dyrcona |
But then, I run some crazy scripts. :) |
| 14:44 |
csharp |
rlefaive: 2G worked for me - upped the RAM and did 'apt-get -f install' |
| 14:44 |
rlefaive |
csharp: awesome! |
| 14:45 |
csharp |
theoretically it's up and running (though it's NAT-ed at the moment so I'm not able to access it in a browser) |
| 14:45 |
rlefaive |
csharp: haha, i had the same thing when I made the “clean install” version. _facepalm_ |
| 14:46 |
csharp |
yeah - the good news is that vbox makes bridging super easy |
| 14:52 |
* csharp |
said that before trying to do it in vbox and totally borking vagrant in the process :-/ |
| 14:53 |
rlefaive |
csharp: is it possible to put the apt-get install evergreen in a vagrant provision (i.e. a script be able to pass it values for the opensrf passwords etc.)? My vagrant-fu is weak. |
| 14:54 |
csharp |
I'll be honest and tell you that my first experience with vagrant was this morning ;-) but I'll place my faith in open source and say "I'm sure it'll work" :-) |
| 14:55 |
rlefaive |
woohoo! It works beautifully! Thank you all for your help! |
| 14:56 |
|
awitter joined #evergreen |
| 14:56 |
csharp |
rlefaive: awesome |
| 14:57 |
csharp |
rlefaive: thanks for working with us on it! |
| 14:57 |
|
dbwells joined #evergreen |
| 15:01 |
|
awitter joined #evergreen |
| 15:08 |
Bmagic |
Is there a bug doing a title advanced search and the results default to "keyword" in the dropdown? |
| 15:11 |
kmlussier |
Bmagic: A possible variation of bug 1005040 ? |
| 15:11 |
pinesol_green |
Launchpad bug 1005040 in Evergreen "TPAC: eliminate advanced search filters from subsequent basic search box" [Medium,Confirmed] https://launchpad.net/bugs/1005040 |
| 15:12 |
Bmagic |
yep, that's it |
| 15:12 |
kmlussier |
Basically, all those advanced search fields and limiters are thrown into the text-entry box since the search form doesn't have as many bells and whistles of the advanced search page. |
| 15:12 |
Bmagic |
kmlussier++ # finger on the bug pulse |
| 15:12 |
kmlussier |
Bmagic: ESI is going to be doing some work for us on that bug at some point. |
| 15:13 |
Bmagic |
right on! |
| 15:15 |
|
edoceo joined #evergreen |
| 15:43 |
|
kmlussier joined #evergreen |
| 15:45 |
jeffdavis |
dbwells: I'm revisiting bug 1429317, do you have a moment to chat about it? |
| 15:45 |
pinesol_green |
Launchpad bug 1429317 in Evergreen "Serials in holdings view should be able to sort in ascending and descending order as well as by call number" [Wishlist,Incomplete] https://launchpad.net/bugs/1429317 |
| 15:46 |
jeffdavis |
just trying to wrap my head around the basics |
| 15:48 |
hbrennan |
jeffdavis++ Yaaaaaay! No more April issues hogging the first 10 results! That would be awesome. |
| 15:53 |
gmcharlt |
Dyrcona: kmlussier: berick: as a heads-up, I'll be ready to cut 2.10.2 tomorrow. |
| 15:53 |
Dyrcona |
I'll be in and out of the office tomorrow. |
| 15:55 |
Dyrcona |
BTW, I'm signing off on lp 1569884, it could be included in this round of updates. |
| 15:55 |
pinesol_green |
Launchpad bug 1569884 in Evergreen 2.9 "Reusing deleted monograph parts" [Undecided,Confirmed] https://launchpad.net/bugs/1569884 |
| 15:55 |
gmcharlt |
+1 |
| 15:55 |
Dyrcona |
There are no notes or tests, but we're using the upgrade script version in production. |
| 15:57 |
kmlussier |
jeffdavis: I don't know how far you got in your explorations, but in answer to one of the questions Liam asked, there is a serials compressed holdings view that sorts the serials holdings display by date. |
| 15:58 |
kmlussier |
jeffdavis: We don't use that display because of bug 963341. I actually don't think the patch that came with the bug fixes the problem originally reported. I'll have to look into it at some point and file a new one if needed. |
| 15:58 |
pinesol_green |
Launchpad bug 963341 in Evergreen "Allow the JSPac and TPac to display both MFHD records and Serial Control/Alternate records," [Medium,Fix released] https://launchpad.net/bugs/963341 |
| 16:01 |
jeffdavis |
The compressed holdings view is the "Issues Held" area at the bottom of a page like this, right? https://bwlcr.bc.catalogue.libraries.coop/eg/opac/record/108220410?expand=issues#issues |
| 16:02 |
kmlussier |
Yeah. |
| 16:02 |
kmlussier |
Did anyone take notes at the hackfest when we were talking about search? I have a hard time taking notes while I'm talking. |
| 16:04 |
kmlussier |
jeffdavis: Since it's displaying that way in your catalog, I guess that means you've found that setting, then. ;) |
| 16:04 |
jeffdavis |
Well, we have Liam's patch applied in our production environment. But the patch doesn't apply cleanly to 2.10, so I am taking another look at the issue to see if it's feasible to reimplement something that will be more acceptable upstream alongside our 2.10 upgrade. |
| 16:05 |
rlefaive |
kmlussier: i tried but was too distracted by the conversation. ;) |
| 16:06 |
jeffdavis |
The compressed holdings display seems like a useful way of sorting serial holdings, but I am unclear how we could integrate what it's doing into the main holdings display. |
| 16:06 |
kmlussier |
We really like that display here. We once talked over an idea of totally removing the copies display when there are issues on the record and moving the issues display up higher in the record. |
| 16:06 |
kmlussier |
Do we really need two different displays on the same record showing users what is available? |
| 16:07 |
jeffdavis |
How would you handle a scenario where a record has both regular copies and serial units attached? |
| 16:08 |
kmlussier |
jeffdavis: Yeah, well, there's that. And, now that you mention it, we will always have a mix of libraries that use serials and those that just add copies through cataloging. |
| 16:08 |
jeff |
display both with the copies above the others, since "having copies in addition to serial units" is the uncommon case? |
| 16:09 |
kmlussier |
No, I don't think it is the uncommon case for the consortia I work with. |
| 16:09 |
jeff |
i suppose it depends on the ou scope. |
| 16:09 |
jeffdavis |
for my example record above, one branch in the system has issues attached as regular copies, the other 2 branches have serial units |
| 16:10 |
jeff |
at the top level in consortia with mixed practices, certainly "both" is going to be more common. |
| 16:10 |
jeff |
but at the system scope the practices are less likely to be mixed, excepting when migrating practices... |
| 16:10 |
|
rlefaive left #evergreen |
| 16:10 |
jeff |
yeah, i've talked myself out of believing the validity of my original assertion. |
| 16:11 |
jeffdavis |
heh |
| 16:11 |
kmlussier |
And when your consortium strongly encourages people to search at the top level because they're usually doing it from home where they can place holds? |
| 16:11 |
jeffdavis |
kmlussier: what was it you were saying earlier about serials and headaches? :) |
| 16:12 |
Dyrcona |
Just for reference: On a trusty vm running concerto with default settings and the database running on another server, I'm presently seeing 2.1GB in use, and that is with the cache subtracted out. |
| 16:13 |
jeff |
kmlussier: in the case of serials, do the users have the ability then to choose between a copy hold and an issuance hold? |
| 16:14 |
* Dyrcona |
should always remember to ispell-buffer before "saving" a commit message. |
| 16:14 |
* jeff |
muses on the ability to disable title holds on certain records |
| 16:15 |
jeff |
holds on parts don't deal with part-equivalency across org units (I learned that a little bit ago), but now I can't remember without looking if issuance holds handle that kind of thing. |
| 16:16 |
jeff |
"give me this issue, i don't care if it's bound with other issues at these other libraries or available on its own at this other library", etc. |
| 16:17 |
jeff |
I *thought* that issuance holds deal with all of that (with the exception of things that are cataloged as copies), but I was wrong about parts holds also. |
| 16:18 |
berick |
certainly placing org-spanning issue-level holds was addressed. ("give me june 2015 Newsweek from anywhere"). don't recall the details OTTOMH |
| 16:19 |
berick |
but it was one of the core use cases for serials |
| 16:22 |
kmlussier |
jeff: I'm not a good person to ask because, like I said, we don't use the compressed view, which is the one that allows issuance holds. |
| 16:22 |
jeff |
berick: good! i was wrong on that about parts, so happy to hear i wasn't wrong about serials. :-) |
| 16:22 |
dbs |
ungh, after a copy has been added, you can't use the GUI to go back and assign a part to it, right? |
| 16:22 |
kmlussier |
For one consortium, they are using parts for their serials. I don't think the other has found a good way to handle holds yet. |
| 16:22 |
kmlussier |
dbs: Sure you can. |
| 16:23 |
dbs |
kmlussier: i've tried "Holdings Maintenance -> Edit items", no dice |
| 16:23 |
kmlussier |
dbs: But it may be in a not-so-intuitive place. Replace barcode maybe? |
| 16:23 |
jeff |
kmlussier: and in the case of parts-for-serials, there isn't cross-org handling for holds, right? |
| 16:23 |
* kmlussier |
doesn't have a client open. |
| 16:24 |
kmlussier |
jeff: Yes, you can place parts holds across org units. In fact, that's one of the reasons that consortium decided to use parts. |
| 16:24 |
kmlussier |
We were under the impression at the time that issuance holds weren't across org units. But I was recently informed we were mistaken. |
| 16:24 |
dbs |
mmm. Item status -> Actions for cataloguers -> Edit items/volumes per bib |
| 16:25 |
* kmlussier |
looks |
| 16:26 |
jeff |
kmlussier: okay, that's because parts are created at a common ancestor, right? |
| 16:27 |
JBoyer |
They have no org unit, they're all universal. |
| 16:27 |
jeff |
so it's not the cross-org bit that's absent from parts, it's the part (or subpart) equivalency, like "disc 1 is contained in both of these parts". |
| 16:27 |
jeff |
JBoyer: ah. |
| 16:28 |
|
jvwoolf left #evergreen |
| 16:29 |
kmlussier |
dbs: Yeah, Edit items/volumes per bib will get you there too. If you don't default to the unified volume/copy editor, then "Replace Barcode" from holdings maintenance will also work. |
| 16:29 |
kmlussier |
If you do default to the unified editor, then you can just click to edit items. |
| 16:29 |
kmlussier |
Looking forward to just one edit interface in webby to simplify things a bit. |
| 16:36 |
dbs |
kmlussier++ # thanks, "Replace barcode" is a bit unintuitive :) I had 20 copies with 20 separate callnums to assign parts to and unify callnums, so the bulk "Edit items/volumes per bib" did the trick in one shot |
| 16:37 |
dbs |
People are still getting used to parts here, so even when I create the catalogue record & the parts in advance and say "please use the Computer & Charger parts for a single callnum" they sometimes fall back to old habits |
| 16:38 |
dbs |
(not to mention "LC" callnum type for accession callnums of "1001", "1002", etc... heh) |
| 16:44 |
kmlussier |
dbs: Yeah, we tested parts at the same time we were testing the unified volume/copy editor, so I didn't notice the "unintuitive for non-unified-editor users" piece until others started using the feature. |
| 16:46 |
|
gmcharlt_ joined #evergreen |
| 16:46 |
|
dbs joined #evergreen |
| 16:48 |
|
awitter joined #evergreen |
| 17:08 |
gmcharlt_ |
buildmaster |
| 17:08 |
gmcharlt_ |
*cough* |
| 17:08 |
gmcharlt_ |
pretend I succesffully did ctrl-F there |
| 17:08 |
gmcharlt_ |
buildmaster |
| 17:08 |
kmlussier |
Ha ha. I'm glad I'm not the only one who does that. |
| 17:09 |
gmcharlt_ |
*sigh* I am not UIing very well today, evidently |
| 17:17 |
|
gmcharlt joined #evergreen |
| 17:30 |
|
awitter joined #evergreen |
| 18:01 |
dbwells |
jeffdavis: Sorry I missed your serials discussion earlier. On my way out right now, but would be happy to help push forward on some of this soon. |
| 18:02 |
jeffdavis |
dbwells: great, thanks - I'll update the LP ticket and maybe bug you on IRC tomorrow? |
| 18:03 |
|
kimo_sabe joined #evergreen |
| 18:04 |
dbwells |
Also, for anyone asking/wondering earlier, IIRC, issuance holds will span as many org units as the "subscription" spans, since that is where issuances attach. If you have consortial subs, the hold will target any matching unit, but if you have a subscription set up at e.g. a branch, your issuance holds will only get filled by that branch's units. |
| 18:06 |
dbwells |
jeffdavis: For IRC, I should be much more around on Friday |
| 18:10 |
kimo_sabe |
anyone familiar enough with the booking module to explain the need for a bit of logic? I'm unclear why canceling a reservation should check-in the item |
| 18:14 |
kimo_sabe |
there's a perl "==" vs "eq" bug there that is triggering the checkin every time but I can't wrap my head around why canceling a reservation in the future should silently return an item that hasn't been returned |
| 18:25 |
kimo_sabe |
miker: git blames you way back in 2010 |
| 18:51 |
|
terranmc joined #evergreen |
| 18:54 |
|
bmills joined #evergreen |
| 19:07 |
|
terranmc joined #evergreen |
| 19:08 |
jeff |
dbwells: thanks for the detail re: issuance holds. |
| 19:47 |
|
brahmina joined #evergreen |
| 20:54 |
|
kimo_sabe joined #evergreen |
| 21:16 |
hbrennan |
|
| 21:33 |
|
bmills joined #evergreen |
| 21:42 |
|
geoffsams joined #evergreen |
| 22:11 |
|
dcook joined #evergreen |
| 22:55 |
|
dcook joined #evergreen |
| 23:55 |
|
bmills joined #evergreen |
