| Time |
Nick |
Message |
| 03:21 |
|
jonadab joined #evergreen |
| 03:21 |
|
gmcharlt joined #evergreen |
| 03:21 |
|
miker joined #evergreen |
| 03:21 |
|
eady joined #evergreen |
| 03:21 |
|
JBoyer joined #evergreen |
| 03:21 |
|
book`_ joined #evergreen |
| 03:21 |
|
eby joined #evergreen |
| 03:21 |
|
csharp_ joined #evergreen |
| 03:21 |
|
rhamby joined #evergreen |
| 03:21 |
|
akilsdonk joined #evergreen |
| 03:21 |
|
dbs joined #evergreen |
| 03:21 |
|
phasefx joined #evergreen |
| 03:21 |
|
Bmagic joined #evergreen |
| 03:21 |
|
bshum_ joined #evergreen |
| 03:21 |
|
jeff joined #evergreen |
| 03:21 |
|
berick joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Failed Installing AngularJS web client <http://testing.evergreen-ils.org/~live//archive/2022-01/2022-01-10_04:00:02/test.28.html> |
| 07:22 |
|
Christineb joined #evergreen |
| 07:26 |
|
collum joined #evergreen |
| 07:47 |
JBoyer |
So, the latest release of colors is now 1.4.2 but that is still affected. Since npm install doesn't trigger the dos it looks like it's easy enough to manually fix index.js. |
| 07:47 |
|
mantis joined #evergreen |
| 07:47 |
JBoyer |
"Just remove the affected packages" is a good idea but a little tricky since one of them is karma itself. :/ |
| 07:48 |
JBoyer |
And ng-toast, |
| 08:08 |
JBoyer |
So unless npm just hard-codes 1.4.0 or 1.4.1 or all 9 affected packages that we use pin one of those versions building Evergreen will have a manual step. |
| 08:13 |
JBoyer |
The good news is that all you have to do for now is edit Open-ILS/web/js/ui/default/staff/node_modules/colors/lib/index.js and remove all lines after the fake "/* remove this line..." before proceeding with npm build. |
| 08:17 |
JBoyer |
And for those wondering, we get to do this again for the Angular client also (even more uses) though the bootstrap opac deps are unaffected. |
| 08:23 |
csharp_ |
well, at least it was developer nonsense and not straight up malware that's screwing everyone |
| 08:25 |
csharp_ |
it definitely highlights the risks of NPM, though |
| 08:29 |
|
rfrasur joined #evergreen |
| 08:34 |
JBoyer |
Well, it isn't a bitcoin miner or auth scraper, but I'd consider a DOS to be close enough, it's just simple to fix. It's also a hell of a way to announce to the world that you're no longer going to work in tech. |
| 08:36 |
|
jonadab joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:43 |
|
jonadab joined #evergreen |
| 08:50 |
|
mmorgan left #evergreen |
| 08:54 |
|
mmorgan joined #evergreen |
| 09:18 |
|
alynn26 joined #evergreen |
| 09:39 |
|
Keith_isl joined #evergreen |
| 09:51 |
|
mmorgan1 joined #evergreen |
| 09:51 |
|
mmorgan2 joined #evergreen |
| 09:56 |
|
jvwoolf joined #evergreen |
| 10:10 |
csharp_ |
oh, I must have missed that part of it (no longer working in tech)) |
| 10:13 |
csharp_ |
ah - I see - it's a sh*tshow |
| 10:16 |
JBoyer |
Yeah, he isn't saying "I quit" but if anyone hires him now they're the idiot. |
| 10:23 |
csharp_ |
can't we just specify one of the pre-insanity releases in package.json(s)? |
| 10:27 |
mantis |
Has anyone noticed a server error when clicking Patron View on a conjoined item record for Angular? We have this issue but with Bootstrap and TPAC, it's fine. |
| 10:30 |
JBoyer |
csharp_, *we* don't use it at all, it's a dependency for several packages and they have to update their package.json files. (Which I imagine many are today.) |
| 10:31 |
JBoyer |
Though now that you mention it, I wonder if us specifying a specific version would cause npm to use that one everywhere... |
| 10:33 |
JBoyer |
WELL HEY. |
| 10:33 |
JBoyer |
csharp_++ |
| 10:41 |
csharp_ |
heh |
| 10:59 |
|
jvwoolf joined #evergreen |
| 11:25 |
|
jihpringle joined #evergreen |
| 12:40 |
|
collum joined #evergreen |
| 13:10 |
alynn26 |
rfrasur, the title database id is in the listing already, it is labeled Document ID. |
| 13:11 |
rfrasur |
Can we change the label? |
| 13:11 |
alynn26 |
Do EI did not. |
| 13:44 |
|
collum joined #evergreen |
| 15:56 |
|
BAMkubasa joined #evergreen |
| 15:59 |
BAMkubasa |
hey folks, I seem to recall that an upgrade at some point provided for the ability to show/hide patron permission groups from certain OUs when working in the patron registration form. if you have consortia level shelving locations, is there a way to not show all of them to some OUs? (we have as many of our shelving locations at the top level as is |
| 15:59 |
BAMkubasa |
reasonable, but not everyone uses and wants to see all of them) |
| 16:06 |
jihpringle |
BAMkubasa: I think your only option for hiding shelving locations is still the OPAC visible flag (which affects all your org units) |
| 16:06 |
BAMkubasa |
Thanks! |
| 16:07 |
BAMkubasa |
In this instance, I'm really trying to hide them from the drop downs that catalogers see. I'm fearing the only solution is not having such a heavy reliance on consortia level shelving locations |
| 16:07 |
jihpringle |
depending on what your cataloguers need, item templates might be a workaround |
| 16:10 |
jihpringle |
then they can just choose the template they want that already has the appropriate shelving location selected instead of going through the whole list |
| 17:12 |
|
mmorgan2 left #evergreen |
| 17:31 |
|
jvwoolf left #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
