| Time |
Nick |
Message |
| 00:46 |
|
stephengwills left #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
jaswinder joined #evergreen |
| 08:05 |
|
dwgreen joined #evergreen |
| 08:38 |
|
rjackson_isl joined #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 09:27 |
|
yboston joined #evergreen |
| 09:56 |
Bmagic |
dbwells: thanks for the idea! I will run that in a minute |
| 10:01 |
Bmagic |
dbwells: I think you might have connected the piece of the puzzle! It seems that the call number ID -1 has a record assigned to it. It should be -1 as well? |
| 10:02 |
dbwells |
Bmagic: Yes, call_number -1 should be attached to record -1; |
| 10:02 |
|
dluch joined #evergreen |
| 10:03 |
Bmagic |
I think a cataloger somehow edited that volume (if that is possible) |
| 10:04 |
|
jaswinder joined #evergreen |
| 10:05 |
|
kmlussier joined #evergreen |
| 10:05 |
|
jaswinder joined #evergreen |
| 10:31 |
Bmagic |
dbwells: yep, that fixed it. LOL. So easy |
| 10:32 |
Bmagic |
dbwells++ |
| 10:32 |
dbwells |
Bmagic: that's great :) |
| 10:37 |
|
Christineb joined #evergreen |
| 10:49 |
jeff |
Just to be clear, was the issue that call number ID -1 had a value in the "record" column other than the expected -1? |
| 10:50 |
Bmagic |
jeff: yep |
| 10:51 |
Bmagic |
Now that I fixed that back to -1, I am still getting results from the srfsh command (memcached?) |
| 10:51 |
Bmagic |
The XUL UI is fine |
| 10:52 |
Bmagic |
jeff: looking at the auditor schema, I found the staff account that was able to edit that volume. Someone was confused :( |
| 10:56 |
|
collum joined #evergreen |
| 11:02 |
Bmagic |
I also found that the bre.id of -1 had deleted='t' |
| 11:02 |
jeff |
not recommended. :-) |
| 11:02 |
Bmagic |
yeah, no doubt |
| 11:03 |
jeff |
db-level protection for bre.id / acn.id <=0 (or <0?) might be useful. I don't think you're the first to run into that. |
| 11:03 |
jeff |
Though also preventing it at the higher levels is probably good. |
| 11:04 |
mmorgan |
Bmagic: Perhaps someone merged id -1 with another record, leaving -1 deleted. |
| 11:04 |
Bmagic |
That seems possible |
| 11:26 |
|
Christineb joined #evergreen |
| 11:48 |
|
jwoodard joined #evergreen |
| 11:50 |
|
jvwoolf joined #evergreen |
| 11:52 |
|
jaswinder joined #evergreen |
| 11:55 |
|
idjit joined #evergreen |
| 11:58 |
|
jaswinder joined #evergreen |
| 12:00 |
|
gsams joined #evergreen |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:12 |
|
littlet joined #evergreen |
| 12:27 |
gsams |
Some libraries in my consortium are having issues with copy level holds I'm having difficulty pinning down. A lot of instances of copy level holds are showing with 0 potential copies while the item is sitting on the shelf. |
| 12:27 |
gsams |
It won't target the available and specific copy no matter what. |
| 12:32 |
kmlussier |
gsams: Are you sure the copies are holdable? Is there something about the copy or patron that would prevent it from targeting? |
| 12:34 |
gsams |
From my experience, a title level hold will be able to target the copy, even superceding the previous copy level hold that came before it. |
| 12:34 |
gsams |
kmlussier: They are holdable, and the patron should be able to place the item on hold. |
| 12:35 |
gsams |
It's a bit of an oddity for sure, and it doesn't appear to happen for all copy holds as far as I can tell. |
| 12:35 |
|
khuckins joined #evergreen |
| 12:40 |
mmorgan |
gsams: I was just looking at some stubborn copy level holds this morning - but these were placed by NCIP, not from within evergreen. |
| 12:41 |
mmorgan |
The holds had a selection depth of 1, when I changed that to 0 they targeted the copy. |
| 12:42 |
* mmorgan |
is not sure what sets selection depth when holds are placed within Evergreen. |
| 12:47 |
kmlussier |
mmorgan: I think selection depth is used with hold boundaries. |
| 12:47 |
mmorgan |
kmlussier: That lightbulb was just about to come on! |
| 12:47 |
kmlussier |
mmorgan: The lightbulb hasn't been packed yet? :) |
| 12:48 |
gsams |
kmlussier: So to correct this I would want to change the soft boundary to 0 then? |
| 12:48 |
mmorgan |
kmlussier: Nope, not yet. Last thing to go in the box :) |
| 12:49 |
kmlussier |
gsams: I don't know. I had been thinking depth might only be used for hard boundaries, but, since we don't use boundaries here, I don't know much about them. Is the depth for the hold set to something other than 0? |
| 12:50 |
gsams |
kmlussier: Yeah, it's set to 2 for the holds that I am seeing, which corresponds to our soft boundary |
| 12:51 |
mmorgan |
I have only recently experimented with boundaries, only hard ones, though. |
| 12:51 |
kmlussier |
gsams: Is the pickup library for the hold outside of that soft boundary? |
| 12:53 |
gsams |
kmlussier: Well, assuming I understand this correctly the soft boundary would limit it to the library level specifically in our consortium so anything outside of a specific library would be. |
| 12:53 |
gsams |
If that is the case, I have no idea how we've been operating for so long with that setting in place. |
| 12:53 |
kmlussier |
lol |
| 12:54 |
gsams |
And further, no clue how it was only recently brought to my attention |
| 12:54 |
mmorgan |
Has anyone recently made changes to the boundary library settings? |
| 12:54 |
gsams |
I think the soft boundary may be unnecessary for us. |
| 12:55 |
gsams |
I think I really need to spend some time to look over our YAOUS setup in detail. |
| 12:55 |
kmlussier |
gsams: Based on my very shaky understanding of soft boundaries, I think it's working as expected because a copy will only go outside of the boundary if there is no other copy available to fill the hold. |
| 12:56 |
mmorgan |
Hmm. For a copy hold, there would be no other copy. |
| 12:56 |
kmlussier |
But I haven't really looked at boundaries closely in about 7 years when we first were considering how to configure our systems. |
| 12:56 |
gsams |
kmlussier: I think ours were set for us, but I think I was really not part of that conversation at the time. |
| 12:58 |
* mmorgan |
was just looking at boundaries over the past week or so, but now realizes that the boundary is stored in the hold. So changing settings won't unbound existing holds. |
| 12:58 |
kmlussier |
mmorgan: Perhaps. If boundaries take that into consideration. |
| 12:59 |
gsams |
I just tested it, and it does indeed fix that particular issue. |
| 12:59 |
gsams |
I had to cancel and replace the hold as mmorgan is correct about the boundary being stored. |
| 12:59 |
gsams |
kmlussier++ |
| 12:59 |
gsams |
mmorgan++ |
| 13:00 |
gsams |
thanks for helping me understand these settings better. |
| 13:00 |
mmorgan |
gsams: Thanks for having the question at the same time I was trying to understand them myself! |
| 13:01 |
mmorgan |
gsams++ |
| 13:01 |
kmlussier |
gsams: I don't know if it's still helpful as there have been many changes in holds, but the results of our original holds testing were posted to the list. https://markmail.org/message/oesp74to5nkw64zt |
| 13:01 |
kmlussier |
This testing is what helped me understand boundaries a little better. |
| 13:04 |
|
jvwoolf1 joined #evergreen |
| 13:04 |
gsams |
kmlussier: Thanks, that might help me make some educated changes! |
| 13:06 |
Bmagic |
Can Evergreen sign outgoing emails with DMARC? |
| 13:06 |
jeff |
do you mean DKIM? |
| 13:06 |
Bmagic |
yes, sorry |
| 13:07 |
jeff |
DKIM is the signing, DMARC is the bit where you specify that others should expect your mail to be signed, etc. |
| 13:07 |
|
beanjammin joined #evergreen |
| 13:07 |
Bmagic |
I am just learning about it. It looks like each message needs to be "signed" with a dynamic hash using a private key of some sort |
| 13:08 |
jeff |
AIUI, DKIM is generally done at the MTA level, not the application / generation level. |
| 13:09 |
jeff |
We're not currently signing, but it is something I'm hoping to start doing soon. I have a few other things related to A/T generated email, also. I should make list. :P |
| 13:12 |
kmlussier |
sigh...that moment when you follow the 3.1 readme for a 3.0 installation. |
| 13:14 |
jeff |
> Please complete registration within 240:00 minutes. |
| 13:30 |
Bmagic |
I assume that EDI messages from the vendor can cancel items automatically. I am trying to figure out where that is signaled in the message |
| 13:33 |
jeff |
I'm not even sure an hour had passed since I sent that search_path related email before something blew up in a test db here due to a search_path issue from... seven years ago. |
| 13:36 |
dbwells |
kmlussier: I am doing some wiki cleanup. Would it hurt anything for me to fix the typo in this link? (I am not sure what this page is for): https://wiki.evergreen-ils.org/doku.php?id=scrachpad:survey_help |
| 13:37 |
dbwells |
(scratchpad is missing the 't') |
| 13:37 |
dbs |
dbwells: if you fix the link, then it will no longer point to the same content |
| 13:38 |
dbs |
https://wiki.evergreen-ils.org/doku.php?id=scratchpad:survey_help "does not exist yet", so whatever pointed at the old link (maybe email about the survey that pointed there for help?) would 404 |
| 13:39 |
dbwells |
dbs: Yes, I am trying to determine if that matters in this case. Not sure if this was just a work-in-progress, one-off, or what. |
| 13:40 |
* dbwells |
will just add the redirect for now |
| 13:41 |
dbs |
yeah, it's linked from the survey form itself |
| 13:41 |
dbwells |
dbs: okay, thanks, that makes it clear. |
| 13:42 |
dbwells |
I didn't connect the dots to where this came from. |
| 13:44 |
dbs |
I did, only because I was so late in filling out the survey :/ |
| 13:46 |
Bmagic |
Can an EDI message cancel an item on an order? Or is that done by the staff when processing invoices? |
| 13:50 |
littlet |
Bmagic Yes, EDI messages can change line items to cancelled |
| 13:50 |
Bmagic |
littlet: The cancel reason would be dictated in the message? |
| 13:51 |
littlet |
It would have to be, I'd think, because it happens without staff intervention and I've seen varying cancel reasons (like delayed vs a true cancellation) |
| 13:52 |
csharp |
yes, it's done by the vendor via EDI - cancel reasons that Evergreen cares about is limited |
| 13:52 |
Bmagic |
It seems like the vendor would need to be aware of the EG cancel reason ID numbers |
| 13:54 |
csharp |
Bmagic: they're defined by the EDI spec and Evergreen knows about and uses the most common ones |
| 13:55 |
csharp |
http://www.editeur.org/31/Library-Book-Supply/ is an entry point for all the docs |
| 13:55 |
Bmagic |
I see. That makes sense. |
| 13:55 |
littlet |
I've had this LP wishlist bug from csharp tucked away to look at on a rainy day sometime, maybe it's helpful? https://bugs.launchpad.net/evergreen/+bug/1627373 |
| 13:55 |
pinesol_green |
Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] |
| 13:56 |
csharp |
littlet++ # I was just looking for that |
| 14:00 |
Bmagic |
Funds are assigned and encumbered before the purchase order is activated right? |
| 14:01 |
littlet |
Funds are assigned before activation, but the encumbrance happens when the order is activated and not before |
| 14:02 |
Bmagic |
I am looking at an order where only some of the items have a fund_debt assigned to them in acq.lineitem_detail. I am attempting to figure out how that is possible. |
| 14:03 |
csharp |
incomplete item load? |
| 14:03 |
|
jaswinder joined #evergreen |
| 14:04 |
Bmagic |
They all have a fund assigned, just no rows in the fund_debt table and no corresponding id in the linitem_detail table - The PO is activated and invoiced and done |
| 14:04 |
Bmagic |
sorry fund_debit |
| 14:04 |
csharp |
I would review the logs for when the activation/item load happened - I would suspect it got interrupted and died off |
| 14:06 |
Bmagic |
I see, those logs are long gone |
| 14:06 |
Bmagic |
but that helps! |
| 14:06 |
csharp |
yeah :-/ |
| 14:06 |
littlet |
A true cancellation would remove fund debits |
| 14:06 |
Bmagic |
in other words - that shouldn't be possible |
| 14:06 |
littlet |
But...I'm struggling to see how you could then end up with an invoice for them |
| 14:06 |
littlet |
And pay the invoice, since you'd have to specify a fund at that point and then there would be a fund debit again |
| 14:07 |
Bmagic |
littlet: two different scenarios. The issue with the fund_debit being missing is on lineitems that are received |
| 14:08 |
Bmagic |
but that makes me wonder if I misunderstood something. At what point in the process will the lineitem_detail rows be assigned a fund_debit? During activation? |
| 14:09 |
littlet |
I'd say yes, since that's when the funds are encumbered. |
| 14:10 |
littlet |
You're not impacting the funds at all until activation |
| 14:11 |
Bmagic |
thanks! |
| 14:11 |
Bmagic |
littlet++ |
| 14:11 |
Bmagic |
csharp++ |
| 14:11 |
littlet |
You're welcome :) |
| 14:12 |
csharp |
@praise littlet |
| 14:12 |
* pinesol_green |
littlet LOVES the RESISTANCE! |
| 14:12 |
littlet |
lol, nice |
| 14:14 |
Bmagic |
Ah! I think I found it - the asset.copy rows are deleted that are referenced by acq.lineitem_detail |
| 14:19 |
littlet |
And this is for the ones where the fund debit is missing, but the items are received? Or am I mixing the two up again? |
| 14:20 |
Bmagic |
they are received but no fund_debit |
| 14:20 |
littlet |
So...maybe they cancelled them, which would delete the fund debits and copies. But then later received the line item, so there would be no associated copies anymore |
| 14:21 |
Bmagic |
can you receive an item that is already canceled? |
| 14:21 |
littlet |
I assumed that receiving a cancelled line item would reinstate fund debits, but maybe I'm just making an assumption |
| 14:21 |
littlet |
Yes, you can |
| 14:22 |
Bmagic |
The action of Canceling an item, will delete the asset.copy row? |
| 14:23 |
littlet |
That one I can't tell you for sure since I can't see that deep, but I can definitely tell you that the copies are deleted from the catalog. So my guess is yes? |
| 14:23 |
Bmagic |
I think that's yes |
| 14:24 |
Bmagic |
Is it normal behavior to receive a canceled item? It's starting to sound like a bug, if canceling an item will delete the copy and remove any references to fund_debit, then subsequently received... |
| 14:25 |
csharp |
Bmagic: backordered items are "canceled", so in that case it's normal |
| 14:25 |
littlet |
I mean, I wouldn't think it would happen too often, but I wouldn't say it's necessarily out of the realm of possibility. Like if someone manually cancelled an item, but the item was already in transit to them at that time, you'd still want to be able to receive it |
| 14:26 |
littlet |
And also, yeah, backorder and true cancels are both called "Canceled". Backorders just keep fund debits, and "true" cancels delete them |
| 14:27 |
Bmagic |
Now that we have established that canceling an item will delete the row in asset.copy. And it's normal behavior to receive a cancled item. The row in asset.copy should be undeleted, and if it doesn't, then it seems that we would have an LP for that |
| 14:27 |
Bmagic |
I found this one but it's not exactly related bug 1269574 |
| 14:27 |
pinesol_green |
Launchpad bug 1269574 in Evergreen "ACQ lineitems canceled via EDI not deleting linked bibs/items" [Medium,Confirmed] https://launchpad.net/bugs/1269574 - Assigned to Chris Sharp (chrissharp123) |
| 14:28 |
littlet |
Ideally the row in asset.copy should be undeleted, but I'd say more important would be reinstating the fund debit. You can always give it a copy manually, but you can't manually create a fund debit for it |
| 14:29 |
Bmagic |
Strange. I certainly have an example of this |
| 14:30 |
littlet |
Of manually creating a fund debit? |
| 14:30 |
Bmagic |
An example where a received item does not have fund_debit |
| 14:31 |
littlet |
Oh, gotcha |
| 14:42 |
|
Shae joined #evergreen |
| 14:59 |
remingtron |
kmlussier: with the email thread about receipt template docs, I noticed you had claimed the related chapter on the webclient docs wiki page. Do you want to keep that, or am I free to work on it? |
| 14:59 |
remingtron |
https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:webclient |
| 14:59 |
remingtron |
(search for "45. Workstation Administration") |
| 15:05 |
rjackson_isl |
anyone else notice that if a patron account is about to expire (3 days out in this case) and the checkout is performed in the web client then no popup warning is recieved? The circ is created but due in 3 days when account expires. |
| 15:06 |
|
mmorgan1 joined #evergreen |
| 15:07 |
rjackson_isl |
I checked in lp and didn't see a related bug. |
| 15:11 |
rjackson_isl |
found this bug: https://bugs.launchpad.net/evergreen/+bug/1726918 but I thought in XUL a popup also was initiated on the attempted checkout as well? |
| 15:11 |
pinesol_green |
Launchpad bug 1726918 in Evergreen "web client: Alert doesn't display for soon-to-expire patron accounts" [Medium,Confirmed] |
| 15:13 |
rjackson_isl |
Nope - sorry for the confusion - the bug covers it all :) |
| 15:16 |
|
gsams_ joined #evergreen |
| 15:17 |
|
foobarrel left #evergreen |
| 15:17 |
|
foobarrel joined #evergreen |
| 15:19 |
|
jaswinder joined #evergreen |
| 15:34 |
|
khuckins joined #evergreen |
| 15:37 |
|
foobarrel joined #evergreen |
| 15:42 |
|
foobarrel joined #evergreen |
| 15:45 |
|
foobarrel joined #evergreen |
| 15:58 |
|
khuckins_ joined #evergreen |
| 16:00 |
jeff |
woah, hey. the 2015 conference had two separate fields for irc and twitter. |
| 16:01 |
jeff |
as did the year before... huh! |
| 16:03 |
|
mmorgan joined #evergreen |
| 16:59 |
|
jonadab joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:10 |
|
khuckins__ joined #evergreen |
| 17:55 |
|
b_bonner left #evergreen |
| 18:05 |
|
foobarrel joined #evergreen |
| 18:24 |
|
jaswinder joined #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live> |
| 19:17 |
|
dwgreen_ joined #evergreen |
| 21:06 |
|
jaswinder joined #evergreen |
| 21:57 |
|
jonadab joined #evergreen |
| 22:33 |
|
jaswinder joined #evergreen |
| 23:00 |
|
bshum joined #evergreen |
