| Time |
Nick |
Message |
| 07:56 |
|
kworstell-isl joined #evergreen |
| 08:02 |
|
BDorsey joined #evergreen |
| 08:23 |
|
redavis joined #evergreen |
| 08:28 |
Stompro |
jeff++ thanks for the pointers last Friday for joining the bug Wranglers. |
| 08:38 |
|
dguarrac joined #evergreen |
| 09:04 |
|
Dyrcona joined #evergreen |
| 09:18 |
pinesol |
News from commits: LP2056480: docs: only index the latest version of the docs for lunr <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0f7289055ff89dd504dfd05f630897f32c203fe7> |
| 09:38 |
|
jvwoolf joined #evergreen |
| 09:48 |
|
jvwoolf joined #evergreen |
| 09:50 |
|
mantis joined #evergreen |
| 09:58 |
|
sleary joined #evergreen |
| 10:06 |
|
kworstell-isl joined #evergreen |
| 10:18 |
pinesol |
News from commits: LP#1779743: add privilege expiration date to Group Member Details <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1a8442295b291a5f8a4967277a0c893daca2c1de> |
| 10:19 |
mantis |
I had one patron/staff member who is very insistent on trying to have the OPAC logout button be HTML instead of JS. Is there anyone who can shed light as to why we don't have it as HTML? |
| 10:20 |
mantis |
My answer is JS just does it better/I don't even know how you can make a logout button HTML since that's more front end |
| 10:23 |
Dyrcona |
mantis: I don't think it is JS, not in the bootstrap OPAC: ./topnav_links.tt2\068: <a class="nav-link" href="[% mkurl(ctx.opac_root _ '/logout', {active_logout => 1}, 1) %]" id="logout_link">[% l('Logout') %]</a> |
| 10:28 |
mantis |
I think the issue is he uses a browser that doesnt run JS and he claims that he can do everything except logout |
| 10:28 |
mantis |
is that tied to opac_utils.js |
| 10:29 |
Dyrcona |
I don't know if you have any local customization or not. |
| 10:29 |
mantis |
gotcha |
| 10:29 |
mantis |
but we don't |
| 10:30 |
mantis |
the only thing we've done is just do the front end display |
| 10:30 |
|
kworstell-isl joined #evergreen |
| 10:31 |
Dyrcona |
The logout button int topnavlinks.tt2 goes to OPAC_ROOT/logout. That runes the load_logout mehtod of EGCatLoader. There is no JavaScript in a stock Evergreen installation in any of that. |
| 10:32 |
mantis |
Dyrcona++ thank you |
| 10:32 |
mantis |
I was getting confused with this |
| 10:33 |
Dyrcona |
If you want the relevant lines in main, it's topnavlinks.tt2 line 68 and line 789 in EGCatLoader.pm. |
| 10:34 |
Stompro |
I just tried logging out with the NoScript extension enabled and it seemed to work. Not sure if that is quite the same as having a browser without Javascript though. |
| 10:34 |
Dyrcona |
There are some parts of the Bootstrap OPAC that don't work so well without JavaScript. |
| 10:39 |
mantis |
Stompro: what's the name of the extension? |
| 10:45 |
Stompro |
mantis, This is the one I just tried - https://chromewebstore.google.com/detail/noscript/doojmbjmlfjjnbmnoijecmcbfeoakpjm |
| 10:45 |
|
Christineb joined #evergreen |
| 10:58 |
|
sandbergja joined #evergreen |
| 11:13 |
|
jihpringle joined #evergreen |
| 11:39 |
mantis |
ok one customization I did make could be preventing a NoScript environment to run, which was bundling the my account links into a dropdown menu, but it looks like CSS and not JS |
| 11:39 |
mantis |
<div class="dropdown"> |
| 11:39 |
mantis |
<button class="btn btn-opac dropdown-toggle" type="button" id="dropdownMenuButton" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"> |
| 11:39 |
mantis |
first link</a> |
| 11:39 |
mantis |
</button> |
| 11:44 |
jeff |
mantis: the dropdown-toggle class there suggests that you're using a Bootstrap component, which relies on JavaScript to work. |
| 11:44 |
Dyrcona |
It's possible that adds some JS behind the scenes, but that does look like it should be all CSS. Could be their browser can't handle the CSS level or it's blocking the popup. |
| 11:44 |
jeff |
mantis: you can see for yourself by trying to manipulate the examples here, with and without JavaScript enabled/permitted: https://getbootstrap.com/docs/4.0/components/dropdowns/ |
| 11:44 |
mantis |
jeff: ah ok gotcha |
| 11:45 |
jeff |
Dyrcona: the CSS class is hiding the dropdown components, and the lack of JavaScript is preventing them from being shown. |
| 11:51 |
Dyrcona |
jeff: Does this mean that CSS requires JavaScript to hide/show things even when it is all done with CSS? (Talk to me like I'm dumb, because I really don't keep up as much with Web stuff as I should.) Does it depend on which browser is used? |
| 11:53 |
Dyrcona |
You know, I should probably just look that up myself. :) |
| 11:54 |
jeff |
in this case, it means that the way Bootstrap implements this component depends on both CSS and JavaScript. |
| 11:56 |
jeff |
you can use CSS to hide/show things in a similar fashion, using different techniques. some use :hover pseudoclasses, but that's not great for accessibility, mobile, or probably a whole host of other reasons. some techniques get creative with a hidden checkbox so that you click to toggle the dropdown (and thus, avoid the downsides of a hover-only solution). |
| 11:58 |
jeff |
in the Bootstrap component here, the various css classes (like "dropdown" on the div and "dropdown-toggle" on the button) set up the default state (hidden) of the dropdown, and the bootstrap javascript that you include elsehwhere in the page sets up event handlers (or similar) to take care of changing the classes when you interact with the button, thus "hiding" and "showing" things. |
| 11:59 |
jeff |
this also explains why looking at just the snippet pasted above looks like it's "all done with CSS" -- though it isn't actually all done with CSS. |
| 12:05 |
|
jvwoolf joined #evergreen |
| 12:10 |
jeff |
Dyrcona: hopefully that helps -- let me know if you need anything more on it. :-) |
| 12:10 |
mantis |
jeff++ I remember when I originally did this, I was thinking of hover but not accessible, you're right |
| 12:10 |
mantis |
so I opted for a hide since all the links would run together on top |
| 12:19 |
pinesol |
News from commits: LP2046974 Hide "more" if facet has 5 or fewer links <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=cb1285745500dec50d19ed706778ce2380102537> |
| 12:21 |
Dyrcona |
jeff: That makes sense. My brain is elsewhere today. |
| 12:49 |
pinesol |
News from commits: LP2056069 Fix button styles in grid actions menu modal <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=95a995fec4a06c8e951625fcd0722037b3f367f4> |
| 12:49 |
pinesol |
News from commits: LP2056069 Fix button styles in grid column config modal <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=eb1cba11db29e0d983ae52e6f6bf001aaf3b5f5e> |
| 13:11 |
|
jvwoolf joined #evergreen |
| 13:18 |
|
kmlussier joined #evergreen |
| 13:42 |
Bmagic |
why doesn't Evergreen close the circulation on a no-bills circulation that was claims return upon checkin? |
| 13:48 |
Dyrcona |
Bmagic: What do you mean by "close the circulation?" Stop fines and stop fines time are set. |
| 13:49 |
Bmagic |
xact_finish = now() |
| 13:49 |
Dyrcona |
probably because it wasn't checked in. |
| 13:49 |
Bmagic |
I'm checking it in |
| 13:49 |
Bmagic |
it remains unfinished |
| 13:50 |
Dyrcona |
Well, hm.... I'd think checking it in would fix it, but I've never really tried checking in a claims returned item. |
| 13:50 |
Dyrcona |
There's a setting to stop a patron from circulating when they have too many claims returned circulations. |
| 13:51 |
Dyrcona |
So, claims returned itself should not set xact_finish in my opinion. |
| 13:53 |
Bmagic |
max patron claims returned count should* reference actor.usr.claims_returned_count and prevent the patron from making a new claim returned after the threshold is met |
| 13:54 |
Dyrcona |
Bmagic: I'm looking at the circulation code right now. If you check in a claims returned circ, it adds an event to the list. Are you being asked to override any events when you do this? |
| 13:54 |
Bmagic |
no |
| 13:54 |
Dyrcona |
Is checkin_time being set? |
| 13:56 |
|
jvwoolf joined #evergreen |
| 13:56 |
Bmagic |
checkin_time is set, though that is interesting. It's old |
| 13:57 |
|
sleary joined #evergreen |
| 13:57 |
Dyrcona |
Does it match the stop_fines_time? |
| 13:57 |
Bmagic |
yes |
| 13:58 |
Bmagic |
so perhaps my checkin didn't do anything |
| 13:58 |
Dyrcona |
checkin will bail if checkin_time is already set. |
| 13:58 |
Bmagic |
that's probably a clue |
| 13:58 |
Bmagic |
I'll set it to null and see what's up |
| 13:58 |
Dyrcona |
Another reason that a checkin will not set xact_finixh is if there are unpaid bills. |
| 13:59 |
Bmagic |
the bills I know about, none in this case |
| 14:00 |
Bmagic |
that took care of it |
| 14:00 |
Bmagic |
setting the checkin_time to null, then checked it in. It hit the circulation in the perl, and closed the transaction |
| 14:00 |
Bmagic |
so, for some reason, when it was checked in originally, it didn't close the transaction |
| 14:03 |
Dyrcona |
Bmagic: hadle_claims_returned at line 1,567 in Circulate.pm will set checkin_time, but not xact_finish. The latter may get set elsewhere. the Circulattion code is a bit complicated. |
| 14:03 |
Dyrcona |
That should be sub handle_claims_returned. |
| 14:04 |
Bmagic |
roger that |
| 14:05 |
Bmagic |
Dyrcona++ |
| 14:12 |
Dyrcona |
Setting a circulation to claims returned does not set checkin_time or xact-finish as far as I can tell, so looks like the checkin time was from a previous checkin attempt or maybe there was an old bug? |
| 14:13 |
Bmagic |
I think it was marked claims returned, then checked in |
| 14:13 |
Bmagic |
I would have expected the first checkin to have closed the transaction (there are 0 rows in money.billing and money.payment) |
| 14:13 |
Dyrcona |
Well, handle_claims_returned doesn't set xact_finish. |
| 14:14 |
Bmagic |
right, I think that's the correct thing |
| 14:14 |
Dyrcona |
That's when a claims returned is checked in, not marking something claims returned. |
| 14:14 |
Bmagic |
It was claimed returned |
| 14:14 |
Bmagic |
leaving the transaction open, which I think is the correct way to handle a claimed returned item. But when it was presented to the barcode scanner a week later, as a checkin, I would expect Evergreen to close the transaction |
| 14:15 |
Bmagic |
When I checked it in just now (first having set checkin_time to null) - it did! It set xact_finished=now() |
| 14:17 |
Bmagic |
There must be a circumstance where Evergreen doesn't set the xact_finish column for a previously claimed returned item. And that circumstance was met originally |
| 14:17 |
Dyrcona |
Things is in Circulae.pm the CLAIMSRETURNED "status" is checked multiple times in different places. do_copy_checks() calls handle_clams_returned(). do_copy-checks gets called from do_permit() which gets called when doing just about anything in circulation. |
| 14:19 |
Dyrcona |
It's too many layers of spaghetti. :) |
| 14:19 |
pinesol |
News from commits: LP2051599 Fix Cash Reports User Payments Date Parsing <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=dc62a7b3540859410e75c585ef585b7145a24c0a> |
| 14:19 |
pinesol |
News from commits: LP#2051599: fix parsing of start and end dates by Cash Reports <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3c6856f19e7e7b8c7b76e63b642ff26b53befde2> |
| 14:21 |
Dyrcona |
I can easily see a claims returned circulation being checked in and not getting xact_finish set even when there are no bills. |
| 14:22 |
Bmagic |
Thanks for looking! |
| 14:25 |
Dyrcona |
Gotta love this '# is this check still needed?' at line 3,799 where checkin_handle_circ_finish determines if it should set or clear the xact_finish. |
| 14:25 |
Dyrcona |
Well, I guess it's "test" not "check" in the comment, but still.... |
| 14:26 |
Bmagic |
:) |
| 14:26 |
Bmagic |
it's always fun reading history |
| 14:27 |
dguarrac |
I had a claims returned test going from a few weeks ago because we just created a new "Claims Returned" status. I just checked in that item and the circ got stamped with the current datetime for xact_finish, checkin_time, and checkin_scan_time. |
| 14:27 |
Dyrcona |
Are there any rows in money.billable_transaction_summary for that circulation? Well, probably not now if xact_finisht was set. |
| 14:27 |
dguarrac |
The circ's stop_fines_time is still the datetime from when the circ was marked as claims returned a few weeks ago, though. |
| 14:28 |
Dyrcona |
dguarrac: That sounds right. |
| 14:31 |
dguarrac |
Awesome! |
| 14:32 |
Dyrcona |
Bmagic: It looks like if there's an entry in money.billable_xact_summary, even if the balance_owed is 0.0, that could prevent xac_finish from being set. |
| 14:33 |
Dyrcona |
Because of floaing point fun, 0 is not always equal to 0.0. |
| 14:33 |
Bmagic |
that's a view on top of money.materialized_billable_xact_summary. I think each circulation receives a row there upon insert |
| 14:35 |
Dyrcona |
Yes. The if in checkin_handle_circ_finixh does "$balance == 0" but $balance is a floating point value, and computer are actually bad at floating point math, Perl notoriously so. |
| 14:36 |
Dyrcona |
Meh. I wish i could type today. :) |
| 14:36 |
Bmagic |
AFTER INSERT ON action.circulation EXECUTE PROCEDURE money.mat_summary_create('circulation'); |
| 14:37 |
Dyrcona |
Bmagic: Something about sufficiently large values of 0. :) |
| 14:37 |
Bmagic |
:) |
| 14:39 |
Dyrcona |
I think one of two things happened: 1) there was a balance owed on the circulation when it was first checked in or 2) there was some floating point issue with Perl. Right now, I'm leaning toward #1 being more likely. |
| 14:39 |
Dyrcona |
There was (is?) a bug where clearing a balance would not set a transaction's xact_finixh. |
| 14:40 |
Dyrcona |
M-x remap-key #?x #?s...... :) |
| 14:44 |
Bmagic |
hmm, there are zero rows in money.billing. I suppose those could have been deleted rather than voided |
| 14:47 |
Dyrcona |
it's possible. |
| 14:49 |
Dyrcona |
There may have been other bugs if this happened a few releases ago. None come to mind, but I was looking at the code from main when I described the above behavior. |
| 14:51 |
Bmagic |
Well, thanks again for spending so much time on it! For now, I'm satisfied that it was (probably) a one-off thing. Until we find a scenario that doesn't close the transaction. |
| 14:52 |
Dyrcona |
Well, I always jump at the chance to plumb the depths of circulation again. :) |
| 14:52 |
Bmagic |
I bet :) |
| 14:53 |
Dyrcona |
There a bug related to deleting patron accounts that have no bills, but Evergreen says you can't delete them because they have open transactions. The trick is to find the stuck circ, add a bill and pay it. |
| 14:53 |
Dyrcona |
I wouldn't be surprised if your circ being open and that are related somehow. |
| 14:57 |
|
jihpringle joined #evergreen |
| 14:58 |
* Dyrcona |
would like to get the Perl debugger working with the back end again. |
| 14:59 |
|
kmlussier1 joined #evergreen |
| 15:07 |
|
redavis joined #evergreen |
| 16:45 |
|
jihpringle joined #evergreen |
| 16:52 |
|
kmlussier joined #evergreen |
| 17:00 |
|
mantis left #evergreen |
| 17:08 |
|
abowling joined #evergreen |
| 17:32 |
|
abowling joined #evergreen |
| 18:18 |
|
kmlussier left #evergreen |
| 22:59 |
|
sleary joined #evergreen |
