| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:54 |
|
brettgilio joined #evergreen |
| 08:29 |
|
Dyrcona joined #evergreen |
| 08:37 |
|
mantis joined #evergreen |
| 09:02 |
|
dguarrac joined #evergreen |
| 09:02 |
|
rfrasur joined #evergreen |
| 09:32 |
mantis |
Trying to hide all items at one org unit (they're renovating). Running on 3.5.4. Basically, I try to run the sql along with this refresh (SELECT asset.refresh_opac_visible_copies_mat_view();) but the items are still appearing in the catalog after clearing cache/restarting browser/etc |
| 09:33 |
csharp_ |
mantis: check that the items still showing are actually assigned to shelving locations owned by the closed library |
| 09:38 |
mantis |
csharp: they are |
| 09:41 |
|
nfBurton joined #evergreen |
| 09:42 |
csharp_ |
and each of those locations is marked opac_visible = false? |
| 09:43 |
mantis |
csharp: in the SQL. Additionally holdable ='f' |
| 09:43 |
mantis |
The holdable was the only thing that worked |
| 09:44 |
csharp_ |
can you share the SQL? |
| 09:45 |
mantis |
update asset.copy |
| 09:45 |
mantis |
set holdable = 'f',opac_visible = 'f' |
| 09:45 |
mantis |
where circ_lib = 95 |
| 09:45 |
mantis |
and deleted = 'f' |
| 09:45 |
csharp_ |
oh, ok |
| 09:45 |
mantis |
Also ran this refresh even though I think we don't need to for this verison of Evergreen |
| 09:45 |
mantis |
SELECT asset.refresh_opac_visible_copies_mat_view(); |
| 09:45 |
Dyrcona |
mantis: I don't think opac_visible copies is used any more. Someone mentioned that last week. |
| 09:46 |
csharp_ |
mantis: btw, should be easier to set those flags at the shelving location level (assuming items are in the right locations) - can be done in the UI without having to touch every copy |
| 09:46 |
csharp_ |
but, seems to me that your query should do what you're after |
| 09:47 |
mantis |
csharp: I'm thinking at this point, it's the only way to make sure it gets done so I'll just do that manually like you suggest |
| 09:47 |
mantis |
Just curious as to why the SQL doesn't wanna hang on |
| 09:47 |
Dyrcona |
mantis: Are you tesing in the staff client or in the patron OPAC. |
| 09:48 |
mantis |
Dyrcona: Staff |
| 09:48 |
Dyrcona |
Well, I suspect the staff client is ignoring opac_visible, but I haven't checked the code. |
| 09:48 |
csharp_ |
mantis: try something like "select blah from asset.copy where holdable and opac_visible and not deleted and circ_lib = 95;" to see what comes up? |
| 09:48 |
alynn26 |
The staff client does ignore OPAC Visible. |
| 09:49 |
csharp_ |
oh - yeah, that's expected if that's the issue |
| 09:49 |
mantis |
Seems that the OPAC has the same results |
| 09:50 |
csharp_ |
we've talked about a "staff_visible" column on copies/locations but that's not been implemented yet as far as I know\ |
| 09:51 |
alynn26 |
OPAC Visible is only used in the public facing OPAC. Try it in incognito mode. And have you set the Actual Org unit as OPAC Visible. |
| 09:51 |
Bmagic |
mantis: be sure and log out before testing the OPAC. Even though you change the URL to the Patron side, you are still logged in (unless you actively click log off) - will will still show you staff results |
| 09:51 |
mantis |
select * from asset.copy where holdable = 'f' and opac_visible ='f' and not deleted and circ_lib = 95; comes up with the number of results I needed |
| 09:52 |
Dyrcona |
manits: What Bmagic said. I was typing up almost the same thing, or use an incognito/private window for the patron opac. |
| 09:52 |
mantis |
Bmagic: awesome thank you |
| 09:53 |
mantis |
Interesting I wasn't aware of t`hat |
| 09:53 |
Dyrcona |
Another way around that is to have a different URL for patrons and staff. |
| 09:53 |
Bmagic |
yeah, a little bit of an annoyance to say the least |
| 09:53 |
Dyrcona |
Like a different TLD. |
| 09:53 |
mantis |
Bmagic++ |
| 09:53 |
mantis |
csharp++ |
| 09:53 |
mantis |
Dyrcona++ |
| 09:56 |
Dyrcona |
Grr. Different domain, not TLD..... |
| 09:57 |
Dyrcona |
Example: We have library-specific domains as well as bark.cwmars.org or catalog.cwmars.org. I use bark with the staff client and catalog when I want to check the patron OPAC. |
| 09:59 |
Dyrcona |
Since browsers store preferences and data by domain name that gets around the issue that Bmagic mentioned. |
| 10:06 |
Dyrcona |
http://irc.evergreen-ils.org/evergreen/2021-05-03#i_481588 |
| 10:07 |
Dyrcona |
Just sayin' that it works. One of the SIP2 servers had issues Saturday morning and ldirectord took it out of rotation automatically. |
| 10:09 |
Dyrcona |
Shameless plug: https://gist.github.com/Dyrcona/b60f239f382ee74c063d9138a2d815b2 |
| 10:18 |
nfBurton |
Is there any fix for Part Level Holds on SIP connections? It keeps killing my SIP connection |
| 10:19 |
nfBurton |
Also, def bookmarking that Github |
| 10:19 |
nfBurton |
Dyrcona++ |
| 10:20 |
Dyrcona |
nfburton: I don't think we have anything that places holds via SIP here, so I wasn't aware that there was an issue with parts holds. |
| 10:20 |
nfBurton |
No. The issue is when we do Patron Information, it hiccups on Part Level holds and discionnects |
| 10:20 |
nfBurton |
Not in placing the hold |
| 10:21 |
Dyrcona |
Oh! I wasn't aware of that either. |
| 10:21 |
Dyrcona |
Or, if I was, It's not ringing any bells right now. |
| 10:21 |
nfBurton |
It ends up blocking users from using our self checks when they have a part level hold. I used my SIP tool to check it and that also errors out when getting Patron Info/Holds and a part level hold is on the acct |
| 10:22 |
nfBurton |
I had to remove all parts from my system (not very ideal) |
| 10:22 |
Dyrcona |
Do you have any log information as to why? Like a part or hold information lookup failure? |
| 10:22 |
nfBurton |
Except for stuff that can't be checked out anyways |
| 10:25 |
nfBurton |
The Selfcheck just shows a disconnect due to malformed response. But not much in the SIP logs |
| 10:27 |
nfBurton |
Wish the SIP log had a datetime indictor |
| 10:28 |
mantis |
Do autorenewal messages send out for every checkout regardless if the item is assigned a circ rule for no autorenewals? |
| 10:29 |
JBoyer |
nfBurton, I recall working on something like that; and possibly instance holds also. I'll see if I can find it. |
| 10:30 |
Dyrcona |
nfBurton: It doesn't look like the SIP code handles part holds at all. |
| 10:30 |
nfBurton |
I pushed a patch on my system from an LP bug where part holds would respond blank. |
| 10:31 |
nfBurton |
Still testing it though |
| 10:31 |
Dyrcona |
nfBurton: If you send your SIP logs through syslog, you'll get a timestamp added by syslog. |
| 10:31 |
JBoyer |
yeah, bug 1525394 |
| 10:31 |
pinesol |
Launchpad bug 1525394 in Evergreen 3.6 "SIP patron part level holds respond blank" [Undecided,New] https://launchpad.net/bugs/1525394 |
| 10:31 |
JBoyer |
nfBurton, is that when you started seeing the dropped connections? |
| 10:31 |
nfBurton |
Yeah. It may just be my grandfathered holds causing issues now? |
| 10:31 |
JBoyer |
Shouldn't :/ |
| 10:32 |
Bmagic |
I was about to look that up - I filed that one |
| 10:32 |
JBoyer |
Did you push both commits or just the first? |
| 10:32 |
nfBurton |
Anytime SIP tries to read Patron Information > Holds |
| 10:32 |
nfBurton |
And there is a part level hold |
| 10:32 |
nfBurton |
I think that patch may have helped but still have issues with older ones |
| 10:33 |
Dyrcona |
mantis: Autorenewal look at the circ matrix. It goes by what's in the action.circulation row. |
| 10:33 |
nfBurton |
Hopefully that patch gets pushed soon. It has a patch and signoff since 3.4 |
| 10:33 |
Dyrcona |
Grr... Autorenewal doesn't look at the circ matrix. |
| 10:34 |
Dyrcona |
The circ. matrix should put the correct information in the circulation row at the time of the checkout. If the matrix is later changed, it has no effect on existing circulations. |
| 10:35 |
JBoyer |
1525394 has a signoff for Bmagic's commit, but not mine. Looks like it hasn't been touched since. |
| 10:35 |
JBoyer |
If you have some part holds that work and some that don't that might warrant investigation, otherwise it sounds like there's more to do on it. :/ |
| 10:35 |
Dyrcona |
nfButon: If it's working for you, you could always add a signoff. |
| 10:36 |
nfBurton |
I'm still testing but can once I get more results |
| 10:36 |
nfBurton |
i need to learn signoffs anyways |
| 10:36 |
nfBurton |
JBoyer Ah, I didn't see the second patch |
| 10:37 |
nfBurton |
JBoyer++ |
| 10:38 |
Dyrcona |
mantis: I should add that the renewal part of autorenewal of course uses the matrix. If the renewal fails, I think the event gets an error status, but I'd have to double check the code. |
| 10:40 |
Dyrcona |
I also don't recall if the autorenewal field is checked when an autorenewal happens in the circ. code. It many still only look at the auto_renewal_remaining field on the circulation. |
| 10:41 |
mantis |
Dyrcona: This one particular circ mod has a 14d_0r rule without any autorenewals |
| 10:42 |
mantis |
Yet I still got a notice saying "no autorenewals remaining" |
| 10:42 |
Dyrcona |
Yeah, that would seem to make sense. It does run for every circulation. |
| 10:42 |
mantis |
Ok thanks |
| 10:42 |
mantis |
Dyrcona++ |
| 10:43 |
mantis |
I guess I never had this come across via testing |
| 10:44 |
Dyrcona |
If you think of the notice as a reminder/courtesy to the patron, it makes sense to tell them that the item couldn't be renewed. After all, patrons can't be expected to know all of the circ rules. |
| 10:45 |
mantis |
Right. I agree. I can see why it also causes confusion with some people, too. |
| 10:45 |
mantis |
We're still on 3.5.4 but upgrading to 3.6.4 this year. I saw in the patch notes that the reasonings have been updated. |
| 10:46 |
Dyrcona |
I suppose it would make sense to have a message saying that the loan rules don't allow this item to be automatically renewed in cases like this, but that's not a tiny feat. |
| 10:47 |
mantis |
Yeah |
| 10:48 |
nfBurton |
How do I issuance hold something? I'm familiar with T/P/C/V/M but not I |
| 10:49 |
nfBurton |
Though we do use serials |
| 11:12 |
nfBurton |
Hmm, those part level holds doon't respond blank anymore, but with a barcode for a completely different item |
| 11:35 |
|
nfBurton joined #evergreen |
| 12:06 |
|
Christineb joined #evergreen |
| 12:58 |
JBoyer |
nfBurton, re: issuance holds, I'm not sure they're currently exposed in the OPAC(s). :( |
| 12:59 |
JBoyer |
And if your part holds are returning nonsense in SIP responses I'll need to see what's up there. Depending on the circumstances it's possible that's not a bug (if there isn't a current copy but SIP wants an eligible barcode, for instance) |
| 13:00 |
JBoyer |
But if it's returning the wrong barcode for a captured hold than that's no good. |
| 13:00 |
jeff |
SIP returns a "representative copy barcode" for most/all holds, captured or not. |
| 13:00 |
jeff |
selfchecks often then query the item information for that barcode to get a title. |
| 13:01 |
JBoyer |
That's what I'm hoping is the case, yeah. |
| 13:02 |
jeff |
if the SIP server is configured to use item barcodes for msg64 responses and it can't determine a representative barcode, it should probably pretend that the hold does not exist, or *maybe* use a placeholder barcode that it replies to internally with a dummy title. |
| 13:02 |
jeff |
I can't remember what it does currently, because I'm pretty sure a hold on a title with all deleted copies can cause that issue pretty quickly, and I'm pretty sure that was fixed a while ago. |
| 13:03 |
jeff |
rather, holds on deleted titles used to be a problem for SIP server, and isn't now. |
| 13:03 |
jeff |
(iirc) |
| 13:03 |
jeff |
so whatever approach we used to fix that might help here if there's no fallback and we need one. |
| 13:04 |
JBoyer |
... and then I read the comment on the bug, and that's super not it. :-/ |
| 13:05 |
JBoyer |
/me goes a-spelunking. |
| 13:05 |
JBoyer |
\me does to |
| 13:05 |
JBoyer |
quits. >:[ |
| 13:06 |
JBoyer |
(I didn't realize how spoiled I have become by Slack's edit feature.) |
| 13:09 |
rhamby |
Jboyer - it sneaks up on you |
| 13:10 |
nfBurton |
I would be interested to know if it has the same affect in other's systems |
| 13:10 |
nfBurton |
I held a DVD part and got a response of a John Denver CD that has NO monograph parts |
| 13:11 |
nfBurton |
The DVD Part only has one item that could possibly fill it too |
| 13:11 |
nfBurton |
On the flip side, I at least don't have SIP crashing. But the item is wrong. So it's a step forward |
| 13:15 |
JBoyer |
And looking over those commits they both are concerned with titles only, not barcodes. I thought I had done some work with those somewhere also but apparently not there. That's definitely going to cause problems because I |
| 13:15 |
JBoyer |
m fairly sure that they're being treated as some other hold type entirely, likely title. |
| 13:17 |
nfBurton |
Ahhh. That would make sense to why the barcode was way off |
| 13:18 |
JBoyer |
Pfft. I did do this, I did it for this specific bug, and then didn't push the commit. |
| 13:18 |
JBoyer |
1 second. |
| 13:19 |
jeff |
yeah, find_copy_for_hold would be interpreting the target incorrectly. |
| 13:22 |
|
rfrasur joined #evergreen |
| 13:22 |
JBoyer |
nfBurton, working/user/jboyer/lp1525394_more_sip_hold_titles_2 has 1 more commit that should address that. I'm not sure at the moment what it does for un-captured holds at the moment though, so keep an eye on it. |
| 13:37 |
JBoyer |
mmm, looking at the issuance part of that commit I'm not sure I really understood the serials schema well enough at that point. It acts like all units require backing acp's, which just isn't how it's done. (One could argue for something like that given their similarities, but I'm not going to step in that today) |
| 13:38 |
nfBurton |
getting invalid checksum again and SIP crashing :S |
| 13:41 |
jeff |
do you have error detection enabled on the clients? |
| 13:42 |
JBoyer |
Not sure why it would do that. :/ |
| 13:43 |
jeff |
barcodes containing AY in just the wrong place can trigger checksum failures, even if checksums aren't enabled. |
| 13:43 |
jeff |
if you have placeholder/on-order barcodes in the db that contain AY I'd look into that, but if not disregard. |
| 13:44 |
Dyrcona |
Does anyone use marc_stream_importer.pl as a server with OCLC to import records? |
| 13:44 |
jeff |
we've experimented with it in the past, but are not currently using it. |
| 13:44 |
Dyrcona |
Fun thing about SIPServer: It will turn checksumming if the client sends what looks like checksum fields. |
| 13:44 |
* jeff |
nods |
| 13:45 |
Dyrcona |
jeff: Did it work? I'm looking into it, and it looks to me like a lot of the information asked for on the OCLC side is unnecessary. I'm also not sure how this would be secured. |
| 13:47 |
JBoyer |
If memory serves somewhere in there it spells out "This means anyone can inject MARC records into your database" so short of iptables and OCLC's ip range I'm not sure you do. :/ |
| 13:47 |
* jeff |
nods |
| 13:48 |
JBoyer |
(Which I suspect is a failing on OCLC's side as much as any other.) |
| 13:48 |
jeff |
permitting OCLC by source IP was the extent of the protection available, iirc. |
| 13:49 |
jeff |
this article documents a /24 and a /32 for the TCP/IP export option: https://help.oclc.org/Metadata_Services/Connexion/Troubleshooting/URL_address_and_port_ranges_for_Connexion_browser |
| 13:50 |
Dyrcona |
JBoyer | jeff: Thanks for the info. Looking at a screenshot of the OCLC side, they could send a username/password, at least, but the Evergreen side wouldn't use it. |
| 13:50 |
jeff |
ah. that rings a bell. i think i looked at adding support for that. |
| 13:51 |
jeff |
also, i think the desktop client may initiate the connections from the client PC. |
| 13:52 |
jeff |
the desktop connexion client also has another option, "OCLC Gateway Export". this lets the ILS return a status message that's displayed to the end user. |
| 13:52 |
jeff |
OCLC and Koha have some documentation on that. I think I looked at that a while ago also. |
| 13:53 |
Dyrcona |
The marc stream importer also appears to be aimed more at loading a file via command line, since it requires a username, password, workstation, queue, etc as command line options. This does not seem to be optimized to run as a server process. |
| 13:56 |
JBoyer |
I thought those might be optional in server mode (though I haven't looked in a long time) |
| 13:57 |
Dyrcona |
I'll keep looking. Thanks, again. |
| 13:59 |
jeff |
not sure about "optimized" to run as a server process, but it certainly supports running as a server process. |
| 13:59 |
jeff |
https://wiki.evergreen-ils.org/doku.php?id=scratchpad:marc_stream_importer&s[]=stream |
| 14:01 |
Dyrcona |
JBoyer: They're not optional in server mode. It will fail to login if they're not specified, unless there's some magic going on with Net::Server and the configuration that is not explicit in the code. |
| 14:03 |
JBoyer |
Oh, right, has to be able to call the apis... If anything is optional for server mode it might be workstation, but even that is uncertain. It was added because of a change made to vandelay that may just require it. |
| 14:03 |
JBoyer |
If it's smart enough to retry when the login tokens timeout it should work fine though. |
| 14:04 |
Dyrcona |
Right, but this limits the usefulness of the service. |
| 14:09 |
jeff |
you were hoping for something that would allow for the records to be created by individual users, and not as a general "imported from oclc" user? |
| 14:10 |
jeff |
right now, you could create multiple dedicated import users and run one stream importer per user on different ports. |
| 14:12 |
jeff |
i think the thing i was looking at was being able to pass a username and a stream importer password (different from the Evergreen password because it's sent unencrypted) as well as being able to return messages "oclc gateway" style to the desktop client. |
| 14:14 |
Dyrcona |
jeff: Yeah, pretty much. Also, it's 2021, why isn't everything encrypted? <- rhetorical question |
| 14:26 |
Dyrcona |
Importing records at various times into the same queue is not a problem, is it? |
| 14:42 |
Dyrcona |
Anchor tags. People need to use more anchor tags, so that I can link directly to the relevant portion of the document. |
| 15:04 |
jeff |
hilight some text, right-click, "copy link to highlight", i.e. https://www.postgresql.org/docs/9.6/textsearch-intro.html#:~:text=helpful%20in%20converting |
| 15:04 |
jeff |
(only works in Chrome at the moment) |
| 15:15 |
Dyrcona |
Ooh. That's almost as good as Xanadu. :) |
| 15:53 |
Dyrcona |
It looks like the Net::Server module accepts allow and deny directives. |
| 15:53 |
Dyrcona |
So, it can be controlled without iptables, I hope. |
| 15:53 |
Dyrcona |
https://metacpan.org/pod/Net::Server#CONFIGURATION-FILE |
| 16:06 |
|
abneiman joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
