| Time |
Nick |
Message |
| 00:54 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:03 |
|
JBoyer joined #evergreen |
| 07:14 |
|
agoben joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 08:01 |
dbs |
Not sure anyone mentioned it, but iOS 11.3 (available a few days ago: https://www.apple.com/ca/newsroom/2018/03/ios-11-3-is-available-today/) added PWA support to Safari, including Service Workers |
| 08:02 |
dbs |
further info on the PWA support at https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7 |
| 08:02 |
dbs |
so the iPad users will need to test and see if it improves their experience |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
collum joined #evergreen |
| 08:44 |
|
dbwells joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 09:10 |
|
jvwoolf joined #evergreen |
| 09:23 |
|
yboston joined #evergreen |
| 09:38 |
|
kmlussier joined #evergreen |
| 09:53 |
|
jonadab joined #evergreen |
| 10:30 |
|
mmorgan joined #evergreen |
| 11:07 |
|
jvwoolf1 joined #evergreen |
| 11:10 |
|
bos20k joined #evergreen |
| 11:26 |
|
beanjammin joined #evergreen |
| 11:27 |
|
rlefaive joined #evergreen |
| 11:35 |
|
rlefaive joined #evergreen |
| 11:49 |
|
gsams joined #evergreen |
| 12:14 |
|
yboston joined #evergreen |
| 12:15 |
|
khuckins joined #evergreen |
| 12:21 |
|
mmorgan joined #evergreen |
| 12:57 |
Bmagic |
Quiet. A little to quiet.... |
| 12:58 |
berick |
careful what you ask for |
| 12:58 |
Bmagic |
Don't get me wrong, not asking for anything |
| 13:00 |
mmorgan |
Don't get us started ;-) |
| 13:00 |
berick |
was about to ask about index normalizers, but I should probably not do that on an empty stomach. |
| 13:02 |
Bmagic |
good call |
| 13:31 |
|
Jaswinder joined #evergreen |
| 14:22 |
Dyrcona |
JBoyer: Lp 1760662 sounds like a duplicate of Lp 1743801 |
| 14:22 |
pinesol_green |
Launchpad bug 1760662 in Evergreen 3.1 "Item Status Detail View: Holdable field displays OPAC Visible value" [Undecided,New] https://launchpad.net/bugs/1760662 |
| 14:22 |
pinesol_green |
Launchpad bug 1743801 in Evergreen "web client: item status list view display issues" [High,Confirmed] https://launchpad.net/bugs/1743801 |
| 14:28 |
JBoyer |
Ah, that it is, in general and specifically comment 2. :/ |
| 14:30 |
JBoyer |
Dyrcona, if you're not too deep into that bug I could try to include a couple more fixes. |
| 14:30 |
JBoyer |
Though there is some benefit to individual bugs, as I can't tell which of those are still issues and which aren't without some sleuthing. |
| 14:37 |
|
tlittle joined #evergreen |
| 14:40 |
Dyrcona |
JBoyer: Don't worry about it. That other bug was described to me on an internal list as being more like your bug. |
| 14:40 |
|
tlittle left #evergreen |
| 14:41 |
Dyrcona |
Plus, a lot of it is supposedly resolved on Lp 1738249. At least, we'll find out this afternoon/tomorrow morning. :) |
| 14:41 |
pinesol_green |
Launchpad bug 1738249 in Evergreen "Circulation Library in Item Status" [Low,Confirmed] https://launchpad.net/bugs/1738249 |
| 15:08 |
|
yboston joined #evergreen |
| 15:24 |
|
khuckins joined #evergreen |
| 15:38 |
JBoyer |
Dyrcona++ |
| 15:41 |
|
kmlussier joined #evergreen |
| 15:42 |
|
beanjammin joined #evergreen |
| 15:47 |
Dyrcona |
Jboyer: It's weird. It doesn't seem to quite work for me. |
| 15:48 |
JBoyer |
It being my patch? |
| 15:49 |
Dyrcona |
Yes. I'm still getting holdable false for a copy with opac visible false. |
| 15:50 |
Dyrcona |
I deliberately picked copies with opposite values. |
| 15:50 |
Dyrcona |
The one with opac_visible true, holdable false, comes up correct. |
| 15:50 |
JBoyer |
Did you force chrome to dump cache and reload the page? It's extremely irritating how sticky our JS is. |
| 15:50 |
Dyrcona |
I did. |
| 15:50 |
JBoyer |
Hmm. |
| 15:51 |
Dyrcona |
And, I didin't look these copies up before applying your patch anyway. |
| 15:51 |
Dyrcona |
I have looked at the eg_template_cace, and it seemed to have the correct template. |
| 15:52 |
Dyrcona |
I deleted that template anyway, cleared my browser cache for the last hour, and tried again. |
| 15:52 |
Dyrcona |
Let me clear all of my cache. |
| 15:52 |
JBoyer |
You don't have to do that exactly; |
| 15:53 |
JBoyer |
if you have the dev tools open you can right-click the Refresh button to do a clear cache and hard reload, which should only clear the cache for things referenced on that page |
| 15:53 |
Dyrcona |
Yeah, but still no good. Something else must be going on. |
| 15:53 |
JBoyer |
Bah. Will poke further. |
| 15:56 |
JBoyer |
Well that's infuriating. I have no idea how that's even possible at present. |
| 15:56 |
Dyrcona |
Yeah, me neither. |
| 15:57 |
Dyrcona |
The installed template looks right, the cached template looks right, the result in the browser looks wrong. |
| 15:58 |
Dyrcona |
There's a deleted copy with the same barcode with both fields true, but that can't be the problem. |
| 15:59 |
JBoyer |
But only for the visible false, holdable true case, right? For me they display correctly when it's holdable false visible true. (almost worse, really) |
| 16:00 |
Dyrcona |
Yes, that second case displays correctly. |
| 16:01 |
JBoyer |
Now I wonder if anything is being "helpful" re: background knowledge of how the hold targeter works. |
| 16:04 |
Dyrcona |
Hm... I just looked up one that is true on both fields, and it still comes back holdable false. |
| 16:04 |
|
kmlussier joined #evergreen |
| 16:05 |
JBoyer |
So if Holdable is *always* false it could mean the bool filter is hiding a bigger mistake by transforming it into a bool value of false instead of just blowing up. |
| 16:07 |
JBoyer |
Sigh. Looks that way. when both are true, holdable is still false on display. :/ Right place, wrong change. (Not sure what it should be though.) |
| 16:08 |
Dyrcona |
Fixed it! |
| 16:08 |
Dyrcona |
Get rid of the boolText filter. |
| 16:10 |
Dyrcona |
JBoyer: You want me to make the change in a follow up commit, or would you rather fix it in your branch? |
| 16:10 |
JBoyer |
Oops. Yeah, that's not used on ref() or opac_visible() or anything else in t_summary_pane. |
| 16:11 |
JBoyer |
If don't mind doing a follow up and signoff you may as well get a little author credit in there. |
| 16:11 |
Dyrcona |
OK. Will do. |
| 16:13 |
JBoyer |
Ah, and now I understand. The bools on the item proper are changed to the text true and false at another point, so boolText is just for things like the location and circ bool values. since neither 'true' nor 'false |
| 16:13 |
JBoyer |
' are == 't' it's always false. |
| 16:13 |
|
kmlussier joined #evergreen |
| 16:15 |
JBoyer |
Dyrcona++ |
| 16:15 |
Dyrcona |
JBoyer++ |
| 16:15 |
* JBoyer |
can finally go home. |
| 16:18 |
Bmagic |
Need a sanity check for group thresholds. Does the logic first want the home library to match closer. Preferring that over permission group? If I have a patron who is an exact match for permission group but two steps away from the defined library. Would the system apply the group penalty rule at the system library one step away from the home library and permission group with one step away? |
| 16:19 |
Dyrcona |
I think line 618 of web/js/ui/default/staff/item/app.js was tripping up the filter. |
| 16:24 |
Dyrcona |
Ha! I really skewered the branch name. :) |
| 16:27 |
Dyrcona |
Anyway, time for me to head home, too. |
| 16:27 |
mmorgan |
Bmagic: Not sure I'm following your question exactly, but I think it depends on the org_depth of your penalty. |
| 16:30 |
Bmagic |
mmorgan: if the penalty definition is at the consortium level (two steps from the patron's home library) and the permission group is defined equal to the patron permission group. There is also a rule for the same penalty located at the system level (one step from the patron) but the permission group is also one step away from the patron.Will Evergreen prefer the consortium rule because it's exact on one of the two data points? |
| 16:39 |
mmorgan |
Ok, I understand the question now. Not sure I can help with the answer, though. |
| 16:39 |
Bmagic |
:) |
| 17:02 |
berick |
Bmagic: one thing to bear in mind is penalties are applied by context org unit (e.g. item was checked out at ABC) instead of home library. |
| 17:03 |
Bmagic |
in case the patron checks things out at more than one library? |
| 17:07 |
berick |
hm, sort of. penalties define policy for a branch (well, org unit) |
| 17:10 |
Bmagic |
I believe I understand. For the sake of example, in my scenario, let's assume that all of the items checked out were at the same branch. And the penalty is "PATRON_EXCEEDS_ITEM_CHECKOUT". |
| 17:12 |
|
mmorgan left #evergreen |
| 17:19 |
berick |
Bmagic: i'm fairly certain the system-level rule would apply, assuming the profile group on the system rule was equal to (not in the case) or a parent of the patron's profile group. |
| 17:19 |
berick |
looks like the code steps through the org units, searching up the profile tree at each step along the way |
| 17:23 |
Bmagic |
so it does prefer the "closeness" on the org unit tree over the permission group tree? |
| 17:25 |
berick |
yes. it starts at context org, tries all the groups, moves up to next parent org, tries all the groups, etc. etc. |
| 17:26 |
Bmagic |
berick++ |
| 17:27 |
Bmagic |
You have to admit that it's confusing |
| 17:38 |
|
abowling joined #evergreen |
| 18:04 |
|
abowling1 joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:56 |
|
beanjammin joined #evergreen |
| 21:57 |
|
jboyer-isl joined #evergreen |
| 22:49 |
|
jvwoolf joined #evergreen |
