| Time |
Nick |
Message |
| 07:01 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
bdljohn joined #evergreen |
| 07:34 |
|
gsams joined #evergreen |
| 07:42 |
|
kmlussier joined #evergreen |
| 07:43 |
kmlussier |
Good morning #evergreen! |
| 08:00 |
rhamby |
Good moring! |
| 08:04 |
kmlussier |
@coffee rhamby |
| 08:04 |
* pinesol |
brews and pours a cup of Nicaraguan Maragogipe Light Roast, and sends it sliding down the bar to rhamby |
| 08:05 |
* rhamby |
mmmmmm |
| 08:10 |
|
bos20k joined #evergreen |
| 08:34 |
|
rlefaive joined #evergreen |
| 08:36 |
rlefaive |
Good morning #evergreen! |
| 08:40 |
kmlussier |
rlefaive: Good morning! |
| 08:41 |
rlefaive |
@coffee kmlussier |
| 08:41 |
* pinesol |
brews and pours a cup of Kenya AA, and sends it sliding down the bar to kmlussier |
| 08:41 |
|
kmlussier joined #evergreen |
| 08:42 |
kmlussier |
rlefaive: Thanks! I think I'll need that today. |
| 08:43 |
rlefaive |
seems awfully quiet here… hope it wasn’t the romaine. |
| 08:44 |
rlefaive |
Do… uh… you happen to know if there’s talk of recreating the “Actions for Cataloguers” functionality in the web client? |
| 08:45 |
kmlussier |
rlefaive: On the Item Status screen? I assumed it was removed because they consolidated all of the actions into one menu. |
| 08:47 |
rlefaive |
huh… maybe the features we’re looking for are under a different name. :[ |
| 08:49 |
rlefaive |
but it really looks like they’re just… gone. (i think it was “Delete record and volume”) |
| 08:50 |
kmlussier |
rlefaive: Deleting a record is done from the MARC Edit screen now. |
| 08:52 |
kmlussier |
I know you can delete volumes/call numbers from Holdings View. I'm not sure if you can delete them from anywhere else. I don't see it in Item Status. |
| 08:57 |
rlefaive |
thanks kmlussier! i think it caused a workflow to be really long in order to delete an item-in-hand… i’ll go see how bad, and maybe make a ticket. |
| 08:58 |
kmlussier |
rlefaive: Yes, if delete volumes was available in more places in xul, I could see an argument for making it available in those places in the web client. |
| 08:59 |
kmlussier |
I kind of like the location of the action to delete a record, because I'm not a big fan of making that action too easily accessible. But that's just me. |
| 09:00 |
|
mmorgan joined #evergreen |
| 09:01 |
rlefaive |
yeah, but weeding’s hard enough to do as it is. I guess we might be unusual in that we are a single library, and deleting our copies means deleting the record. |
| 09:02 |
kmlussier |
hmmmm |
| 09:03 |
kmlussier |
rlefaive: Have you enabled the Library Setting to Delete volume with last copy? With that, if you're deleting the last copy on the record, it would automatically delete the call number and then delete the bib record. |
| 09:04 |
kmlussier |
Unless you have the Retain empty bibs library setting enabled. |
| 09:04 |
mmorgan |
rlefaive: We have the settings kmlussier mentions set such that deleting the last item will delete the call number and bib record. |
| 09:05 |
rlefaive |
ooh! is that safe for a catalogue with e-book records? |
| 09:06 |
kmlussier |
rlefaive: Are you using located URIs? If so, those are considered copies. |
| 09:08 |
kmlussier |
I imagine transcendent bib records without Located URIs are safe too. The bib records only get deleted when the last copy is deleted, but if the record never had copies, they should be fine. |
| 09:10 |
rlefaive |
kmlussier: thanks. We have a small handful of “merged” records with electronic links and copies,and we haven’t been using located URI’s but might start, for that reason. |
| 09:13 |
kmlussier |
rlefaive: FWIW, the behavior to automatically delete the bib record when all volumes/copies are deleted is the default behavior, so your system may already be doing that. It's the automatic deletion of volumes that requires you to enable a setting. |
| 09:15 |
rlefaive |
kmlussier: aha! I’m gonna try this out! |
| 09:19 |
|
mdriscoll joined #evergreen |
| 09:32 |
|
rlefaive_ joined #evergreen |
| 09:51 |
|
rlefaive joined #evergreen |
| 09:54 |
|
agoben joined #evergreen |
| 09:56 |
|
rlefaive joined #evergreen |
| 10:10 |
|
rlefaive joined #evergreen |
| 10:20 |
|
rlefaive joined #evergreen |
| 10:27 |
|
rlefaive joined #evergreen |
| 10:29 |
|
devted joined #evergreen |
| 10:29 |
|
dluch joined #evergreen |
| 10:40 |
|
rlefaive joined #evergreen |
| 10:42 |
|
rlefaive joined #evergreen |
| 10:42 |
mmorgan |
I have a patron permission group that is not allowed to checkout items at a library. |
| 10:43 |
mmorgan |
I have a circ matrix matchpoint set up with circulate=false, but the message at checkout is "target item is not allowed to circulate", which staff users find confusing, as it looks like an item issue |
| 10:44 |
mmorgan |
I've tried setting up a standing penalty, and a limit set, but neither seems to work when the threshold is zero. |
| 10:44 |
mmorgan |
Is there a better way to prevent checkouts to these patrons than the circulate=false in the circ matrix? |
| 10:49 |
|
JBoyer joined #evergreen |
| 10:49 |
* JBoyer |
appears from the bushes |
| 10:49 |
JBoyer |
mmorgan: bug 1576754 |
| 10:49 |
pinesol |
Launchpad bug 1576754 in Evergreen "Custom Error Messages for Circ/Hold Matrix Matchpoints" [Wishlist,New] https://launchpad.net/bugs/1576754 |
| 10:49 |
* JBoyer |
disappears into the mist |
| 10:50 |
mmorgan |
JBoyer++ |
| 10:50 |
mmorgan |
Who was that masked man?;-) |
| 10:51 |
|
rlefaive joined #evergreen |
| 10:54 |
kmlussier |
Ha ha ha. Does he have an alert that goes off whenever somebody asks a question that he knows the answer to? |
| 10:57 |
|
rlefaive joined #evergreen |
| 11:00 |
|
rlefaive joined #evergreen |
| 11:00 |
|
bdljohn joined #evergreen |
| 11:04 |
|
rlefaive joined #evergreen |
| 11:15 |
|
rlefaive joined #evergreen |
| 11:35 |
|
rlefaive joined #evergreen |
| 11:46 |
|
blongwel joined #evergreen |
| 11:47 |
blongwel |
Recently updated to 3.1.7. Patron search by email not working in xul client or web client. Is this a known issue? |
| 11:49 |
kmlussier |
blongwel: I haven't heard of a previous bug report. Let me check the community demo server to see if I can replicate it. |
| 11:50 |
jeff |
blongwel: which version were you running previously where patron search by email was working without issue? |
| 11:50 |
blongwel |
previous version was 2.11 |
| 11:50 |
mmorgan |
blongwel: I was just able to search by email in the xul client on a 3.1.7 server. It did take a few moments. |
| 11:51 |
kmlussier |
It works for me in 3.1.6 |
| 11:52 |
mmorgan |
Also worked in the web client on the same server. |
| 11:53 |
blongwel |
I am getting a no patrons found message after just a couple seconds. Seems isolated to us based on what all of you are reporting. Thanks |
| 11:56 |
|
stephengwills joined #evergreen |
| 11:56 |
mmorgan |
blongwel: Do you have an org unit filter set in your patron search, or a permission profile filter? |
| 11:57 |
|
Bmagic joined #evergreen |
| 11:58 |
blongwel |
mmorgan: no filters were set |
| 11:58 |
|
dluch joined #evergreen |
| 11:58 |
|
devted joined #evergreen |
| 11:58 |
blongwel |
Discovered that if I edited the patron record, changed the email address and saved, a search would return the patron. |
| 11:59 |
stephengwills |
3.0.6-3.1.0-upgrade-db.sql:1060: ERROR: function evergreen.oils_json_to_text(text) does not exist |
| 11:59 |
stephengwills |
it appears this function belongs to public in my schema |
| 12:00 |
jeff |
blongwel: if you pick another patron and search by email address does that work? is it possible that the patron you were searching for had an email address other than what you thought it was, for example due to non-obvious characters being present (or different) in the email address? |
| 12:00 |
jeff |
stephengwills: depending on the history of your database and your search path, you may have it in a schema other than what evergreen expects, or (in some other cases, not this one) you may have two identical or different copies in different schemas. |
| 12:01 |
* jeff |
should write up search path issues and how to fix and prevent them |
| 12:03 |
stephengwills |
I assume it’s a better practice to have one copy of a funtion and have it living in the schema my target version expects? |
| 12:03 |
stephengwills |
function* |
| 12:06 |
blongwel |
jeff:after getting a help ticket from one of our libraries I looked up some emails in patron records and tried a search on them. |
| 12:11 |
jeff |
blongwel: auditor.actor_usr_lifecycle could help determine if the email address value changed in any way, but if you're confident that the value before and after save was identical, it's possible that you have a corrupt index on that column. have you tested at the database level with something like SELECT id, email FROM actor.usr WHERE deleted = false AND lowercase(email) = |
| 12:11 |
jeff |
lowercase('someaddress example.org');? |
| 12:11 |
jeff |
(sorry, that split across messages) |
| 12:11 |
jeff |
a corrupt index would be worrisome unless you know what led to the corruption, but a REINDEX can fix it. |
| 12:11 |
jeff |
but I'd suggest confirming the symptoms before trying that. |
| 12:13 |
blongwel |
jeff: I will give that a try. Thanks for the assist |
| 12:13 |
jeff |
What does the index look like currently in the psql output of \d+ actor.usr |
| 12:14 |
jeff |
mine looks like: "actor_usr_email_idx" btree (lowercase(email)) |
| 12:15 |
stephengwills |
for search debug posterity: 1.6.1-2.0-upgrade-db.sql:CREATE OR REPLACE FUNCTION oils_json_to_text( TEXT ). looks like I’ve had this problem for a while. 2.12.6-3.0.0 upgrade still non specific. It looks like it becomes evergreen. explicit in 3.0. on it! |
| 12:15 |
jeff |
keep in mind that CREATE INDEX or REINDEX can lock writes to a table -- that may be unacceptable for you during operational hours. |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:17 |
jeff |
stephengwills: in many cases, we have created functions with a reliance on the first schema in the search path being "evergreen". We have then also relied on that when we reference the function. In some other cases, we've used an explicit reference when using but not when creating, or vice versa... |
| 12:24 |
|
sandbergja joined #evergreen |
| 12:25 |
jeff |
pg_dump/pg_restore (unless pg_dumpall) does not retain database settings such as search path, and pg_restore ignores or overrides search path in various ways. |
| 12:30 |
stephengwills |
so in psql, show search_path yields. $user, public. - since I log in as evergreen, that should be first, yes? |
| 12:30 |
blongwel |
jeff: select statement for actor.usr returns result list just fine |
| 12:31 |
jeff |
blongwel: okay, then you *probably* don't have a database-level issue such as a corrupt index. that's a bit of a relief. does a patron search by email address show the patron you searched for via psql? |
| 12:36 |
blongwel |
jeff: psql shows 3 records with that email address, xul and web client return none. |
| 12:37 |
jeff |
blongwel: for the XUL client, you should be able to see some possibly-helpful logs from the gateway containing the string open-ils.actor.patron.search.advanced |
| 12:38 |
bshum |
stephengwills: Yes, but if you're using the "postgres" user to perform the upgrade script, then it won't search_path right |
| 12:38 |
bshum |
In the past, we've told people to update their search path after database restores |
| 12:39 |
bshum |
Like: |
| 12:39 |
bshum |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 12:39 |
bshum |
(borrowing from the pinesol factoid) |
| 12:39 |
jeff |
blongwel: my arguments on a patron email search from the XUL client look something like this: {"email":{"value":"jqpublicexample.com","group":0},"profile":{"value":"","group":0}}, 51, ["family_name ASC","first_given_name ASC","second_given_name ASC","dob DESC"], 1, "1" |
| 12:39 |
jeff |
blongwel: being careful to remove any auth tokens or private email addresses, can you see if your search arguments contain something unexpected? |
| 12:40 |
stephengwills |
good stuff. thanks guys. Balsam will be joining the 3.x world during the holiday and can go back to sleep for another 5 years :) |
| 12:42 |
kmlussier |
stephengwills: Congrats! But maybe just two years next time? :) |
| 12:43 |
stephengwills |
LOL! oh ok…. As usual, it really depends on the generosity of strangers, of course. |
| 12:43 |
* stephengwills |
starts baking pies like crazy |
| 12:43 |
kmlussier |
stephengwills: What release were you on previously? |
| 12:43 |
* kmlussier |
can't back pies until tonight or maybe tomorrow morning. |
| 12:44 |
kmlussier |
s/back/bake |
| 12:44 |
stephengwills |
I’m moving from 2.8.3 to 3.1.7 on my test bed. |
| 12:44 |
jeff |
impressive. beats our 2.10 -> 3.1 jump back in September. |
| 12:44 |
kmlussier |
Wow! That's a lot of fun new features packaged in there. |
| 12:45 |
bshum |
stephengwills: When you go through the motions |
| 12:45 |
bshum |
I'll be curious if you snag on https://bugs.launchpad.net/evergreen/+bug/1772028 |
| 12:45 |
pinesol |
Launchpad bug 1772028 in Evergreen "Missing db functions in 3.0.1-3.0.2 upgrade script" [High,Confirmed] |
| 12:45 |
stephengwills |
I’m excited about it. |
| 12:46 |
jeff |
stephengwills: if you plan on running the xul client for a time after the upgrade and if you make use of copy alerts you may want to look back in irc logs to see some discussion regarding delaying some of the copy alert matrix database updates until you're off xul. |
| 12:46 |
bshum |
I was reviewing the bug, and I was going to cross it off my list since 3.0 is dead to me, but I guess there are still folks out there who have to upgrade past it eventually :) |
| 12:47 |
* bshum |
goes back to try enjoying his lunch |
| 12:48 |
stephengwills |
I’ll look for that in my next pass at the scripts. I am creating my own repairs for the stuff that got tucked into public instead of evergreen after my last upgrade |
| 14:08 |
kmlussier |
@quote random |
| 14:08 |
pinesol |
kmlussier: Quote #5: "<senator> the armenian regression sounds like a spy novel" (added by bshum at 03:44 PM, February 22, 2011) |
| 14:39 |
|
bdljohn joined #evergreen |
| 14:39 |
|
gsams_ joined #evergreen |
| 14:58 |
|
bdljohn joined #evergreen |
| 15:18 |
rjackson_isl |
new update to an old ticket (hopefully in the right ticket): https://bugs.launchpad.net/evergreen/+bug/1529969/comments/3 |
| 15:18 |
pinesol |
Launchpad bug 1529969 in Evergreen "double-scan during check-in still troublesome" [Undecided,New] |
| 15:33 |
|
stephengwills left #evergreen |
| 15:57 |
kmlussier |
mmorgan: I'm confused. I thought the Retarget All Statuses modifier covered those non-holdable statuses. Am I misremembering? |
| 16:00 |
mmorgan |
It's been a while since I tested this, but for an item in a non-holdable status, the first checkin would clear the status, possibly the retargeting would happen in the background, but the item was non-holdable, so it wouldn't capture. The second checkin would capture. |
| 16:01 |
* mmorgan |
should re-confirm that with a current test |
| 16:04 |
kmlussier |
OK, if that's the case, then that bug can probably be set to Incomplete. I'll add a comment. |
| 16:05 |
kmlussier |
I don't think I understand what the use case is for retargeting all statuses if it's not there to capture those items that were not in the hold copy map. |
| 16:07 |
jeff |
without "retarget all statuses", it only attempts to retarget copies that had a pre-checkin status of "In Process". |
| 16:07 |
jeff |
# Specifically target items that are likely new (by status ID) |
| 16:07 |
jeff |
return unless $status->id == OILS_COPY_STATUS_IN_PROCESS || $self->retarget_mode =~ m/\.all/; |
| 16:09 |
kmlussier |
Yes, I knew In Process was the only status handled by the first one. I guess I always just assumed that new items would always be in that In Process status. :) |
| 16:09 |
* kmlussier |
should never assume. |
| 16:09 |
mmorgan |
That issue where it takes 2 checkins with the modifiers on to capture a hold on an item in a non-holdable status is a main reason why we have set many of our statuses as holdable. |
| 16:09 |
|
stephengwills joined #evergreen |
| 16:10 |
jeff |
my $status = $U->copy_status($self->copy->status); |
| 16:10 |
jeff |
return unless $U->is_true($status->holdable); # Current status not holdable means no hold will ever target the item |
| 16:10 |
* mmorgan |
just confirmed that it takes 2 checkins with the "Retarget..." modifiers turned on to capture a hold for an item that was initially in a non-holdable status. |
| 16:11 |
jeff |
you could probably make a case for skipping that status check, maybe conditionally based on a setting or the "retarget all statuses" bit. |
| 16:12 |
jeff |
some of the other checks that are done in that code are checking things that don't change as a result of checkin. status does change, and the label DOES say "retarget all statuses..." |
| 16:13 |
jeff |
there's also a skip in there for precats, but i think that might need to change now also. |
| 16:13 |
kmlussier |
Why do you think the behavior for precats should change? |
| 16:14 |
jeff |
they're holdable now, iirc. |
| 16:15 |
jeff |
as of commit a1c8c3a |
| 16:15 |
pinesol |
jeff: [evergreen|Bill Erickson] LP#1308239 Support pre-cat copy hold targeting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a1c8c3a> |
| 16:15 |
jeff |
and at least one other commit, bug 1308239 |
| 16:15 |
pinesol |
Launchpad bug 1308239 in Evergreen "Support targeting and fulfillment of precat copy holds (for ILL)" [Wishlist,Fix released] https://launchpad.net/bugs/1308239 |
| 16:16 |
kmlussier |
Ah, yes. Very useful for our NCIP integration. |
| 16:16 |
jeff |
i'm not sure if some other aspect of hold_type = 'C' will make retargeting at checkin pointless for pre-cat ILL holds, though. |
| 16:17 |
jeff |
kmlussier: yes, I'm very much looking forward to making time to re-factor things so that we don't create a temporary bib for every NCIP hold request here. |
| 16:19 |
mmorgan |
So, do others find it problematic that two checkins need to happen to get an item in a non-holdable status to capture a hold, even when the Retarget modifiers are turned on? |
| 16:21 |
kmlussier |
mmorgan: I can think of at least one other Evergreen consortium that would probably like that check in modifier to capture items in a non-holdable status. |
| 16:21 |
kmlussier |
Presumably, when you check in an item, you are putting it into a holdable status. |
| 16:23 |
jeff |
i think when "retarget all statuses" is checked it should not skip retargeting when the pre-checkin status is non-holdable. |
| 16:23 |
kmlussier |
I would +1 a Wishlist bug on that. Despite my lame duck status. :) |
| 16:24 |
mmorgan |
I would agree with jeff, but that still would not help when checking in items in a non-holdable status without the Retarget... modifiers on. |
| 16:26 |
mmorgan |
For example, Missing is a non-holdable status. A vanilla checkin of a missing item attached to a bib with holds would not capture. |
| 16:26 |
mmorgan |
The item would go to Reshelving, so would go back to the shelf. |
| 16:26 |
kmlussier |
mmorgan: No, I think it could help, but I know a few people would would like the system to automatically handles those items. |
| 16:28 |
mmorgan |
I certainly think it could help some, but likely not enough to make us change our mind about the holdability of our statuses. |
| 16:30 |
mmorgan |
It would be great if the Retarget checkin modifiers were not necessary. |
| 16:38 |
jeff |
i would support further investigation of that. |
| 16:40 |
mmorgan |
jeff: bug 1686463 |
| 16:40 |
pinesol |
Launchpad bug 1686463 in Evergreen "Wishlist: Background targeting of holds when items are edited into a holdable state" [Wishlist,Confirmed] https://launchpad.net/bugs/1686463 |
| 16:40 |
jeff |
we'd probably still need to be careful not to affect checkin performance, especially in larger environments on popular items, etc. |
| 16:40 |
mmorgan |
Yes, indeed. |
| 16:41 |
jonadab |
So on checkin, put it into a queue to be checked as time allows. |
| 16:41 |
jeff |
well, no. |
| 16:42 |
* kmlussier |
wanders off to buy pie ingredients. |
| 16:42 |
jeff |
ideally there'd be no need to re-checkin. |
| 16:42 |
jeff |
the subject of that older bug is slightly different from current conversation. |
| 16:43 |
jeff |
but it's probably the best summary of issues all in one place that we have. |
| 16:43 |
jeff |
though not ALL issues, of course... |
| 16:44 |
jeff |
mmorgan++ bug finding |
| 17:03 |
mmorgan |
Happy Thanksgiving #evergreen! |
| 17:03 |
|
mmorgan left #evergreen |
| 17:09 |
|
gsams_ joined #evergreen |
| 17:28 |
|
dbwells joined #evergreen |
| 17:57 |
Bmagic |
Happy Thanksgiving! Gnight all - see you after we get back from Disney World December 3rd! |
| 18:01 |
berick |
go to Harry Potter world for all us, Bmagic |
| 18:27 |
|
nfburton joined #evergreen |
| 18:33 |
nfburton |
I have enabled the au.created action trigger but it doesn't seem to even be creating a trigger. Do I need to do something else other than enable it from stock? |
| 19:10 |
|
nfburton joined #evergreen |
| 21:59 |
|
rlefaive joined #evergreen |
