| Time |
Nick |
Message |
| 03:44 |
|
jaswinder joined #evergreen |
| 04:38 |
|
beanjammin joined #evergreen |
| 06:31 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:35 |
|
rlefaive joined #evergreen |
| 08:41 |
|
rlefaive joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:56 |
csharp |
after a recent re-install of master on my testing server, I'm seeing several instances of this issue: https://stackoverflow.com/questions/41281515/possibly-unhandled-rejection-in-angular-1-6 and things like the "Item Status" view aren't loading |
| 08:57 |
csharp |
since I don't hear anyone else talking about it, I'm wondering if it's just me, but my test server is kind of dead in the water until I resolve this |
| 08:57 |
csharp |
from the symptoms, it looks like issues common to upgrading to angular 1.6 |
| 09:01 |
csharp |
hmm - normally I wouldn't celebrate something like this, but I just hit a white screen - hooray! |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:06 |
|
rlefaive_ joined #evergreen |
| 09:06 |
JBoyer |
csharp, Maybe we'll have to start pinning Angular versions to get semi-stable installations? :/ |
| 09:07 |
JBoyer |
Doesn't help you today, unfortunately, but it seems safer than having an install work today and break today + 1.v |
| 09:09 |
|
tlittle joined #evergreen |
| 09:10 |
JBoyer |
Although now that I look at it I think we already do. (we're using 1.6.7, possibly higher?) |
| 09:13 |
|
rlefaive joined #evergreen |
| 09:29 |
|
yboston joined #evergreen |
| 09:35 |
Dyrcona |
I think pinning versions might be more important with Angular than it is with AngularJS. |
| 09:37 |
|
jaswinder joined #evergreen |
| 09:40 |
|
lsach joined #evergreen |
| 09:42 |
|
rlefaive joined #evergreen |
| 09:47 |
|
rlefaive joined #evergreen |
| 09:51 |
|
jvwoolf joined #evergreen |
| 10:01 |
|
Christineb joined #evergreen |
| 10:04 |
|
dkyle1 joined #evergreen |
| 10:12 |
Dyrcona |
So, I'm trying to make a custom view to summarize how much a patron owes by organization unit. |
| 10:13 |
JBoyer |
That last bit must be fun. |
| 10:13 |
jeff |
heh. i don't remember if it will be possible without mmpbbt, which is likely in need of some more attention before it can go into 3.2. |
| 10:13 |
Dyrcona |
JBoyer: Yeah.... |
| 10:13 |
jeff |
(see what I did there?) |
| 10:14 |
Dyrcona |
jeff: I think it's possible. The trick is assigning lost fees to the library that owns the copy. |
| 10:15 |
|
jvwoolf1 joined #evergreen |
| 10:15 |
Dyrcona |
Kind of a merge of money.open_usr_summary and money.billable_xact_summary_location_view. |
| 10:16 |
JBoyer |
One of the things I've had in the back of my mind re: overhauling money.* was assigning a priority and context to billing reasons. (priority for "these bills have to be paid first, like collections fees; and contexts for who the billing ou: item or transaction) |
| 10:17 |
jeff |
i don't think we have a concept here of "these need to be paid first" |
| 10:20 |
Dyrcona |
Well, when I rewrote billing, it would pay larger bills first, assuming those were more "important." I haven't looked to see if dbwells kept that feature. |
| 10:20 |
JBoyer |
Some libraries that use collection agencies like to apply payments to those bills first since they're being billed for the services for that patron. It's not strictly necessary, but I can see the point. |
| 10:21 |
jeff |
JBoyer: Not sure I follow the logic as you described it. |
| 10:22 |
jeff |
Dyrcona: thanks for reminding me, that's on my list of things that need my attention as I try to determine if we're able to use stock billing code after our upgrade. |
| 10:23 |
jeff |
(attributing payments out of order was something that did not at all mesh with how we wanted to do things) |
| 10:23 |
Dyrcona |
What JBoyer said makes sense to me. |
| 10:23 |
JBoyer |
Overdue fines are a punitive things applied to late transactions and don't represent an actual expense or anything, but lost bills are more important because now you have to replace an item, and collection fees are an actual expense already paid by the library to begin collection services against the user. |
| 10:23 |
JBoyer |
So first you pay back the ~$10 we've spent on you, then you pay back the book(s) you lost, then we'll get to the quarters. |
| 10:23 |
jeff |
JBoyer: is the idea that you're more likely to forgive one than the other? |
| 10:24 |
JBoyer |
That's also possible. |
| 10:24 |
JBoyer |
Legally speaking it's really easy to write off overdues, it's a lot more work to waive lost fees, etc. |
| 10:24 |
mmorgan |
Paying off lost billings first will also affect patron penalties. |
| 10:24 |
jeff |
Interesting. I'll ask some questions here. |
| 10:25 |
JBoyer |
(Legally speaking in IN, obviously. ymmv.) |
| 10:25 |
* jeff |
nods |
| 10:25 |
mmorgan |
If libraries block for lost items, it makes sense to resolve the lost fees first. |
| 10:30 |
|
jaswinder joined #evergreen |
| 10:42 |
|
rlefaive joined #evergreen |
| 11:19 |
Dyrcona |
JBoyer | jeff: Turns out to be easy enough for my purposes: https://pastebin.com/per3f5QY |
| 11:24 |
JBoyer |
Dyrcona, that looks like that may be pretty handy. I was thinking about the last time someone asked about incoming payments for overdue vs lost which I absolutely hated. |
| 11:43 |
csharp |
JBoyer: I can confirm that your FF branch works fine (using web-ext) on my Fedora workstation - planning to test Windows in a VM next |
| 11:44 |
JBoyer |
Woo. |
| 11:44 |
JBoyer |
I can also toss out some anecdata that Hatch works fine with Java 10 since I forgot I had it installed on my laptop while fighting with this. |
| 11:45 |
csharp |
good |
| 11:54 |
JBoyer |
A quick FYI about Chrome and this version of the Hatch extension. Firefox doesn't complain about the unknown 'minimum_chrome_version' key, but in dev mode Chrome shows a warning about the unknown 'applications' key. So long as it doesn't cause a problem when uploaded to the web store it should be no problem, it worked fine for me otherwise. |
| 11:55 |
JBoyer |
(And I think the ERRORS link only appears in dev mode, even though it's only a warning.) |
| 11:59 |
JBoyer |
berick, you may be interested in the above if you're the one that uploads the next version of the Chrome extension. |
| 12:00 |
|
mmorgan1 joined #evergreen |
| 12:02 |
|
jaswinder joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:03 |
berick |
JBoyer: noted, thanks |
| 12:14 |
|
abowling joined #evergreen |
| 12:28 |
|
khuckins joined #evergreen |
| 12:30 |
|
yboston joined #evergreen |
| 12:35 |
|
rlefaive joined #evergreen |
| 12:38 |
|
kmlussier joined #evergreen |
| 12:40 |
|
jaswinder joined #evergreen |
| 12:46 |
|
mmorgan joined #evergreen |
| 14:16 |
|
yboston_ joined #evergreen |
| 14:17 |
|
gsams__ joined #evergreen |
| 14:36 |
pinesol_green |
[evergreen|Jane Sandberg] LP1766712: Add Scrollbar to Patron Search Permission Group Field - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=06fda6a> |
| 14:54 |
|
tlittle joined #evergreen |
| 15:38 |
|
mmorgan1 joined #evergreen |
| 16:02 |
pinesol_green |
[evergreen|Bill Erickson] LP#1740537 Transit dialog showing wrong branch - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0b3b42b> |
| 16:08 |
|
jaswinder joined #evergreen |
| 16:14 |
|
jaswinder joined #evergreen |
| 16:15 |
|
mmorgan joined #evergreen |
| 16:17 |
|
jaswinder joined #evergreen |
| 16:55 |
|
yboston joined #evergreen |
| 17:06 |
|
Dyrcona joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:39 |
|
abowling left #evergreen |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:42 |
|
gsams__ joined #evergreen |
| 18:52 |
|
akilsdonk_ joined #evergreen |
| 19:59 |
|
JBoyer-alt joined #evergreen |
| 21:12 |
|
jvwoolf joined #evergreen |
| 23:33 |
|
randomacc1257[m] joined #evergreen |
| 23:38 |
|
clopez360 joined #evergreen |
