| Time |
Nick |
Message |
| 00:05 |
|
alynn26_away joined #evergreen |
| 00:15 |
|
dluch joined #evergreen |
| 00:15 |
|
Bmagic joined #evergreen |
| 00:15 |
|
devted joined #evergreen |
| 00:15 |
|
genpaku joined #evergreen |
| 00:15 |
|
awitter joined #evergreen |
| 00:15 |
|
phasefx joined #evergreen |
| 00:16 |
|
dluch joined #evergreen |
| 00:16 |
|
Bmagic joined #evergreen |
| 00:16 |
|
devted joined #evergreen |
| 00:16 |
|
genpaku joined #evergreen |
| 00:16 |
|
awitter joined #evergreen |
| 00:16 |
|
phasefx joined #evergreen |
| 00:18 |
|
genpaku joined #evergreen |
| 00:18 |
|
dluch joined #evergreen |
| 00:18 |
|
Bmagic joined #evergreen |
| 00:18 |
|
devted joined #evergreen |
| 00:18 |
|
awitter joined #evergreen |
| 00:19 |
|
phasefx joined #evergreen |
| 00:21 |
|
sandbergja joined #evergreen |
| 00:40 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 07:30 |
|
mantis joined #evergreen |
| 07:41 |
|
rfrasur joined #evergreen |
| 07:48 |
|
rlefaive joined #evergreen |
| 08:31 |
|
tlittle joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:51 |
|
collum joined #evergreen |
| 08:56 |
rhamby |
rfrasur - fwiw the baseline goal for marc templates in db doesn't really need discussion I think (expansions beyond different issue) but it definitely needs a champion to see it happen |
| 08:56 |
rhamby |
every cataloger I know wants this but no one is fighting to make it happen |
| 08:56 |
rfrasur |
rhamby, yes. I think this is a worthy mountain. |
| 08:58 |
rfrasur |
I've added a topic in the ECDI forum. There are a few other things that I need to give priority, but most of them seem to have their own (sort of) heads of steam. |
| 08:58 |
rhamby |
yeah, there is probably some language out there for "issues that persistently annoy people but they're so used to them they don't htink about fixing them anymore" - that is how I think of this one |
| 08:59 |
rhamby |
term in a language |
| 08:59 |
rfrasur |
lol, yes |
| 09:00 |
rhamby |
really, you wouldn't need to touch the existing UI for this one, just add a new UI for adding, editing, deleting them and the db structure (that part is simple), and re-direct all the perl parts and cut some existing stuff out ... enough that a spec would be useful |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:17 |
|
Keith-isl joined #evergreen |
| 09:35 |
|
dbwells joined #evergreen |
| 09:52 |
|
jvwoolf joined #evergreen |
| 10:02 |
rfrasur |
I think part of the reason is we don't OFTEN have to make changes or add templates. But then OCLC does a change that affects EVERY template. |
| 10:02 |
rfrasur |
And yes, rhamby, a new UI was my thought as well. |
| 10:08 |
|
nfBurton joined #evergreen |
| 10:11 |
|
dbwells joined #evergreen |
| 10:19 |
|
dbwells joined #evergreen |
| 11:18 |
|
rlefaive joined #evergreen |
| 11:48 |
|
dbwells joined #evergreen |
| 11:55 |
Dyrcona |
So, i have a question. Looking for opinions. We've been enabling hold notifications for members as requested. Today, a member asked to have the notifications enabled for their branch, and the notices have been enabled for quite a while for the main library. |
| 11:56 |
Dyrcona |
I'm leaning toward updating the owner on the main branch notifications to be their system org unit id, since they only have the 2 locations. My other option would be to add a new set of events for the branch. |
| 11:56 |
Dyrcona |
The pros and cons of either are many. |
| 11:57 |
Dyrcona |
If anyone has done something like this before and has thoughts, feel free to chime in. I think I'll break for lunch and make a decision afterward. |
| 11:57 |
|
jihpringle joined #evergreen |
| 12:01 |
|
rfrasur joined #evergreen |
| 12:01 |
|
dbwells joined #evergreen |
| 12:20 |
|
rfrasur joined #evergreen |
| 12:23 |
|
jvwoolf1 joined #evergreen |
| 12:23 |
|
rfrasur joined #evergreen |
| 12:41 |
jeff |
Dyrcona: we split some event defs for hold.available into per-branch from their previous per-system defs. In theory we're at a point now where I can reassemble them, but I've not done so yet, nor have I decided if we want to leave them like this or not. |
| 12:42 |
jeff |
Dyrcona: agreed that there are several pros and cons. I've not sat down and enumerated them all. |
| 12:48 |
Dyrcona |
I've not enumerated them all, either. |
| 12:49 |
Dyrcona |
It looks like I've got per branch for another system where all of the branches are now doing notifications. I also have at least 1 where the notifications are at the system level. |
| 12:50 |
Dyrcona |
The fun part of going from one per branch to per system, or even back up to the whole consortium (like we had before the pandemic changes), is updating all the pending events to the "new" id. |
| 12:52 |
|
jihpringle joined #evergreen |
| 12:52 |
* jeff |
nods |
| 12:53 |
jeff |
I remember lots of disabled cron jobs followed by ad hoc sql. |
| 12:53 |
Dyrcona |
Well, I do have the advantage of scheduling these for the evening, so there's less chance of having cron job problems. |
| 12:55 |
Dyrcona |
Even though I prepared a SQL to undo this last year, I suspect that we won't be going back to 1 set of notification events for the whole consortium. I could be wrong, and I suspect that I'll know for certain by August or so. |
| 12:59 |
Dyrcona |
I should have been more consistent. For most of the "single branch systems" I did this at the branch level. I probably should have used the system. It didn't seem to matter at the time. |
| 13:01 |
jeff |
we've had that semi-consistency here also. event defs, shelving locations, circ policies... I think we're consistent in at least each place... all the circ policies for single-location libraries are at the system level, say. |
| 13:01 |
jeff |
(but shelving locations might all be owned at the branch level, for example) |
| 13:01 |
Dyrcona |
Yeah. |
| 13:02 |
Dyrcona |
I should be able to just update the owner on the main branch's event defs, and it will "just work." :) |
| 13:15 |
Dyrcona |
I may just clean up the other library where all branches are doing hold notifications. |
| 13:16 |
Dyrcona |
jeff++ |
| 15:49 |
jeff |
barcode completion is certainly handy when it comes to situations like libraries with overlapping item barcodes. |
| 15:50 |
jeff |
I mean, overlapping barcodes are still a pain and worth avoiding for all kinds of other reasons, but barcode completion makes the whole thing slightly more tolerable. |
| 15:55 |
mmorgan |
jeff: by overlapping, do you mean the same significant digits but different prefixes? |
| 15:57 |
* mmorgan |
just had an interesting issue reported with user barcode completion. |
| 15:57 |
|
sandbergja joined #evergreen |
| 15:59 |
mmorgan |
Whenever the library starts typing a patron barcode beginning with 2 on the place hold screen in the staff client (tpac) it matches on a patron with "2" as the significant digit. |
| 16:04 |
jeff |
by overlapping, I mean two branches in a system using a barcode like "T 9999". With barcode completion, I can import one as "T 9999_LIB2" and define a barcode completion for the system with a suffix of "_LIB2" |
| 16:06 |
jeff |
then, scanning "T 9999" (we've reverted the commit that strips whitespace from barcodes) gives you the Barcode Choice dialog, asking you to select from the items, showing their barcode (as stored in the db), title, and circ lib. |
| 16:06 |
jeff |
mmorgan: does the library in question have patron barcode completion rules defined? |
| 16:08 |
mmorgan |
jeff: Yes, and they find it useful, so dp |
| 16:08 |
|
jihpringle joined #evergreen |
| 16:08 |
mmorgan |
don |
| 16:08 |
mmorgan |
't want it disabled |
| 16:08 |
* mmorgan |
apparently can't type today |
| 16:09 |
mmorgan |
It always surprises me to see barcodes like those you mention. Ours are all standard, numeric prefix and 14 digits. No spaces |
| 16:10 |
jeff |
I would guess that there might be an issue with that input performing a barcode completion lookup "too soon". I know that interface has had some issues like that in the past. |
| 16:10 |
mmorgan |
Yes, I think a delay would help. Or the ability to configure something like "don't try and complete a barcode until you get 3 characters" |
| 16:12 |
jeff |
worth a launchpad bug, at least. i don't think that interface would be out of support yet. |
| 16:16 |
Dyrcona |
Don't try completion before X number of characters entered. |
| 16:16 |
jeff |
amused that "Search the Catalog (Traditional)" brings up a very not-traditional looking boopac interface. :-) |
| 16:17 |
mmorgan |
Dyrcona: Exactly! |
| 16:19 |
jihpringle |
jeff: https://bugs.launchpad.net/evergreen/+bug/1919178 |
| 16:19 |
pinesol |
Launchpad bug 1919178 in Evergreen "Bootstrap OPAC has replaced Traditional Catalogue in Staff Client" [Undecided,New] |
| 16:21 |
jeff |
I think the behavior changed in bug 1778606 / commit 332588c |
| 16:21 |
pinesol |
jeff: [evergreen|Dan Briem] LP#1778606 Web Client - Place Hold Requires Two Clicks on Submit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=332588c> |
| 16:21 |
pinesol |
Launchpad bug 1778606 in Evergreen master "Web Client - Place Hold Requires Two Clicks on Submit" [Medium,Fix released] https://launchpad.net/bugs/1778606 |
| 16:21 |
jeff |
(the place hold barcode lookup timeout) |
| 16:21 |
jeff |
commit 332588c |
| 16:21 |
pinesol |
jeff: [evergreen|Dan Briem] LP#1778606 Web Client - Place Hold Requires Two Clicks on Submit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=332588c> |
| 16:24 |
mmorgan |
jeff: Yes, and bug 1903358 is the companion bug for the angular staff client, not fixed yet |
| 16:24 |
pinesol |
Launchpad bug 1903358 in Evergreen "Angular Catalog: Submit Required after entering Patron Barcode when Placing Hold" [Medium,Confirmed] https://launchpad.net/bugs/1903358 |
| 16:32 |
|
mantis left #evergreen |
| 16:38 |
Bmagic |
I'm reinstalling Evergreen to see if that helps, but this problem where any Angular interface requires authentication (again) when clicking any Staff Admin link that goes to Angular... I don't think it's memcached related |
| 16:40 |
Dyrcona |
Bmagic: I've not heard of that one. Is it everybody or just some users? |
| 16:41 |
Bmagic |
everybody, it's something* on the server and I know I've fixed it before... |
| 16:41 |
Dyrcona |
Well, IDK, then. Good luck! |
| 16:43 |
Bmagic |
ty |
| 16:46 |
jeff |
interesting. double-call to open-ils.cat.asset.volume.fleshed.batch.update.override that involves setting an item status will overwrite the status_change_time on the second call. i wonder where that's originating... |
| 16:47 |
jeff |
(and if it's still a valid bug or if it's fixed/moot in a new version) |
| 16:48 |
Bmagic |
jeff: that one sounds "fun" |
| 16:48 |
Bmagic |
I'm sure it's in the code somewhere, lol |
| 16:48 |
jeff |
relevant but for different reasons: bug 1235420 |
| 16:48 |
pinesol |
Launchpad bug 1235420 in Evergreen "status_changed_time can go back in time" [Medium,Triaged] https://launchpad.net/bugs/1235420 - Assigned to Rogan Hamby (rogan-hamby) |
| 16:49 |
Bmagic |
RIP pinesol, nvm |
| 16:58 |
Dyrcona |
gmcharlt++ |
| 17:06 |
Bmagic |
Dyrcona: Figured it out. It was browser cache. Weeee. Fresh upgrade, old browser to interact with the new server. Causes the local code to throw the workstation registration again and again |
| 17:10 |
|
jvwoolf1 left #evergreen |
| 17:21 |
|
Keith-isl left #evergreen |
| 17:27 |
|
mmorgan left #evergreen |
| 17:35 |
|
jwoodard joined #evergreen |
| 17:39 |
JBoyer |
Bmagic, Ah! That reminds me when I saw that. It's not necessarily the whole cache, just the workstation settings in LocalStorage. |
| 17:40 |
Bmagic |
JBoyer++ |
| 17:41 |
Bmagic |
It's hard to shake. I can still reproduce the white screen of death in private browsing mode on an old URL (freshly upgraded server) |
| 17:41 |
JBoyer |
So if the db your rebuilt that server from had existing workstations in it but the id's didn't match it wouldn't be recognized as removed so you would be able to login, but part of the login process uses the id provided which does not match, throwing you back to the login page over and over until you remove the old workstation(s) manually |
| 17:41 |
Bmagic |
CTRL+SHIFT+R whilst on the new Angular registration page fixes it |
| 17:42 |
JBoyer |
And if you're using Firefox private browsing doesn't work at all before a certain (recent) version because it removes some feature we use. |
| 17:42 |
Bmagic |
and continuing to use that key combo in just about every singe interface throughout the staff client (only the once after a fresh upgrade) |
| 17:42 |
Bmagic |
yep FF |
| 17:43 |
JBoyer |
That seems odd, so may not be the same thing. |
| 17:43 |
Bmagic |
granted the difference between the previous EG version and new is a big leap: 3.1 -> 3.7 |
| 17:44 |
Bmagic |
goodnight all |
| 17:51 |
|
mantis joined #evergreen |
| 17:52 |
|
mantis left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:45 |
|
nfBurton joined #evergreen |
| 19:48 |
|
jihpringle joined #evergreen |
| 22:41 |
|
sandbergja joined #evergreen |
