| Time |
Nick |
Message |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:49 |
|
JBoyer joined #evergreen |
| 08:56 |
|
sandbergja joined #evergreen |
| 09:05 |
|
sandbergja joined #evergreen |
| 09:50 |
jeff |
Has anyone here considered including the user setting "Default Hold Pickup Location" in the patron summary? I don't see a stock way to do it with an OU setting. Short of patching it in, I'm thinking if it would make sense to have that togglable for some/all user settings, similar to how you can enable a user stat cat to be displayed in the summary (some user settings would need normalization or formatting |
| 09:50 |
jeff |
to be useful). |
| 09:50 |
jeff |
argh. the dreaded "your message was so long we broke it into two". |
| 09:52 |
berick |
jeff: we patched it in locally |
| 09:57 |
jeff |
berick++ thanks! confirms several things. :-) |
| 09:57 |
jeff |
(no stock way, we're not alone, etc.) |
| 09:57 |
Bmagic |
berick: I'm looking at the evergreen-xml-notices github project. Diffing that against a copy I have and they are off. Notibly the --for-text feature is missing from the github repo. How did I get that feature in my copy? Sorry, I forget, does the latest code live somewhere else (gonna write it down this time) |
| 09:58 |
berick |
Bmagic: this one? https://github.com/berick/evergreen-xml-notices -- see the message along the top |
| 09:59 |
Bmagic |
hehe, reading |
| 09:59 |
Bmagic |
ok, thanks |
| 10:00 |
Bmagic |
I wanted to make a contribution |
| 10:03 |
berick |
k, i think that calls for going back to a dedicated repo for that.. something I've been meaning to do |
| 10:04 |
berick |
should I put it on the kcls page to make it a little more official or is there somewhere better? |
| 10:09 |
Bmagic |
it's whatever you want. I'm almost done forking/pull request for evergreen-pub |
| 10:11 |
Bmagic |
wowsa, you've done a lot of work on this since last I pulled |
| 10:15 |
Bmagic |
I'm wondering if the colon in the filename removal was the reason for making a copy of this project back to the KCLS utilities. I see that the colon in the filename exists in this version |
| 10:24 |
jeff |
Well that's puzzling. Looking at stats for a branch library, their count of distinct users with a circ grouped by year went down. Of the numerous ways that I can think of that would cause that, none seem to apply or be possible. |
| 10:28 |
eby |
@blame melcat |
| 10:28 |
pinesol |
eby: we've had a good run, melcat, but it's time to say goodbye forever |
| 10:30 |
jeff |
Oh, here we go: in a later iteration, I included users with circulations in the ... yes, eby: MeLCat. :-) |
| 10:30 |
jeff |
I just needed to keep reading in my notes from 2023 when I ran these ad-hoc stats for a director request. |
| 10:31 |
eby |
have you been 'modernized' yet |
| 10:32 |
jeff |
For those curious, I was comparing the numbers we had provided with an initial first iteration of the query, and that version of the query did not count circulations at that library that took place via MeLCat. Running the final version of the query from 2023 on today's database matches the numbers in the output of the query from back then. (phew) |
| 10:33 |
|
dguarrac joined #evergreen |
| 10:34 |
jeff |
eby: No more than the whole yet. As I recall, there's a bunch of backend modernization that's happened, and then we'll each be individually (or as groups by DCB server) "modernized" in the way that eventually results in us no longer using the Millennium client. |
| 10:35 |
eby |
yeah dcb4 is set for feb 10 with documentation coming after it starts now. hoping it won't mean more iNCIPit tweaks |
| 10:57 |
pinesol |
News from commits: LP2095215 Ensure that actor.usr_mfa_exception gets created <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7406c8001d3a332f67a39bad23574b6b380d8b95> |
| 11:13 |
|
Christineb joined #evergreen |
| 11:27 |
pinesol |
News from commits: LP#2095215: (follow-up) add the table during upgrade if necessary <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4426b7dcd416d33288dc8e61c8830eb19846e06f> |
| 11:33 |
Bmagic |
anyone using 3.13+ and found that shared template folders are getting polluted with other user's templates somehow. I can't use the interface to figure out how they are able to save templates into other users's shared template folders, but they are somehow |
| 11:33 |
Bmagic |
(reporter) |
| 11:36 |
Bmagic |
I thought maybe there was a bug wit the "move" feature. Allowing someone to move a local template to a shared template folder. But no dice. In some cases, the user doesn't even have a folder of their own, so I don't see how they were able to create a template in the first place. clone or otherwise. A clue might be: each example user does have Simple Reports template folder... hmmm, interesting |
| 11:48 |
csharp_ |
maybe the table sequence is borked? |
| 11:49 |
Bmagic |
ha! Figured it out. If you use standard reports first, and browse the shared tempaltes folders. Click a folder. That's all you need to do. Then switch to Simple reporter and create a new template. Just throw some columns on there and click save. The resulting simple report template will land in the shared folder from the previous step |
| 11:49 |
Bmagic |
freaky |
| 11:49 |
csharp_ |
in the olde dayes we saw an issue where an upgrade reset a sequence and started assigning new users to old users' groups - it was a huge PITA to untangle |
| 11:50 |
csharp_ |
Bmagic: ewwww |
| 11:50 |
Bmagic |
writing bug report |
| 11:50 |
csharp_ |
we don't have the Simple Reporter enabled at this point |
| 11:50 |
csharp_ |
(i.e., we removed the menu entry) |
| 11:53 |
Bmagic |
man, that was a wild ride. I'm thinking to myself, how in the world..... |
| 11:53 |
csharp_ |
@blame bots |
| 11:53 |
pinesol |
csharp_: bots stole csharp_'s ice cream! |
| 11:53 |
Bmagic |
Think like a user. What are they doing to make this happen |
| 11:54 |
csharp_ |
that's when end users start saying my least favorite tech-related word: glitch |
| 11:54 |
Bmagic |
and they'd be right in this case |
| 11:54 |
Bmagic |
My favorite tickets lately are "it freezes" |
| 11:56 |
csharp_ |
Bmagic: thank $deity that you weren't around for the XUL client memory leak - it took a very long time to train our users to stop attributing anything they saw to "the memory leak" |
| 11:57 |
csharp_ |
it was all on super old, under-resourced-even-for-the-time Windows XP/7 workstations that we're barely functioning anyway |
| 11:57 |
Bmagic |
That was pre-2012? I think I remember it |
| 11:57 |
Bmagic |
I started in 2012 |
| 11:57 |
csharp_ |
thankfully our local system admins have gotten way more skilled and savvy |
| 11:58 |
csharp_ |
we have an annual IT Boot Camp that helps everyone learn and exchange information |
| 11:58 |
csharp_ |
also Windows got better |
| 11:58 |
csharp_ |
and a lot of libraries are on Chrome for all OPACs |
| 11:58 |
Bmagic |
lol, I defintely understand the easy latch-on to a known issue like "memory leak" |
| 11:59 |
mmorgan |
s/memory leak/cache |
| 12:00 |
csharp_ |
oh yeah |
| 12:00 |
csharp_ |
especially in early web client days |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:55 |
|
jihpringle joined #evergreen |
| 15:38 |
JBoyer |
Since I was just grousing about it yesterday I thought I'd mention that just today Aspen auto-blocked a library from their own catalog because of whatever clever stuff it does. See prior complaint. :D |
| 16:30 |
jmurray-isl |
JBoyer++ |
| 17:02 |
|
mmorgan left #evergreen |
| 20:10 |
|
jeffdavis joined #evergreen |
