| Time |
Nick |
Message |
| 00:12 |
|
sandbergja joined #evergreen |
| 00:28 |
|
jvwoolf joined #evergreen |
| 01:01 |
|
jvwoolf joined #evergreen |
| 01:32 |
|
dbwells joined #evergreen |
| 01:33 |
|
jvwoolf joined #evergreen |
| 03:34 |
|
dbwells joined #evergreen |
| 04:30 |
|
dbwells joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:56 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl_hom joined #evergreen |
| 07:12 |
dickreckard |
hello all.. i have a question regarding the open-ils.search.biblio.marc method.. |
| 07:12 |
dickreckard |
it seems to expect a second parameter (a string) after the hashref which would describe the marc search |
| 07:13 |
dickreckard |
but i dont really understand how it works i think. i manage to use simpler opensrf methods, when they only require a few strings as params, but have difficulties with this one |
| 07:20 |
|
dbwells joined #evergreen |
| 07:30 |
|
dbwells joined #evergreen |
| 07:32 |
JBoyer |
Hi dickreckard, I don't know off hand how to call that, but it looks like there's some fairly helpful documentation in the comments in the file where the function is defined. Check out Evergreen/Open-ILS/src/perlmods/lib/OpenILS/Application/Search/Biblio.pm around line 2063. There's an example of the type of params it needs also. |
| 07:55 |
|
sandbergja joined #evergreen |
| 07:55 |
|
Dyrcona joined #evergreen |
| 08:02 |
dickreckard |
thanks JBoyer! I tried to craft a hashref that way but still get this error:Status: *** Call to [open-ils.search.biblio.marc] failed for session [1595851329.370991.159585132940286], thread trace [1]: |
| 08:02 |
dickreckard |
Can't locate object method "content" via package "OpenSRF::DomainObject::oilsMethodException" at /usr/local/share/perl/5.24.1/OpenILS/Application/Search/Biblio.pm line 2148. |
| 08:03 |
dickreckard |
from srfsh I get the same error |
| 08:03 |
dickreckard |
as from the osrf-gateway |
| 08:15 |
JBoyer |
That seems like an odd error, are other calls working normally? And if so, how many keys in the arghash are you sending? You might try sending the smallest thing you can, possibly adding keys if it doesn't work. |
| 08:19 |
JBoyer |
I haven't used it myself, you may need to look around in the OPAC code where it's used, I *think* it's used for the MARC Advanced search. |
| 08:23 |
dickreckard |
yes I'm trying to search by one internal marc tag (930) |
| 08:24 |
dickreckard |
but maybe it would be better to setup a facet using that marc tag and then search via that rather than the marc advanced search |
| 08:24 |
dickreckard |
the other calls are working normally, and the marc advanced search works properly in the opac interface |
| 08:25 |
|
mantis1 joined #evergreen |
| 08:26 |
dickreckard |
i tried requesting {"searches":{"term":"harry","restrict":{"tag":930}}} , which would seem the minimum necessary but i still get the same error |
| 08:29 |
|
mmorgan joined #evergreen |
| 09:02 |
|
alynn26 joined #evergreen |
| 09:25 |
|
mantis1 left #evergreen |
| 09:34 |
|
dbwells joined #evergreen |
| 09:53 |
|
jvwoolf joined #evergreen |
| 09:56 |
|
jvwoolf1 joined #evergreen |
| 09:57 |
gmcharlt |
dickreckard: {"searches":[{"term":"harry","restrict":[{"tag":"245","subfield":"a"}]}]} |
| 09:58 |
gmcharlt |
i.e., a couple keys are expecting lists as their contents |
| 10:00 |
gmcharlt |
and tags >= 010 require a subfield parameter |
| 10:00 |
gmcharlt |
although you can use "_" as its value if you want to search any subfield in that field |
| 10:02 |
|
jvwoolf1 left #evergreen |
| 10:17 |
* gmcharlt |
claims 1210 |
| 10:20 |
pinesol |
[evergreen|Chris Sharp] LP1248734: Add workstation to in-house use - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=53faf16> |
| 10:20 |
pinesol |
[evergreen|Jane Sandberg] LP1248734: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c9b7c69> |
| 10:20 |
pinesol |
[evergreen|Galen Charlton] LP#1248734: (follow-up) add new indexes to schema update script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ebbdca4> |
| 10:20 |
pinesol |
[evergreen|Galen Charlton] LP#1248734: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=70c3cbe> |
| 10:25 |
Dyrcona |
rhamby++ # For mentioning the Github repo for the migration tools |
| 10:26 |
Dyrcona |
I started looking at the script for removing org_unit data again since there have been updates to the code in the past few months. We have a situation that the circ removal doesn't cover. |
| 10:26 |
rhamby |
thanks. yeah, the main motivation was that we're putting more koha tools in there and it makes more sense for koha users but I think it'll be advantegous for some evergreen folk too |
| 10:26 |
Dyrcona |
We have circulations originally checked out at the ou_to_del that were renewed elsewhere. |
| 10:26 |
rhamby |
dyrcona yeah, definitely submit a pull request, I updated them recently for one I did but of course I only update for the situations I run into |
| 10:27 |
Dyrcona |
I also have a set of changes to make them more convenient to run. I'll possibly submit that as a separate pull request. |
| 10:28 |
rhamby |
sounds good |
| 10:28 |
Dyrcona |
In the case of the renewals at a different lib, should we delete them or null out the parent_circ? |
| 10:28 |
rhamby |
IMO I'd null out the parent circ, I don't like the idea of removing potential stats for a library |
| 10:29 |
|
jvwoolf joined #evergreen |
| 10:29 |
rhamby |
though to some degree stats are a bit wonky after an org removal, but least disturbance viable and all that |
| 10:29 |
Dyrcona |
Ok. That's the way I was leaning. |
| 10:30 |
Dyrcona |
Yeah, we're losing some stats regardless, but if you wait a few years after a member leaves, things shouldn't be too bad. |
| 10:30 |
Dyrcona |
Until that one library asks for all their stats for the last ten years. :) |
| 10:30 |
* rhamby |
goes to hide under my desk |
| 10:30 |
Dyrcona |
heh. |
| 10:31 |
rhamby |
I once spent an hour on the phone with a director explaining why the same report two days apart gave slightly different numbers. |
| 10:31 |
agoben |
Depends on the report. |
| 10:32 |
rhamby |
yeah, in this case it was fines and circs and there were a lot of variables at play; we could have been at it for days |
| 10:32 |
rhamby |
and the difference was on the magnitude of .01% difference |
| 10:32 |
agoben |
I've had reports that should have given consistent numbers, but don't. |
| 10:33 |
rhamby |
there's always a rational reason even if it's hard to find |
| 10:33 |
agoben |
Yeah, both of those areas are volatile and prone to change. |
| 10:33 |
rhamby |
"how could circ numbers go up after the fact" answer was: offline circs |
| 10:33 |
agoben |
Yeah, "rational" might be a bit much to call it. |
| 10:34 |
rhamby |
I'm trying to be an optimist, work with me it's not easy |
| 10:34 |
agoben |
Not with reports, anyway :) |
| 10:34 |
Dyrcona |
I just tell them the reports use imaginary numbers. :) |
| 10:39 |
agoben |
(<.<) (>.>) ....yeah, just the good stats... (<.<) (>.>) |
| 10:39 |
csharp |
idea that just occurred to me without thinking too much about it: create a stats schema that doesn't care about anything live or archived |
| 10:41 |
Dyrcona |
Well, we could actually calculate stats and store them, then they won't change later when things are deleted/updated. Is that what you mean, csharp? |
| 10:44 |
Dyrcona |
rhamby: The update works for me. I got the old circs to delete and the others look like new checkouts. I'll refrain from adding additional updates, because I don't need them, yet. (I'm testing with a library that left CWMARS to join MVLC about 8 years ago.) |
| 10:45 |
rhamby |
Dyrcona: coolness |
| 10:45 |
|
jvwoolf1 joined #evergreen |
| 10:46 |
|
nfBurton joined #evergreen |
| 10:51 |
csharp |
Dyrcona: yeah - some place that's independent, probably controlled by triggers for circ/holds/transits, etc. |
| 10:52 |
csharp |
it's what we do for our Executive Reports feature in PINES - except those are SQL run outside of EG to populate stats tables - less integrated |
| 10:52 |
jeff |
This goes back to "all circs should start as aged circs" idea. |
| 10:52 |
csharp |
jeff: yeah - that's in line with what I'm thinking about |
| 10:52 |
* gmcharlt |
claims 1211 |
| 10:53 |
* csharp |
challenges gmcharlt's claim to 1211 |
| 10:54 |
gmcharlt |
csharp: oh, preparing a merge now? |
| 10:54 |
csharp |
gmcharlt: no - joking :-) |
| 10:54 |
gmcharlt |
ah, OK :) |
| 10:54 |
* csharp |
is defeated by gmcharlt |
| 11:00 |
pinesol |
[evergreen|Jason Stephenson] Lp 1802166: Purge User Preferred Names - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2e86369> |
| 11:00 |
pinesol |
[evergreen|Jason Stephenson] Lp 1802166: Purge User Name Keywords - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6628319> |
| 11:00 |
pinesol |
[evergreen|Galen Charlton] LP#1802166: (follow-up) document a way to clear names from already-purged patron records - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f3bdc3d> |
| 11:00 |
pinesol |
[evergreen|Galen Charlton] LP#1802166: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa91def> |
| 11:02 |
Dyrcona |
:) |
| 11:05 |
Dyrcona |
ERROR: schema "esi" does not exist |
| 11:08 |
Dyrcona |
So, it looks like :vol_del_table can't be temporary because both 08_remove_volumes.sql and all of the 09_remove_bibs_stage[1-3].sql scripts use it.... |
| 11:09 |
Dyrcona |
So, I'll a create schema if not exists? |
| 11:09 |
Dyrcona |
missing a verb, there. It should be "add a create schema...." |
| 11:09 |
Dyrcona |
rhamby^^ |
| 11:10 |
rhamby |
Dyrcona: yeah, we kind of assumed esi but I'm not opposed to a create schema of CREATE SCHEMA remove_foo |
| 11:10 |
rhamby |
and then adding it to the path |
| 11:10 |
rhamby |
assuming not everyone wants an 'esi' schema on their dbs :) |
| 11:14 |
Dyrcona |
Well, I was thinking of adding a 20_cleanup.sql that could drop the schema, so maybe a special remove_ou schema would be better. |
| 11:15 |
gmcharlt |
or schemas, given the potential for churn over the years |
| 11:15 |
Dyrcona |
Is there any reason to keep the data around after the deletion is complete? |
| 11:16 |
rhamby |
yeah, the churn was what I was thinking of, I don't have to do this very often but but it could happen to have multiple on the same box |
| 11:16 |
rhamby |
probably not, the data itself is gone, the main reason I can think of for differentiating them is a very special case where multiple org removals were happening parallel |
| 11:16 |
gmcharlt |
:vol_del_table probably has a very short life-span -- basically long enough for final review before one starts tossing out database snapshots |
| 11:17 |
Dyrcona |
Also, 18_delete_usrs_stage_2.sql seems to be missing. Was it obsolete and deleted? (I haven't checked the log too closely, yet.) |
| 11:17 |
gmcharlt |
though i could image wanting to store additional aggregrated data for stats |
| 11:17 |
gmcharlt |
Dyrcona: stage_1 generates stage_2 |
| 11:18 |
rhamby |
right, to serially delete because the batch delete takes a very long time and (in my experience) is the stage mostly likely to find excpetions that need cleanup |
| 11:18 |
Dyrcona |
Oh, all right. I haven't gotten that far, yet, but now that you mention it, I remember that from last time I tried. |
| 11:18 |
rhamby |
faster to get rid of the bulk that don't have issues |
| 11:19 |
Dyrcona |
Yeah, storing aggregated stats goes along with the reports discussion from earlier. tsbere and I talked about it briefly several years ago, but never made any progress. |
| 11:19 |
Dyrcona |
Other things came up. |
| 11:19 |
rhamby |
it's another one of those "it would be nice .... when we have time" things |
| 11:19 |
Dyrcona |
Yeahp. |
| 11:20 |
Dyrcona |
So, I think I'll just add a esi schema to my database and we can figure out something more automatic later if necessary. |
| 11:20 |
Dyrcona |
my test database that is. |
| 11:23 |
Dyrcona |
I have 9 org units that I can remove, though we might keep one. krvmga used to use it for testing things. Not sure if anyone else does. |
| 11:27 |
Dyrcona |
csharp++ # For list migration work. |
| 11:34 |
jeff |
printers-- |
| 11:39 |
Dyrcona |
printing-- |
| 11:39 |
Dyrcona |
printers-- |
| 11:40 |
mmorgan |
Save the trees! |
| 11:40 |
Dyrcona |
jeff: Anything in particular this time or just the general printing issues? |
| 11:41 |
Dyrcona |
Some of these deletes run for a long time. |
| 11:43 |
Dyrcona |
And, I missed an org. unit earlier. I have 10 systems that I could delete, and at least one has two branches. |
| 11:43 |
* Dyrcona |
decides it is close enough for lunch. |
| 11:49 |
dickreckard |
gmcharlt: thanks. tried with the lists, too, but it seems to require a second variable.. |
| 11:50 |
dickreckard |
srfsh# request open-ils.search open-ils.search.biblio.marc {"searches":[{"term":"debord","restrict":[{"tag":"245","subfield":"_"}]}]} |
| 11:50 |
dickreckard |
this fails with the same error |
| 11:50 |
dickreckard |
srfsh# request open-ils.search open-ils.search.biblio.marc {"searches":[{"term":"debord","restrict":[{"tag":"245","subfield":"_"}]}]} "uhm" |
| 11:51 |
dickreckard |
this does not give error but gives back 0 results |
| 11:51 |
gmcharlt |
hmm, works for me with open-ils.search.biblio.marc.staff |
| 11:52 |
gmcharlt |
lemme check quickly regarding plain old open-ils.search.biblio.marc |
| 11:53 |
gmcharlt |
ah, in that case it also wants an org_unit param, e.g., |
| 11:53 |
gmcharlt |
{"searches":[{"term":"harry","restrict":[{"tag":"245","subfield":"_"}]}],"org_unit":1} |
| 11:55 |
dickreckard |
gmcharlt: great! thanks a lot! :) |
| 11:55 |
dickreckard |
gmcharlt++ |
| 11:55 |
dickreckard |
it was missing the org unit indeed |
| 12:01 |
|
jihpringle joined #evergreen |
| 12:03 |
|
sandbergja joined #evergreen |
| 12:05 |
|
nfBurton joined #evergreen |
| 12:07 |
jeff |
> -When using Terminal Service and Remote Desktop, interactive communication becomes unavailable between the PC and the printer, prohibiting displaying the printer status and obtaining printer information using the Status API. |
| 12:08 |
|
mrisher joined #evergreen |
| 12:09 |
|
mrisher joined #evergreen |
| 12:51 |
|
rfrasur joined #evergreen |
| 12:59 |
pinesol |
[evergreen|Bill Erickson] LP1878079 Staffcat Add Call Nums honors selected orgs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4231540> |
| 12:59 |
pinesol |
[evergreen|Bill Erickson] LP1878079 Staffcat 'Edit' items / call numbers support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=caa1460> |
| 12:59 |
pinesol |
[evergreen|Bill Erickson] LP1878079 Staffcat Add Holdings action support - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1528c22> |
| 13:28 |
Dyrcona |
Whee! This one had a lot of asset.call_number entries, over 660,000. Probably because of URIs. |
| 13:45 |
|
khuckins joined #evergreen |
| 14:18 |
|
jihpringle joined #evergreen |
| 14:58 |
|
jihpringle joined #evergreen |
| 14:58 |
jeff |
varying shelf expire time for different items looks like something we may do. |
| 14:59 |
jeff |
getting away from placing conditionals in A/T templates for certain items that only wait on the shelf for two days, etc... just have the shelf_expire_time be set to the actual value right off the bat. |
| 15:00 |
jeff |
though some may still have some templated "BEFORE 10:30 AM on the day" :-P |
| 15:03 |
Dyrcona |
jeff: How are you thinking of configuring that? |
| 15:06 |
|
nfBurton joined #evergreen |
| 15:12 |
jeff |
Dyrcona: maybe a config table. OU setting establishes the default, then the shortest or most specific of (ou setting), (config match on circ modifier), (config match on shelving location) determines. |
| 15:13 |
jeff |
I'm not sure if it belongs in hold policy or as its own matchpoint/matrix. |
| 15:13 |
jeff |
Similar-but-different thoughts with reshelving interval. |
| 15:13 |
jeff |
(making a way for them to vary based on some item level attributes like circ mod / copy location) |
| 15:17 |
Dyrcona |
Yeah. I was thinking a new config table at least. I'm not sure about matchpoints either. |
| 15:21 |
* Dyrcona |
wonders if this bib delete is ever going to finish. :) |
| 15:25 |
Dyrcona |
rhamby++ # I'll have another pull request later. I want to see if any of our other libraries trip up any special circumstances. |
| 15:25 |
rhamby |
Drycrona: np, thanks for the pull request |
| 15:34 |
sandbergja |
Does anybody have an amazing COVID-19 way to make changes to circ policies that you intend to revert when this is all over? My specific interest: our books usually checkout for 3 weeks. I'm thinking of setting them to term-long checkouts for the next few terms (long duration rule + hard due date). And then, when the college is back to more typical operations, switch it back to 3 weeks. What's the tidiest way to do that ( |
| 15:34 |
sandbergja |
aka the way least likely to totally confuse me several terms from now)? |
| 15:52 |
Dyrcona |
sandbergja: I would suggest copying the current policies to tables in a special schema so that you can easily put them back later. We have a custom schema named cwmars that we use for things like that and a few custom functions, etc. |
| 15:53 |
Dyrcona |
As for not confusing yourself, the best thing that I can think of keeping a document around explaining what you did and why you did it. Also, doing this sort of thing with SQL helps because you can also write an undo script at the same time. |
| 15:53 |
sandbergja |
Oh, I like that! |
| 15:53 |
sandbergja |
Dyrcona++ |
| 15:59 |
jvwoolf1 |
sandbergja: I wrote some SQL that would update the description field to whatever the original policies were, then used that to write the undo script. That helped me quickly identify what had been changed, too. |
| 15:59 |
jvwoolf1 |
We only have had libraries altering their fine rules at this point, though |
| 16:00 |
sandbergja |
jvwoolf1: that sounds pretty slick! |
| 16:58 |
gmcharlt |
sandbergja: what jvwoolf1 and Dyrcona suggested is probably easier to deal with, but there's one more approach I can think off: create an auditor table for the relevant policy tables |
| 16:59 |
gmcharlt |
e.g., select auditor.create_auditor('config', 'circ_matrix_matchpoint'); |
| 16:59 |
gmcharlt |
and repeat as needed before making other changes |
| 17:00 |
gmcharlt |
on the plus side: with effort, being able to track the exact state of the policies in the past |
| 17:01 |
gmcharlt |
on the minus side, it does create a maintenance task: needing to run auditor.update_auditors() after changes to the structure of the policy tables |
| 17:02 |
gmcharlt |
also on the minus side: auditor tables don't inherently record the intent of the change |
| 17:24 |
|
mmorgan left #evergreen |
| 17:39 |
|
sandbergja joined #evergreen |
| 17:39 |
|
jvwoolf1 left #evergreen |
| 17:44 |
|
mrisher_ joined #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:09 |
|
abowling1 joined #evergreen |
| 19:25 |
|
abowling joined #evergreen |
