| Time |
Nick |
Message |
| 03:55 |
|
dbwells_ joined #evergreen |
| 05:18 |
|
sseng_ joined #evergreen |
| 05:18 |
|
fparks_ joined #evergreen |
| 05:18 |
|
ktomita joined #evergreen |
| 06:43 |
|
kbeswick joined #evergreen |
| 07:04 |
|
timlaptop joined #evergreen |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 08:08 |
|
Dyrcona joined #evergreen |
| 08:11 |
csharp |
@later tell hopkinsju you can also use "lib_ips.txt", which allows you to set start/end ranges for library IPs and Evergreen will set physical_loc for your libraries automatically - let me know if you want assistance with setting that up |
| 08:11 |
pinesol_green |
csharp: The operation succeeded. |
| 08:12 |
csharp |
okay so after like 2 years, one of our libraries has starting using standing penalties to apply blocks/alerts/messages on patron accounts, and we've run into something that I'm having trouble sorting... |
| 08:13 |
csharp |
I read the docs (Evergreen In Action FTW!) about the "org_depth" setting for each standing penalty |
| 08:14 |
csharp |
and I set them all to "0" (consortium), but previously applied blocks aren't showing up |
| 08:14 |
csharp |
so as our administrative user, I'm able to create a consortium-level block that's visible everywhere |
| 08:15 |
csharp |
but as a system local administrator, it only creates the block at the branch level and I don't see a way to change that |
| 08:15 |
phasefx2 |
you set the depth on the config table? what about the actor map table? |
| 08:17 |
|
mrpeters joined #evergreen |
| 08:17 |
|
depesz left #evergreen |
| 08:21 |
csharp |
lemme look |
| 08:22 |
|
Shae joined #evergreen |
| 08:23 |
csharp |
phasefx2: I don't see a depth setting on actor.usr_standing_penalty (assuming that's the table you meant ;-) ) |
| 08:23 |
csharp |
I see org_unit |
| 08:25 |
csharp |
the "visible everywhere" block is set at the "PINES" (consortium) level |
| 08:26 |
csharp |
that is to say, the org_unit is PINES |
| 08:28 |
berick |
csharp: thinking of config.standing_penalty.org_depth ? |
| 08:28 |
|
akilsdonk joined #evergreen |
| 08:28 |
csharp |
berick: yeah - that's what I set to 0, but I'm wondering if that's doing something different than I'm assuming |
| 08:29 |
csharp |
my starting assumption was that it would make all penalties of that type visible/applicable everywhere |
| 08:29 |
eeevil |
csharp: at least in master, a manually applied penalty gets the session's ws_ou |
| 08:29 |
csharp |
but the interface apparently works from the ws ou and only displays blocks from there or "higher" |
| 08:30 |
csharp |
my goal is to make any penalty applied anywhere to be applied/visible everywhere |
| 08:30 |
berick |
that's the exact point of org_depth |
| 08:30 |
berick |
it may be that some types of penalties ignore it, though |
| 08:31 |
berick |
i.e. it might only work for automagic penalties (max fines, etc.) |
| 08:32 |
eeevil |
csharp: you're just talking about the penalty display in the patron summary, right? |
| 08:32 |
csharp |
eeevil: right |
| 08:33 |
eeevil |
berick: blocking penalties, at least, don't care about the id, just the block_list and actor.org_unit_descendants(ausp.org_unit, csp.org_depth) |
| 08:33 |
csharp |
so if the org_unit on the penalty is Branch1 it would never be visible from Branch2 |
| 08:34 |
berick |
open-ils.actor.user.penalty.apply sets the value of ausp.org_unit by inspecting ws_ou and csp.org_depth. |
| 08:34 |
csharp |
that makes it sound like it would work then - lemme test some more |
| 08:35 |
berick |
so it should be possible to apply a penalty at BR 1 that is ulatimately a CONS (or SYS1) penalty (i.e. ausp.org_unit == 1 or 2) |
| 08:35 |
|
kbeswick joined #evergreen |
| 08:35 |
csharp |
berick: right - that's my goal |
| 08:35 |
csharp |
I'd like all penalties to be visible anywhere |
| 08:39 |
csharp |
okay - that does work |
| 08:39 |
csharp |
whew! |
| 08:39 |
csharp |
berick: eeevil: phasefx2: thanks for your help! |
| 08:39 |
berick |
csharp: glad it's working. |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:59 |
|
ericar joined #evergreen |
| 09:26 |
|
ningalls joined #evergreen |
| 09:59 |
jboyer-isl |
Maybe someone can help me come to grips with the hold matrix matchpoints. Lets say I want to restrict a profile to placing holds only at their home OU. could that be done this way: |
| 09:59 |
|
yboston joined #evergreen |
| 10:00 |
jboyer-isl |
just a usr_grp of the profile, and holdable=false |
| 10:00 |
jboyer-isl |
then the usr_grp of the profile, item_ou and user_home_ou set to the same ou, and holdable=true? |
| 10:03 |
jboyer-isl |
I guess the question really is, the line with the most matching fields is the winner? (sort of like CSS specificity?) |
| 10:04 |
tsbere |
jboyer-isl: The fields are weighted. Some "mean" more than others. |
| 10:05 |
jboyer-isl |
So the line that has the highest weighted score is chosen, even though it may have fewer matching fields? |
| 10:05 |
tsbere |
jboyer-isl: For example, the requestor's group (the person placing the hold, not the person the hold is for) by default trumps everything else, followed by the user's group, then a combination of the OUs... |
| 10:07 |
Dyrcona |
jboyer-isl: Without getting into too many details, yes, what you want to do would work. |
| 10:07 |
Dyrcona |
What tsbere is trying to warn you about is if you have any rules with the requestor_grp set then they might interact badly with your changes. |
| 10:08 |
Dyrcona |
We have Local Use Only patron groups and we set them up as you described. |
| 10:08 |
Dyrcona |
We also do not use the requestor_grp field, because we never care who places the hold, just who the hold is for. |
| 10:09 |
jboyer-isl |
Dyrcona: That's the way we see it too, caring about who places the hold only causes confusion. |
| 10:10 |
jboyer-isl |
Thanks for the explanations you two. |
| 10:10 |
Dyrcona |
You can adjust the weights in config.hold_matrix_weights, but we use the defaults. |
| 10:11 |
jboyer-isl |
I'll probably review them so there aren't any surprises, but I'm hoping to stick to the defaults also. |
| 10:11 |
Dyrcona |
jboyer-isl: One other thing, we usually the pickup_ou to the user's home_ou as well. |
| 10:11 |
|
mllewellyn joined #evergreen |
| 10:11 |
Dyrcona |
So, we set item_circ_ou, user_home_ou, pickup_ou to the user's home ou, user_grp to Local Use Only (in our case) and holdable true. |
| 10:12 |
Dyrcona |
There's a consortium holdable false for Local Use Only. |
| 10:12 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.5: Fix floating groups heading level - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d1de196> |
| 10:12 |
Dyrcona |
We also have to make exceptions for any non-holdable circ_modifiers, because setting the holdable true would usually override that. |
| 10:13 |
jboyer-isl |
Dyrcona: Good to know. That's very similar to how our scripts used to work. |
| 10:14 |
Dyrcona |
It's kind of funny, because the majority of entries in our hold_matrix_matchpoint set the holdable false for specific circ_modifiers for local use only patrons at their home ou. |
| 10:15 |
jboyer-isl |
So they can only place holds at their home_ou's but not on everything? |
| 10:16 |
Dyrcona |
jboyer-isl: Right. Some circ_modifiers do not allow holds at all. |
| 10:16 |
Dyrcona |
Trouble is when you set all of the ous with the usr group and say true for holdable, that outweighs the circ_modifier with false. |
| 10:16 |
Dyrcona |
So you make exceptions to keep the rules in line with expectations. |
| 10:17 |
jboyer-isl |
Oh, I see. The Local Use Only lines permitting their holds were overriding the generic "no holds on these circ_mods" lines? |
| 10:17 |
Dyrcona |
Yes. |
| 10:17 |
Dyrcona |
You could adjust that by making the circ_modifier have the highest weight, probably. |
| 10:18 |
Dyrcona |
tsbere wrote the code. I just manipulate the data. :) |
| 10:19 |
jboyer-isl |
Well, this should certainly keep our testers busy anyway. :) |
| 10:19 |
jboyer-isl |
tsbere++ |
| 10:19 |
tsbere |
Note that if you make circ mod first then circ mods can override "this patron type can't place holds..." type entries ;) |
| 10:19 |
jboyer-isl |
Dyrcona++ |
| 10:20 |
tsbere |
jboyer-isl: Oh, and if you want it to act in a "the more you fill out..." state set the weight association to "All Equal" - Then the more fields filled out the higher the rule will be. |
| 10:20 |
Dyrcona |
Yeah, the real problem is trying to cram analog logic into a binary system. |
| 10:21 |
jboyer-isl |
tsbere: That sounds like the way to go. It shouldn't be too many more rules for our situation, but you would be able to tell at a glance what rule will be used for each situation. |
| 10:22 |
tsbere |
jboyer-isl: Don't be too sure of that. Things get iffy when multiple rows match with the same number of filled in fields that way... |
| 10:22 |
|
Sha`Bren left #evergreen |
| 10:22 |
tsbere |
jboyer-isl: Say you have a rule that matches marc type, and another that matches circ mod. The first says not holdable, the second says holdable. Otherwise identical, both match the hold. Which one wins? |
| 10:22 |
eeevil |
jboyer-isl: what tsbere just said. provide differing weights for (generally) mutually exclusive fields |
| 10:23 |
jboyer-isl |
Oh, yeah. I guess there's nothing stopping us from defining 2 rules that have 3 matches each, on different fields. That's no good. |
| 10:23 |
csharp |
we hit the marc_type vs circ_modifier issue before... |
| 10:23 |
eeevil |
it's good when you have a set of fields that are used in well-known combinations, just be careful :) |
| 10:24 |
mrpeters |
jboyer-isl: i dont think you guys are using any hold rules based on marc type though, at least you weren't when i left |
| 10:24 |
mrpeters |
all the rules were based on circ mod |
| 10:25 |
jboyer-isl |
mrpeters: Nope, everything is circ_mod and *_ou. But similar situations could come up with other fields I suppose. |
| 10:26 |
mrpeters |
perhaps |
| 10:28 |
Dyrcona |
we use marc_type and use circ_modifier as modifiers to the general rules, but we're crazy. :) |
| 10:28 |
tsbere |
mrpeters: If they switch to "everything is equal" then "this group says no" and "this circ mod says yes" but otherwise equal would be a toss-up as to which one applies... |
| 10:29 |
mrpeters |
i see |
| 10:29 |
mrpeters |
fun stuff, wish i could be more involved |
| 10:29 |
* tsbere |
notes that it isn't *really* a toss-up due to other factors, such as the "final determinator if otherwise identical is ID order in the table" |
| 10:29 |
Dyrcona |
tsbere is working on switching us to a system where the circ_modifier names encode the rules that they represent, to make it easier for library staff to understand what their circ rules actually are. |
| 10:31 |
* Dyrcona |
gets kind of tired for the "we want it simple, except we don't" dance. |
| 10:31 |
jboyer-isl |
"Everything checks out for 2 weeks." "Everything?" "Well, everything but X, Y, Z, things in this location, that Item ...." |
| 10:32 |
Dyrcona |
Exactly! |
| 10:32 |
Dyrcona |
And that's just the easy stuff. |
| 10:33 |
bshum |
RDA-- |
| 10:33 |
tsbere |
jboyer-isl: and by the time the exceptions are done "everything" has become "1% of the collection" ;) |
| 10:34 |
jboyer-isl |
This shelf! Everything on this shelf checks out for 2 weeks! The rest of it, consult the crystal ball. |
| 10:35 |
Dyrcona |
Magic Meatball sez...... Ask again later. |
| 10:35 |
tsbere |
jboyer-isl: But what if the tea leaves disagree with the crystal ball? ;) |
| 10:35 |
mrpeters |
just be glad you have consortial policies, jboyer-isl |
| 10:35 |
mrpeters |
and not per library |
| 10:35 |
Dyrcona |
Hey! We have both! |
| 10:36 |
mrpeters |
i pity you |
| 10:36 |
Dyrcona |
tsbere: Then it's time for the chicken guts. |
| 10:36 |
Dyrcona |
I should have gotten into something simple like neurosurgery. |
| 10:36 |
* Dyrcona |
is NOT joking. |
| 10:36 |
jboyer-isl |
Sisyphus thinks that shit is a lost cause. |
| 10:37 |
Dyrcona |
Yes, it often is sisyphean. |
| 10:42 |
csharp |
yeah - you end up with something where 95% of your configuration efforts are to address the 5% of actual occurrences of those exceptions |
| 10:42 |
csharp |
probably less |
| 10:43 |
csharp |
@praise pulling percentages from thin air |
| 10:43 |
* pinesol_green |
pulling percentages from thin air is the very model of a modern major hacker |
| 10:43 |
Dyrcona |
I know. Then they blather on about "serving the patron" when they want to be able to override all or their self-imposed exceptions. |
| 10:44 |
Dyrcona |
I feel like just removing the rules and saying, "Deal with it at the circ. desk." |
| 10:45 |
tsbere |
I love when they say "we need to be able to X to serve the patron!" where X is basically "don't serve a different patron while serving the one standing in front of you" >_> |
| 10:45 |
|
collum joined #evergreen |
| 10:46 |
paxed |
seems like the gauntlet has been thrown down. i need to fix bug 1089767 in the next 3 weeks for our project. |
| 10:46 |
pinesol_green |
Launchpad bug 1089767 in Evergreen "Add Parent/Guardian Field to Patron Summary Record" (affected: 2, heat: 10) [Low,Triaged] https://launchpad.net/bugs/1089767 |
| 10:47 |
Dyrcona |
paxed: That would have been nice for my recent migration. Their old system had that field. |
| 10:48 |
paxed |
Dyrcona: indeed. this is something we need by law - minors shall not get collection letters, for example. |
| 10:49 |
Dyrcona |
paxed: That's probably a law here, but who knows what the law is in the US of A? |
| 10:50 |
paxed |
finns often compare russia to a wonderland (in a negative sense) where anything is possible. i guess it's similar ... :P |
| 10:51 |
Dyrcona |
It's getting that way here. Anything is possible, if you have deep pockets. |
| 10:54 |
bshum |
Well this is just weird.... so with pubinfo, I'm seeing something weird happen where the search results page doesn't show the pubinfo value (even though the bib has the proper 264 RDA tag for publication data) while the record details itself shows the pubinfo variable just fine. |
| 10:56 |
bshum |
Oh interesting. |
| 10:56 |
eeevil |
bshum: IIRC, those interfaces get their data from different sources, and different helpers chop up the records in different ways |
| 10:56 |
bshum |
The record summary uses the full breakdown of pubplace, publisher, pubdate as separate variables. |
| 10:56 |
* Dyrcona |
is not surprised. |
| 10:57 |
bshum |
Results gets a single mashed pubinfo variable |
| 10:57 |
bshum |
That apparently is broken |
| 11:04 |
jeff |
for parent/guardian, we add a patron note (non-blocking, but alerting) called a "Confidentiality Note". We populate it with the name of the individual or individuals who are authorized to be given information about that account. In the majority of the cases, this is parent/guardian/etc. |
| 11:06 |
bshum |
dbs: The graphic_880s for args.pubinfos in misc_util.tt2 breaks on RDA bibs. I think it's target_field towards 260 is what's causing it to mangle the pubinfo data block and prevent it from showing up in search results. |
| 11:06 |
jboyer-isl |
jeff, paxed: I think we've used ID2 in the past. I don't know if there's anything special set up so that collections companies will ignore user's with that set, but it's a possibility. |
| 11:06 |
bshum |
Removing that graphic_880s lookup for pubinfo fixes the search results display of pubinfo for RDA bibs, but then it breaks facets of course. :D |
| 11:07 |
jeff |
jboyer-isl: in our case, since patron DoB is delivered in collections calls, letters for collections for patrons under 18 years of age are addressed to "Parent/Guardian of" |
| 11:07 |
bshum |
I'll file an LP bug |
| 11:08 |
jeff |
jboyer-isl: I suspect that is similar for all libraries using UMS in most/all US states. |
| 11:08 |
paxed |
jboyer-isl: the collection company (or whatever) shouldn't even get the information that it's a minor - the parent is the one who's getting the collection letter. |
| 11:08 |
jboyer-isl |
jeff: that's probably true. |
| 11:09 |
jboyer-isl |
paxed: so you mean the company should only see the parent's information, not even the name of the actual account holds? |
| 11:09 |
jboyer-isl |
er, holder? |
| 11:09 |
jeff |
And there's a difference between the company that we contract with who gets the details on what is owed for what by whom, and the credit reporting agencies that they work with after some time has passed if there is no patron response. My understanding is that no collection reporting is done for minor accounts -- I don't think it goes to the parent, since that data is not provided. |
| 11:10 |
jeff |
(let me know if that truncated before "not provided." |
| 11:10 |
paxed |
jboyer-isl: the library won't even send the minor's info out. |
| 11:10 |
jboyer-isl |
paxed: I see. |
| 11:10 |
jboyer-isl |
jeff: it all came through/ |
| 11:10 |
jeff |
thanks. |
| 11:11 |
paxed |
the idea is that anything the minor has to pay, is actually paid by his guardian. this is one way to prevent parents abusing their kid's accounts. |
| 11:11 |
* jeff |
nods |
| 11:11 |
jeff |
that's how we operate also. |
| 11:12 |
jeff |
when opening a new account the parent/guardian is informed that they are responsible for return of the material in good condition, etc. |
| 11:12 |
paxed |
yup |
| 11:13 |
jeff |
https://tadl.org/newuser has the wording that we currently use |
| 11:14 |
paxed |
also, the linkage between minor and guardian should be automatically unlinked when the minor is no longer minor. |
| 11:14 |
* jeff |
nods |
| 11:15 |
paxed |
(although that needs a override, in case the guardian is not because of age, but for some other reason the patron cannot take care of his or her things) |
| 11:16 |
paxed |
i guess i shold put all this up on the bug... |
| 11:16 |
jeff |
and that's where it gets tricky. :-) |
| 11:16 |
jeff |
there is existing logic (in a scheduled script) to remove Juvenile status on patrons who have met the age criteria. |
| 11:20 |
dbs |
bshum: haven't read scrollback yet, but it doesn't surprise me that something RDA-ish would break |
| 11:20 |
bshum |
dbs: Yeah, darn RDA |
| 11:21 |
bshum |
RDA-- again |
| 11:21 |
bshum |
I just filed https://bugs.launchpad.net/evergreen/+bug/1243746 |
| 11:21 |
pinesol_green |
Launchpad bug 1243746 in Evergreen "TPAC search results don't display RDA 264 publisher info" (affected: 1, heat: 6) [Undecided,New] |
| 11:21 |
bshum |
I think we're going to need to add some more protection to prevent 260 vs. 264 issues from bringing further pain upon us. |
| 11:33 |
bshum |
I could see splitting up 260 and 264 into separate pubinfo variables and leaving the 880 check for only the 260 one. But then the question is which displays if both happened to exist. |
| 11:45 |
|
smyers_ joined #evergreen |
| 11:48 |
|
kitteh_ joined #evergreen |
| 12:05 |
|
kmlussier joined #evergreen |
| 12:58 |
|
kbutler joined #evergreen |
| 13:08 |
|
kbeswick_ joined #evergreen |
| 13:31 |
|
smyers__ joined #evergreen |
| 14:01 |
|
dMiller joined #evergreen |
| 14:11 |
|
stevenyvr2 joined #evergreen |
| 14:23 |
Dyrcona |
kmlussier: I loaded depesz's ranked_volumes function on my development system. |
| 14:27 |
pinesol_green |
[evergreen|Remington Steed] Serials Docs: Improve format, fix typos, and update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ca588fe> |
| 14:27 |
pinesol_green |
[evergreen|Remington Steed] Serials Docs: Update for new features in 2.5 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1dead5d> |
| 14:34 |
|
collum joined #evergreen |
| 14:34 |
kmlussier |
Dyrcona++ |
| 14:37 |
|
smyers_ joined #evergreen |
| 14:49 |
|
dMiller joined #evergreen |
| 14:52 |
|
blake joined #evergreen |
| 14:54 |
|
qwebirc69238 joined #evergreen |
| 14:58 |
|
Dyrcona joined #evergreen |
| 15:44 |
|
mrpeters joined #evergreen |
| 16:14 |
jboyer-isl |
A quick global flags Q if anyone still on knows: When the global flag "Holds: When testing hold matrix matchpoints, use the profile group of the receiving user instead of that of the requestor (affects staff-placed holds)" is enabled, |
| 16:17 |
jboyer-isl |
Does that mean it compares the user that will receive the hold against the requestor permission group column of the holds matrix, instead of the user permission group? |
| 16:22 |
jboyer-isl |
Ah, nevermind. I went looking for the test and found it. It does. |
| 16:28 |
* Dyrcona |
was about to say that is what it does. |
| 16:42 |
|
ktomita joined #evergreen |
| 16:43 |
|
gsams joined #evergreen |
| 16:44 |
|
Dyrcona joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 21:37 |
|
mrpeters joined #evergreen |
| 21:49 |
|
kbeswick joined #evergreen |
| 22:16 |
|
mrpeters left #evergreen |
