| Time |
Nick |
Message |
| 00:04 |
|
sandbergja joined #evergreen |
| 00:39 |
|
pinesol` joined #evergreen |
| 00:40 |
|
egbuilder joined #evergreen |
| 00:40 |
|
miker joined #evergreen |
| 00:41 |
|
felicia joined #evergreen |
| 00:41 |
|
dbs joined #evergreen |
| 00:42 |
|
genpaku joined #evergreen |
| 00:42 |
|
jweston joined #evergreen |
| 06:57 |
|
agoben joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:05 |
|
Dyrcona left #evergreen |
| 08:05 |
|
Dyrcona joined #evergreen |
| 08:13 |
|
bos20k joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:47 |
mmorgan |
@coffee |
| 08:47 |
* pinesol |
brews and pours a cup of Ethiopia Sidamo Guji, and sends it sliding down the bar to mmorgan |
| 08:47 |
mmorgan |
@coffee [someone] |
| 08:47 |
* pinesol |
brews and pours a cup of Ethiopia Yirga Cheffe Koke Espresso, and sends it sliding down the bar to eady |
| 08:50 |
Dyrcona |
So, that error message I pasted yesterday corresponds with another case of the open-ils.storage listener dying while the fine generator is running in multisession mode. |
| 08:52 |
Dyrcona |
Looks like this: https://bugs.launchpad.net/evergreen/+bug/1206629/comments/2 |
| 08:52 |
pinesol |
Launchpad bug 1206629 in Evergreen "Fine Generator timeout is different in single/parallel modes" [Medium,Confirmed] |
| 08:54 |
Dyrcona |
Doesn't appear to be any bug filed for OpenSRF::MultiSession though past conversations with jeff and berick indicate that they suspect some kind of bug. Am I remembering correctly? |
| 08:54 |
Dyrcona |
I tried searching the IRC logs both on evergreen-ils.org and locally and didn't turn up much that was actually useful. |
| 09:01 |
|
aabbee joined #evergreen |
| 09:16 |
|
yboston joined #evergreen |
| 09:22 |
|
jvwoolf joined #evergreen |
| 09:28 |
abneiman |
sandbergja++ # docs generation |
| 09:36 |
|
tlittle joined #evergreen |
| 10:21 |
|
sandbergja joined #evergreen |
| 11:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:05 |
|
yboston joined #evergreen |
| 11:44 |
yboston |
sandbergja++ |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:05 |
|
khuckins joined #evergreen |
| 12:27 |
|
sandbergja joined #evergreen |
| 12:37 |
Bmagic |
I have to say, I've never understood why the permission tree works the way it does. Permissions assigned at groups further up the tree take precedence over those that are closer to where the staff are assigned. Opposite of CSS inheritance. Or maybe I don't understand it correctly |
| 12:42 |
jeff |
are you trying to deny perms (which isn't supported, iirc), or are you running into the issue of different depths for the same perm, and the one you want to take effect isn't? |
| 12:43 |
jeff |
(which is in one way another form of deny, but the other way... isn't.) |
| 12:49 |
mmorgan |
Permissions also can get mapped to users directly, which is a further complication. |
| 13:09 |
|
yboston joined #evergreen |
| 13:24 |
|
sandbergja joined #evergreen |
| 13:36 |
Dyrcona |
emerge-files++ |
| 13:38 |
Dyrcona |
@karma emerge-files |
| 13:38 |
pinesol |
Dyrcona: Karma for "emerge-files" has been increased 2 times and decreased 0 times for a total karma of 2. |
| 14:17 |
csharp |
perm groups that are "closer" to the actual user should trump ones above (e.g., Circ1 perms would take precedence over Staff or User) |
| 14:21 |
csharp |
incidentally, I created a script that shows the combined perms for a user: https://git.evergreen-ils.org/?p=contrib/pines.git;a=blob;f=perms/get_combined_perms_per_user.sh;h=0be38ea2b3e51a6b5803fd5b216e198c104e33ba;hb=HEAD |
| 14:22 |
csharp |
includes primary perm group, secondary perm groups, and user-assigned perms |
| 14:25 |
berick |
related the UI for bug #1823981 shows perms inherited from parent groups |
| 14:25 |
pinesol |
Launchpad bug 1823981 in Evergreen "Port Permission Group Admin Page to Angular" [Wishlist,New] https://launchpad.net/bugs/1823981 |
| 14:27 |
csharp |
berick: nice! |
| 14:32 |
jeff |
Bmagic: still curious what you're trying to do / running into regarding permission groups, if you have a change to give more details. |
| 14:33 |
Bmagic |
jeff: I would love it to work like CSS |
| 14:34 |
jeff |
I think this may be the first time I've heard someone express that wish. |
| 14:34 |
Bmagic |
define a permission at a higher level, then the same permission with more power at a lower level and it "wins" as it gets closer to the target permission group |
| 14:34 |
jeff |
what do you mean by "same permission with more power" |
| 14:35 |
Bmagic |
like you might have branch power for deleting copies but I can override that with system with a more specific permission group |
| 14:37 |
Dyrcona |
Bmagic: Why make it more complicated than it is? Configure your groups properly. |
| 14:37 |
jeff |
okay, so that sounds like "different depths for the same perm, and the one you want to take effect isn't" above. |
| 14:37 |
Bmagic |
csharp: really? I'm mistaken then. That's exactly the way I wanted it to work. LOL |
| 14:39 |
Dyrcona |
It sounds to me like what its really wanted is give a user different perms depending on where they're logged in. Is that it? |
| 14:39 |
Bmagic |
not the org unit where they are registered but rather the permission group assigned to their account |
| 14:40 |
Bmagic |
csharp says it works the way I want. I'm looking again |
| 14:55 |
Bmagic |
Sorry to be so needy today. We have a branch of a multi branch system that wants to go out on their own and become a single branch at a newly-created-system OU. No problem. Done that before. The catch is they still want holds to flow from the previous sibbling branches the same way. Including age protected things |
| 14:56 |
Bmagic |
The method I dreamt was to invent two new age protection rules (one for 3 months and one for 6 months) that specified the proximity of 4 instead of 2. Only issue is that would allow the whole consortium to get their holds filled. To mitigate that, I saw that we could specify the age protection rule on the hold policy and make a deny rule |
| 14:57 |
Dyrcona |
Just tell them, it doesn't work like that. |
| 14:57 |
Bmagic |
It seems that the hold matrix ignores that column as a matchpoint :( |
| 14:57 |
Dyrcona |
It's not part of the match rules, no. |
| 14:58 |
Bmagic |
so now I'm thinking of abandoning the hold policy approach and going with org_unit_proximity adustment approach. But it appears that the proximity adjustment is only consulted by the hold targeter and not the hold matrix |
| 14:58 |
Dyrcona |
Tell them "No." |
| 14:59 |
Bmagic |
So that is my question: am I right in my understanding? It's just plain not possible? |
| 14:59 |
Dyrcona |
Possible or not, it's insane. |
| 15:00 |
Bmagic |
not to them. The two systems are very closely related in terms of geographically, patron sharing, etc. But not fiscally and they each have their own board. At the end of the year, they pay eachother for patrons that use eachothers branch |
| 15:01 |
Dyrcona |
Then don't merge them. |
| 15:01 |
Dyrcona |
Leave them as-is. It's still insane. |
| 15:01 |
Bmagic |
And it's a real chore to exclude this one branch when it comes time to implement things like OPAC payments for the system (but not this one branch) and hold rules, circ rules, group policies. We are left with (instead of making a system rule) making 8 rules for each of the branches except for the one that is different |
| 15:03 |
Dyrcona |
Sounds like the hierarchy is wrong. |
| 15:03 |
Bmagic |
standard system->branch |
| 15:04 |
Dyrcona |
Not if the 1 branch needs to be excluded, it's not "standard." |
| 15:04 |
mmorgan |
Bmagic: Would proximity adjustments help? |
| 15:05 |
Dyrcona |
Needs to be by itself. |
| 15:07 |
|
yboston joined #evergreen |
| 15:07 |
mmorgan |
http://docs.evergreen-ils.org/3.2/_absolute_and_relative_adjustments.html |
| 15:08 |
Dyrcona |
Unless, I misunderstand your situation, which is quite likely. |
| 15:09 |
Bmagic |
mmorgan: that's what I was thinking but it doesn't seem that the hold permit test consults that. There are really two things: placing a hold, and targeting the hold. The hold targeter consults the proximity but not action.find_hold_matrix_matchpoint( |
| 15:09 |
csharp |
Bmagic: we have a situation that's marginally similar - two separate systems that share A/V item holds |
| 15:10 |
csharp |
they don't share age-protected things, though |
| 15:10 |
* csharp |
looks at the hold policies |
| 15:11 |
Dyrcona |
They're part of a consortium. Tell them to share or leave. :P |
| 15:11 |
Bmagic |
I'm just the monkey :) |
| 15:12 |
Dyrcona |
I know, and it's not my circus. :) |
| 15:12 |
* Bmagic |
reminded of Monty Python |
| 15:12 |
Dyrcona |
Most days it seems like it. :) |
| 15:12 |
csharp |
@decide evergreen or evergreeen |
| 15:12 |
pinesol |
csharp: go with evergreen |
| 15:13 |
mmorgan |
pinesol's no fun. |
| 15:13 |
Dyrcona |
I was thinking of a Polish expression: Not my circus; not my monkeys. |
| 15:13 |
Dyrcona |
In other words, not my problem. :) |
| 15:13 |
Bmagic |
@decide Life of Brian or Holy Grail |
| 15:13 |
pinesol |
Bmagic: go with Life of Brian |
| 15:14 |
Dyrcona |
@decide Meaning of Life or Life of Brian |
| 15:14 |
pinesol |
Dyrcona: go with Life of Brian |
| 15:14 |
Bmagic |
ha! |
| 15:14 |
Bmagic |
"Look on the bright side of life" |
| 15:14 |
Dyrcona |
@decide Fawlty Towers or A Fish Called Wanda |
| 15:14 |
pinesol |
Dyrcona: That's a tough one... |
| 15:15 |
csharp |
Bmagic: so my rules go off pickup library and owning library - if the pickup library is system A and the owning library is B and the circ modifier is one of an A/V type, then allow the hold |
| 15:15 |
csharp |
so yours might be something the same except for age protection rule rather than circ modifier |
| 15:15 |
csharp |
and you just flip A and B for each rule |
| 15:16 |
Bmagic |
csharp: right on. I did that and sadly I found out the hold matrix doesn't use the age protection rule as a matchpoint. It's totally ignored for purposes of rule finding |
| 15:16 |
csharp |
oh - hmm |
| 15:16 |
csharp |
I wonder why it's in the UI then? |
| 15:17 |
Bmagic |
I made two consortium deny rules for those special age protections. and then 2 rules for each system (total of 4 rules) to fill holds between them with items that have those special age protections |
| 15:17 |
Bmagic |
no dice. The logic didn't care at all |
| 15:18 |
Bmagic |
I believe it's all contained in this fuction: action.find_hold_matrix_matchpoint |
| 15:18 |
Bmagic |
that whole function never once metions the keyword "age_prot" |
| 15:19 |
Bmagic |
or age_* even |
| 15:19 |
csharp |
I was just looking at action.hold_request_permit_test - is that not the one? |
| 15:19 |
Bmagic |
that is the outter function that calls this one |
| 15:19 |
csharp |
oh - I see |
| 15:21 |
Bmagic |
Using config.hold_matrix_matchpoint.age_hold_protect_rule as a matchpoint seems like a reasonable request/wishlist improvement? |
| 15:22 |
Dyrcona |
Bmagic: But it won't do what you want, probably, unless you delete age_protect from items after it expires. |
| 15:23 |
Bmagic |
so, instead of that - I started barking up another tree: proximity adjustment. Which is likewise not consulted in this SQL code ( I don't think) |
| 15:23 |
Bmagic |
Dyrcona: good point. I had thought of that as well, and we do have a nightly script to scrub that off copies as they age off. |
| 15:23 |
Dyrcona |
Those things are meant to exclude items from filling holds, not from preventing holds from being placed. |
| 15:24 |
Dyrcona |
The matchpoint matrix is meant to see if a hold can be placed. |
| 15:25 |
Bmagic |
that's the conclusion I'm coming to as well. And if two systems wanted to share age protected stuff, it should permit the hold if all of the ducks were aligned |
| 15:25 |
Dyrcona |
Proximity adjustment is what you want because age hold protect rules have a proximity. |
| 15:25 |
Dyrcona |
Make them closer by using a smaller value. |
| 15:25 |
Bmagic |
yep! Exactly! |
| 15:26 |
csharp |
so this is why we tend to be pretty vague when libraries request unusual situations - we always tell them we'll have to test and make sure whatever they're asking works before they just assume it - we've had lots of those situations over the years |
| 15:26 |
Bmagic |
so, if the hold matrix brought that into the equation, we should be gold |
| 15:27 |
csharp |
and sometimes we can kill wild hare ideas with the dreaded "that would require development" |
| 15:27 |
csharp |
DUM DUM DUMMMM |
| 15:27 |
Dyrcona |
The hold matrix has nothing to do with items filling holds. |
| 15:27 |
Bmagic |
right :)=) |
| 15:28 |
Bmagic |
Dyrcona: right, but if they can't place a hold to begin with, then it's a non-starter |
| 15:28 |
Dyrcona |
I thought you were trying to let two distant branches share age protected items? |
| 15:29 |
Bmagic |
that's rightr |
| 15:29 |
Dyrcona |
So, change the matrix so that they can place holds on each other's things. |
| 15:29 |
* miker |
reads up, notes that the age protection on the matrix is not, indeed, used anywhere (it's a dead field, once considered to be the new home of that, rather than the copy, but did not happen for the reasons Dyrcona says: matrix is about "can hold exist", not "can THIS copy fill a hold") |
| 15:29 |
mmorgan |
Regarding the age protection rule in the hold matrix, somewhere I saw/heard/read that the hold rule *applies* the age protection rather than *consults* the age protection |
| 15:29 |
|
khuckins joined #evergreen |
| 15:30 |
csharp |
so many knobs and switches on those policies |
| 15:30 |
csharp |
and they aren't super intuitive |
| 15:30 |
csharp |
I have to read the SQL any time I need to know what they actually do :-/ |
| 15:31 |
Bmagic |
Dycona: I think I see what you are saying. As-is, the code can do it presicly *because* the hold matrix doesn't consult the age protection! I'm seeing a light |
| 15:31 |
Bmagic |
presicly/precisely |
| 15:33 |
csharp |
we also try to squash any "I want to leave but I want to stay" kinds of conversations - if they leave, they are a separate system with all the implications that includes |
| 15:33 |
csharp |
but sounds like that ship has sailed :-) |
| 15:34 |
Bmagic |
csharp: haha |
| 15:35 |
mmorgan |
So the matrix decides if a hold can exist, does the targeter consult the matrix? I feel like I should know this... |
| 15:35 |
csharp |
mmorgan: no, it doesn't |
| 15:35 |
csharp |
the matrix is like a bouncer at the door |
| 15:36 |
csharp |
@eightball do we all live in the matrix? |
| 15:36 |
pinesol |
csharp: No clue. |
| 15:36 |
Bmagic |
I believe this will work the way they want it to with proximity adjustments and two easy hold rules to allow the holds to eachother |
| 15:36 |
mmorgan |
Hmm. Does capture consult the matrix? |
| 15:37 |
Dyrcona |
Capture uses the copy lists gathered by the targeter. |
| 15:38 |
Dyrcona |
If the copy's not listed for a hold, it won't fill it. |
| 15:38 |
mmorgan |
So targeter fills the hold_copy_map, but it doesn't consult the matrix when it does that? |
| 15:40 |
Dyrcona |
I'd have to look at the code again to be sure. |
| 15:45 |
mmorgan |
If the hold gets by the bouncer at the door, something else must be checking the matrix during targeting or capturing. |
| 15:47 |
Dyrcona |
I believe it does, but I'd have to look and don't have time right now. |
| 15:48 |
mmorgan |
No worries! |
| 15:59 |
* Dyrcona |
has too many git branches.... |
| 16:23 |
|
jvwoolf left #evergreen |
| 16:25 |
berick |
Dyrcona got me wondering.. we're up to 6336 working branches |
| 16:25 |
Bmagic |
daaaaang |
| 16:57 |
|
khuckins joined #evergreen |
| 17:07 |
|
jihpringle joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:30 |
|
cmalm joined #evergreen |
| 17:36 |
* gmcharlt |
claims 1173 in the name of templates everywhere! |
| 17:40 |
pinesol |
Showing latest 5 of 8 commits to Evergreen... |
| 17:40 |
pinesol |
[evergreen|Bill Erickson] LP1825851 Server managed/processed print templates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d372c6c> |
| 17:40 |
pinesol |
[evergreen|Bill Erickson] LP1825851 Server print templates Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9468c79> |
| 17:40 |
pinesol |
[evergreen|Bill Erickson] LP1825851 Print template failure warnings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=339b462> |
| 17:40 |
pinesol |
[evergreen|Bill Erickson] LP1825851 Print template admin misc. repairs/improvements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3372aa2> |
| 17:40 |
berick |
gmcharlt++ |
| 17:41 |
pinesol |
[evergreen|Galen Charlton] LP#1825851: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c24940> |
| 17:42 |
pinesol |
[evergreen|Mike Risher] lp1836808 add cancel button to merge edit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c7d8b25> |
| 17:42 |
pinesol |
[evergreen|Galen Charlton] LP#1836808: add release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5e43045> |
| 17:51 |
|
sandbergja joined #evergreen |
| 17:58 |
|
jihpringle joined #evergreen |
| 18:48 |
|
sandbergja joined #evergreen |
| 19:48 |
|
cmalm joined #evergreen |
| 19:59 |
|
sandbergja joined #evergreen |
| 21:44 |
|
sandbergja joined #evergreen |
| 23:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
