Time |
Nick |
Message |
06:51 |
|
collum joined #evergreen |
07:15 |
|
kworstell-isl joined #evergreen |
07:57 |
|
BDorsey joined #evergreen |
08:17 |
|
kworstell-isl joined #evergreen |
08:22 |
|
kworstell_isl joined #evergreen |
08:35 |
|
Rogan joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
09:08 |
|
Dyrcona joined #evergreen |
09:23 |
|
kworstell-isl joined #evergreen |
09:40 |
StomproJ |
I didn't realize bug 1862834 was a thing... we have 88 call number prefixes in use with 250 templates... lets go test that fix out. |
09:40 |
pinesol |
Launchpad bug 1862834 in Evergreen 3.11 "regex based url building that can match hostnames" [Medium,Confirmed] https://launchpad.net/bugs/1862834 |
09:41 |
StomproJ |
Ooops, bad paste buffer. I mean bug 1983156. |
09:41 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] https://launchpad.net/bugs/1983156 - Assigned to Michele Morgan (mmorgan) |
09:42 |
mmorgan |
StomproJ++ |
09:44 |
mmorgan |
StomproJ: Just fyi, I feel the current patch is progress, but it's incomplete. It does allow call number attributes in existing templates to work, though, which is the most important thing. |
09:46 |
StomproJ |
So it needs the bits to save back into the template when updating the template? |
09:46 |
mmorgan |
StomproJ: Exactly! |
09:47 |
mmorgan |
Also, the standalone template editor under Local Admin DOES allow the call number attrs to get saved in the template - that interface hasn't been angularized yet. |
09:48 |
StomproJ |
That makes testing a bit harder, if someone cannot add that info to the prefix.... ah. |
09:49 |
* mmorgan |
can add some testing notes to the LP bug. |
09:49 |
StomproJ |
I'm seeing two actor.usr_setting types for storing templates, cat.copy.templates and staff_client.copy_editor.templates. |
09:49 |
StomproJ |
Is staff_client.copy_editor.templates the old XUL key? |
09:50 |
Dyrcona |
One of them is, and I don't remember which. |
09:51 |
StomproJ |
cat.copy.templates seems to what the Angular client uses. I think I got them confused in another bug I was looking at. |
09:51 |
StomproJ |
Shoot, I worked for a few hours on that, not noticing that it was the wrong one. |
09:51 |
mmorgan |
cat.copy.templates is the one. |
09:52 |
Dyrcona |
"[T]he standalone template editor under Local Admin" this points to a problem without intending to. |
09:53 |
|
Rogan joined #evergreen |
09:57 |
StomproJ |
mmorgan, I'm in what I think is the standalong template editor, but there is no item section where the prefix can be set. |
10:00 |
mmorgan |
StomproJ: Just posted some testing notes: https://bugs.launchpad.net/evergreen/+bug/1983156/comments/9 |
10:00 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] - Assigned to Michele Morgan (mmorgan) |
10:00 |
mmorgan |
You need to set preferences in the holdings editor to get those to display. |
10:01 |
StomproJ |
Thanks |
10:01 |
mmorgan |
Thanks for having a look! |
10:07 |
StomproJ |
I'm still not seeing the item info in the stand alone template editor though... |
10:11 |
StomproJ |
Maybe I need to set the settings in the AngularJS volcopy editor, instead of the Angular one? |
10:13 |
mmorgan |
StomproJ: Do you mean "call number info"? Setting it in the Angular holdings editor should work, it should set the same ws setting as the AngularJS option. |
10:18 |
StomproJ |
I had to open up https://bugsquash2.mobiusconsortium.org/eg/staff/cat/catalog/record/252 to get the AngularJS interface, then Add Holdings to get the AngularJS Volcopy editor, then Defaults, and set Allow Call Number attributes in Item Templates there. |
10:20 |
StomproJ |
The settings storage must be different between the versions? |
10:22 |
mmorgan |
Hmm. Shouldn't be, unless I missed something - which is possible :) |
10:24 |
StomproJ |
AngularJS volcopy prefs seem to be in cat.copy.defaults - and the "Allow Call Number attributes" sets the ""show_vol_template_controls": true," json value |
10:25 |
StomproJ |
Angular seems to use "eg.cat.volcopy.defaults" and sets "show_vol_template_controls": true |
10:27 |
mmorgan |
Ok, that makes sense. So it sounds like you DO need to set the preference in the angularjs holdings editor to get the call number attributes to show in the standalone holdings editor. |
10:28 |
mmorgan |
Just so you can create a template to test. I can see how this is difficult to test. :-/ |
10:29 |
StomproJ |
Yes, but I'm making progress. I'm just adding some Call number suffix entries to make sure I try them also. |
10:31 |
mmorgan |
StomproJ++ |
10:34 |
pinesol |
News from commits: LP2028088 Fix info, primary, success button colors <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5186c72cc0d5aa0ab142a8515697735bef6cd1b5> |
10:35 |
Dyrcona |
QOTD (although it is 3 years old): "You may be tempted to meddle with the pg_database system catalog manually, but I can only discourage that: as the saying is, if you do that and things break, you get to keep both pieces." |
10:35 |
|
kworstell_isl joined #evergreen |
10:37 |
StomproJ |
mmorgan, the Suffix isn't applying. |
10:37 |
mmorgan |
:-( |
10:39 |
* mmorgan |
will need to take a look at that. |
10:41 |
StomproJ |
mmorgan, false alarm, had to log out and log in for the template change to get read. Could have been a side effect of me doing things in different tabs. |
10:42 |
StomproJ |
The Suffix does apply. |
10:42 |
mmorgan |
Ok, thanks! I have to admit, in my testing I was mostly focusing on Classification and Prefix, but thought I did try Suffix a few times :) |
10:43 |
StomproJ |
We don't use suffix at all either in production, but I don't want to hurt it's feelings by not testing it. |
10:44 |
mmorgan |
We have lots of libraries that use Prefix, many fewer that use Suffix, but it needs to work, too! |
10:46 |
Dyrcona |
If it is there, someone will use it. :) |
10:47 |
StomproJ |
I really hate that template save button being there. Gets me every time. |
10:48 |
Dyrcona |
So, move it somewhere safer. |
10:49 |
* mmorgan |
has hit that a few times by accident, too! |
10:50 |
StomproJ |
I thought the AngularJS volcopy editor did have it moved.. |
10:50 |
StomproJ |
Yes, it did, I liked that. |
10:51 |
Dyrcona |
So, move it while you're working on the code. |
10:54 |
StomproJ |
Dyrcona, if I ever get proficient with Angular I'll give it a shot. |
11:00 |
Dyrcona |
By then we'll be using Circular or whatever comes next. :P |
11:03 |
StomproJ |
Ha, no doubt. |
11:04 |
|
mdriscoll joined #evergreen |
11:04 |
StomproJ |
mmorgan, it seems to work as described.... I'm going to look at the saveTemplate() function in Open-ILS/src/eg2/src/app/staff/cat/volcopy/copy-attrs.component.ts and see how hard it is to add info to the template. |
11:05 |
mmorgan |
StomproJ: That would be awesome! I've been poking at it, but am also struggling to become proficient in Angular! :) |
11:18 |
* berick |
grabs 1380 |
11:34 |
pinesol |
News from commits: LP1999804 Stamp DB Upgrade (ADMIN_PROXIMITY_ADJUSTMENT) <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6e13d5bf6eb42366589e5553b0dbe97f0570d044> |
11:34 |
pinesol |
News from commits: LP1999804 - Add Missing Permission ADMIN_PROXIMITY_ADJUSTMENT <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8d911740ac4998e5afb6b2e6c0c873f41788b63c> |
11:34 |
pinesol |
News from commits: LP1917092: Add release note. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=24c07c5ccbb833dbbdcdff7b46552d4d114e30ff> |
11:34 |
pinesol |
News from commits: LP1917092: Filter shelving location grid to non-deleted by default <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1d91157da26fcfa578195dff2b52110a8a8f1a2e> |
11:59 |
|
jihpringle joined #evergreen |
12:02 |
mmorgan |
So if a patch is committed to main and 3.11, and should also be applied to 3.10, but there are conflicts that need to be resolved, should the 3.10.4 target be set in Launchpad? |
12:04 |
pinesol |
News from commits: LP2030915: Add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=80bcff6795c472a9cec3031d15e0428cc98fd308> |
12:04 |
pinesol |
News from commits: LP2030915: Restrain creation of AutorenewNotify events <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=635cc3971e11f883a2db7d25276b47248960e9ac> |
12:04 |
pinesol |
News from commits: LP#1986706 - Fast Item Add - barcode wasn't being set in volcopy editor. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e1dccfb02086fbe25265a3d17f3c999313d38dc9> |
12:06 |
Dyrcona |
mmorgan: if the conflicts are resolved and it is pushed to 3.10, then yes. If you're not going to push it to 3.10, then set it to "won't fix" for 3.10 and remove the milestone. |
12:07 |
Dyrcona |
It wouldn't hurt to add a comment about it is "won't fix" for 3.10. |
12:13 |
mmorgan |
Dyrcona: My intent is to push it to 3.10, but need to look at the conflicts. It's already been pushed to main and 3.11 and those targets say Fix Committed. To me it makes sense to add the 3.10 target pending resolution of the conflicts, but I don't see that consistently on LP. |
12:16 |
Dyrcona |
Your plan sounds find to me. It's OK to add the milestone if you think you'll get in for the release. As for the lack of consistency, we don't have really firm guidelines on setting these things, there are many of us, we're only human, etc. |
12:16 |
Dyrcona |
s/find/fine/ |
12:18 |
mmorgan |
Ok, thanks! I will add those targets so the intent won't get lost! |
12:18 |
mmorgan |
Dyrcona++ |
12:53 |
|
kworstell-isl joined #evergreen |
13:12 |
Dyrcona |
Ooh... Subtle bug is subtle: 08 != 8; and 08 is 'value too great for base (error token is "08")' |
13:13 |
Dyrcona |
And all because it is August. Script worked just fine until this month. :) |
13:14 |
berick |
Beware the Octal of August |
13:15 |
berick |
guess Caesar didn't make it that far |
13:15 |
Dyrcona |
berick++ |
13:15 |
Dyrcona |
It works fine every month but August and September. |
13:17 |
Dyrcona |
Fix is not too onerous. Since I'm using `date +%m` to get the month, I just pipe that through `sed -e s/^0//`. |
13:18 |
Dyrcona |
Too bad it didn't blow up, it just produces bogus output with dates like 20230025. |
13:19 |
Dyrcona |
I noticed that and started picking it apart to find the issue. |
13:28 |
|
kworstell-isl joined #evergreen |
13:35 |
mdriscoll |
Dyrcona: I'm looking at customizations in our system and checking If each has a Launchpad bug. You created a fix in SuperCat.pm so keyword searches from Comcat would not be treated as exact matches. Does that merit a launchpad bug? Would it be of interest to anyone else? |
13:39 |
Dyrcona |
mdriscoll: I suppose. I'm not sure it's a patch that everyone would want. We don't have a way to share patches for things like this. |
13:41 |
Dyrcona |
I also wonder if there is not already a Lp bug for it. |
13:43 |
mdriscoll |
I looked but couldn't find one. Doesn't mean there isn't one. |
13:44 |
mdriscoll |
It would be nice to have the patch somewhere and may be useful to someone else with a similar issue. |
13:45 |
mdriscoll |
I would be happy to write up the LP. |
13:45 |
Dyrcona |
Nope. I searched bugs reported by me including all statuses. |
13:49 |
Dyrcona |
If you want to open a Lp bug, that's fine by me. |
13:53 |
mdriscoll |
Ok I'll write one up. |
13:57 |
jeffdavis |
mdriscoll: while you're here ... I took a look at bug 1818144. I found in our system what I *think* is an Advantage title not shared with the consortium, but the API requests using overdrive-api-checker.pl are returning a 404 with content '{"errorCode":"TitleNotFoundError","message":"The requested title was not found.","token":"<token>"}' |
13:57 |
pinesol |
Launchpad bug 1818144 in Evergreen "Integration with OverDrive API (v.2) needed" [Undecided,Confirmed] https://launchpad.net/bugs/1818144 |
13:57 |
jeffdavis |
I don't know if that's how the API responds or if I just picked a bad example title |
13:58 |
jeffdavis |
or if I'm doing it wrong in some other way :) |
13:59 |
mdriscoll |
jeffdavis: That's interesting. You may need to send the collection token for the Advantage library. |
14:00 |
jeffdavis |
hmm, that would make sense |
14:02 |
mdriscoll |
To do that you use this endpoint: https://api.overdrive.com/v1/libraries/{accountID}/advantageAccounts |
14:03 |
mdriscoll |
To find the collection token that is. |
14:05 |
mdriscoll |
Then resend your query for the title but with the owning library's collection token. |
14:05 |
jeffdavis |
Yes, I was able to grab the right collection token that way and am getting more sensible availability responses now, will update the LP bug. Thanks! |
14:05 |
mdriscoll |
Super! |
14:23 |
jeffdavis |
bug updated |
14:25 |
mdriscoll |
jeffdavis++ |
14:26 |
jeffdavis |
mdriscoll++ # thanks for working on that bug! |
14:28 |
mdriscoll |
Dyrcona: I create bug 2033095. I pretty much scraped the description from an email you sent in 2016. |
14:28 |
pinesol |
Launchpad bug 2033095 in Evergreen "Keyword searches sent over z39.50 treated as exact match searches" [Undecided,New] https://launchpad.net/bugs/2033095 |
14:32 |
Dyrcona |
mdriscoll++ I'll rebase the collab branch (it's about 4 years old) and add it to the bug. |
14:33 |
mdriscoll |
Great I was hoping your would do that. |
14:33 |
mdriscoll |
dyrcona++ |
14:33 |
Dyrcona |
I wonder if we should make a tag on Lp for customization/optional type things? |
14:34 |
Dyrcona |
We probably need a better way than Launchpad to share these things. |
14:38 |
mdriscoll |
Would it be of interest to anyone else working with Autographics? Does the fix break other z39.50 searches or is it harmless? |
14:42 |
Dyrcona |
Well, according to eeevil back in the day, it would break other searches expecting an exact match on the eg indexes in the patch. However, it doesn't seem to be an issue in practice. I don't think Z39.50 is used that much. |
14:43 |
Dyrcona |
It does NOT local staff using Z93.50 to search remote sites, nor does it affect local staff using the local catalog Z39.50 search. |
14:44 |
* eeevil |
reads up |
14:45 |
Dyrcona |
It's old stuff, probably not worth going into much detail on again. |
14:46 |
eeevil |
oh dear... it's too late on a Friday for z search :P |
14:46 |
Dyrcona |
:) |
14:49 |
eeevil |
I read the commit message as "one client is very broken, so we'll not follow the standard instead of telling that client to not be broken" ... what's the client, btw? |
14:50 |
eeevil |
oh, AG |
14:50 |
eeevil |
of course |
14:51 |
Dyrcona |
Well, sometimes it's easier to patch our side than struggle with a vendor. Particularly when every other implementation appears to be broken, too, and "it's only a problem with Evergreen...." |
14:52 |
eeevil |
"how dare you OSS idiots do what the document says to do!" |
14:52 |
Dyrcona |
But, yeah. I'm not arguing to mainline the code. |
14:52 |
Dyrcona |
:) |
14:52 |
Dyrcona |
Well, then there's NCIP.... |
14:53 |
eeevil |
anyway, I hope Z search goes away forever, eventually, because it's terrible. so if we're returning too many results and you can't do a phrase search in EG via Z, then so be it, I suppose |
14:54 |
Dyrcona |
I think mdriscoll just wants the thing findable in LP, so if we leave the bug in a searchable state, we're fine. |
14:54 |
mdriscoll |
What Dyrcona said. |
14:57 |
* Dyrcona |
tries to figure out how to return a set of records with or without copies with or without located URIS, but not with located URIs and no copies. So they can have 0 copies and 0 URIs, or any number of copies, but not any number of URIs and 0 copies. |
14:59 |
mmorgan |
Dyrcona: That's a tall order on a Friday afternoon :) |
14:59 |
Dyrcona |
maybe a union. |
14:59 |
Dyrcona |
Yeah, I don't plan to get it right today. |
15:07 |
mmorgan |
Is it true that there's been no action on porting the view Holds Shelf to Angular? I don't see it in the Angular Circ interface, or a Launchpad bug. |
15:14 |
berick |
mmorgan: hm. i have one. |
15:17 |
mmorgan |
Did I miss finding the lp bug? |
15:17 |
berick |
no. looking at my local commit.. "LPXXX Angular Holds Shelf / Clear Holds" -- never made it to LP |
15:17 |
berick |
i'll post what I have |
15:18 |
berick |
might need a little cleanup |
15:23 |
* mmorgan |
was just looking at bugs for the existing view Holds Shelf, wondering if they would still apply to the Angular version - that doesn't exist yet :) |
15:34 |
pinesol |
News from commits: Docs: LP1775930 updates to conjoined items docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=8c91b2bc9474b2d477100cc6952847461017ae80> |
15:34 |
pinesol |
News from commits: Conjoined items doc <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1b3fd2bef01f071ccc147d56b59b19b4e722e4f9> |
15:43 |
* Dyrcona |
sings along with Ian Astbury: "Open the skyyyyy and let it come down......Here comes the rain!" |
15:44 |
Dyrcona |
Surprise. It's raining here again. |
15:45 |
Dyrcona |
Also, back to my query. I've tried a few things and it doesn't seem to make any difference to the output. The concern is we don't want to send records with only located URIs to our authority/cleanup vendor. |
15:45 |
abneiman |
bah I'm not sure how I did that docs commit twice, but I am bad at git |
15:46 |
Dyrcona |
From what I can tell, we aren't because we limit the records to a single bib source. If I run the query for all of the records created so far this year, and then add code to exclude those where the label is "URI" on the volume, it only drops 1 record. |
15:47 |
Dyrcona |
abneiman: It takes talent to get git to accept the same commit twice in a row. |
15:49 |
Dyrcona |
abneiman: They look like different commits as as git and I are concerned. Maybe I misundestand what's messed up? |
15:49 |
abneiman |
Dyrcona: lest you think I'm actually talented, they are slightly different |
15:50 |
Dyrcona |
S'OK. It's Friday. :) |
15:50 |
abneiman |
I'm not sure how I managed to do it twice - I was trying to do a follow-up (renaming file directory & corresponding path in the doc) but I ended up committing the whole thing, without those changes, and then the whole thing, with those changes /shrug |
15:51 |
abneiman |
I just wanted to commit it once with all the changes |
15:51 |
abneiman |
oh well, as you say, TGIF |
15:51 |
Dyrcona |
abneiman++ |
15:52 |
Dyrcona |
Could be the rename of the file. If you move then edit a file, you have to ad it again. |
15:52 |
Dyrcona |
s/ad/add/ |
15:52 |
abneiman |
ahhh |
15:52 |
abneiman |
that is quite likely it |
15:52 |
abneiman |
Dyrcona++ |
15:52 |
Dyrcona |
Do it the other way around, i.e. edit then move, I don't think you have to add the file twice. |
15:54 |
mmorgan |
Git + Bug Squashing Week + Friday afternoon is a dangerous combination |
15:55 |
abneiman |
mmorgan++ # facts |
15:55 |
Dyrcona |
Throw in Tequila and handguns and you've got a potential disaster. |
15:56 |
mmorgan |
... and rain. |
15:56 |
abneiman |
sounds like the way my neighbors party |
15:57 |
|
stompro joined #evergreen |
15:57 |
Dyrcona |
:) |
15:59 |
Dyrcona |
I was gonna say 'a party' instead of a potential disaster. There's a quote I was think of: https://www.goodreads.com/quotes/52117-a-computer-lets-you-make-more-mistakes-faster-than-any |
16:00 |
mmorgan |
Heh. |
16:03 |
Dyrcona |
Speaking of potential disasters, Banksy said something along the lines of Art isn't art unless it has the potential to be a total disaster. |
16:07 |
mmorgan |
Dyrcona: Glad to hear you got to visit Salem Library! It's a great library! |
16:08 |
Dyrcona |
Yeah, nice place in a nice neighborhood. |
16:09 |
mmorgan |
Love that neighborhood! The coolest architecture! |
16:09 |
Dyrcona |
I was there almost all day Tuesday, and most of yesterday afternoon. |
16:09 |
Dyrcona |
Every other house has a plaque on it. :) |
16:10 |
abneiman |
phasefx++ for additional help with me un-borking git |
16:10 |
mmorgan |
Salem is great - except when it's between you and your place of work in October. |
16:10 |
Dyrcona |
My daughter was working at the Pickering House this summer. She was helping catalog some letters of one of the John Pikcering's. |
16:11 |
Dyrcona |
Yeah, October.... |
16:11 |
Dyrcona |
I think there's so much more of interest in Salem than the witch trials. |
16:12 |
* mmorgan |
generally drives by the Pickering house on my commute. Cool place! |
16:12 |
mmorgan |
Your daughter must find it fascinating! |
16:12 |
Dyrcona |
It's open for tours on Sunday, and they may be looking for new caretakers soonish. |
16:13 |
Dyrcona |
Well, turns out she's distantly related to the Pickerings through her mother, but yeah, she found it interesting. |
16:15 |
Dyrcona |
She's also also transcribing documents in the Gordon College archives this summer. She found the records of the 4th Street Baptist Church from the 1850s amusing. There was a to do about Mrs. Somebody's pew; they kept tabling the discussion to the next meeting for like 2 years, and then their neighbor sued the church for using his air and light. He lost. |
16:16 |
mmorgan |
:) |
16:16 |
mmorgan |
Gordon College - Another great library (though I might be biased) ;-) |
16:16 |
Dyrcona |
:) |
16:19 |
Dyrcona |
They're all great libraries. |
16:19 |
mmorgan |
Indeed! |
16:32 |
StomproJ |
mmorgan, I have something working for saving the call number attributes, I commented on bug 1983156 |
16:32 |
pinesol |
Launchpad bug 1983156 in Evergreen "Allow Call Number attributes in Item Templates option gone" [High,Confirmed] https://launchpad.net/bugs/1983156 - Assigned to Michele Morgan (mmorgan) |
16:33 |
mmorgan |
StomproJ: Awesome! Thanks, I'll have a look! |
16:33 |
mmorgan |
StomproJ++ |
16:35 |
Bmagic |
is anyone available to give this code a looksy? Dyrcona berick StomproJ mmorgan eeevil? commit 5ef0ba5c21edd5e396f0b0806fea92b991999875 Particularly the JS code that reads the library setting from the database. The patch is installed on https://bugsquash2.mobiusconsortium.org - I can see the affected templates with the angular "if" statements, but it's not hiding the barcode box |
16:37 |
Bmagic |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/web/js/ui/default/staff/circ/checkin/app.js;h=c688823b3d071475a9a3d020fdf5bd11cc284f55;hp=0cf3439b09997b524d1df70d24256aa05f438f69;hb=5ef0ba5c21edd5e396f0b0806fea92b991999875;hpb=afcd1cd8b5aa29af8e83c710106d0d0748e1403e |
16:37 |
Bmagic |
setting['ui.circ.hide_patron_strict_barcode'] is null after egCore.org.settings('ui.circ.hide_patron_strict_barcode'). What gives? |
16:40 |
eeevil |
so, settings() expects an array, I think. look just below at the suppress_checkin_popups call |
16:40 |
eeevil |
(and you could just combine those two settings calls into one. and... really should) |
16:40 |
Bmagic |
we checked into that. It's ok to pass it a non-array, there's JS code under the covers that converts it |
16:41 |
Bmagic |
plus, I tried passing it as an array and that didn't fix it |
16:41 |
Dyrcona |
Does the setting exist in the database? Is it set for the current org_unit? |
16:41 |
Bmagic |
yeah, it exists in the DB, and it's set at CONS atm |
16:42 |
mmorgan |
Bmagic: It looks like a name mismatch to me after a quick look. ui.circ.hide_patron_strict_barcode vs. circ.hide_patron_strict_barcode |
16:43 |
eeevil |
mmorgan: the other Hard Thing in compsci! :) |
16:43 |
mmorgan |
looks like circ.hide_patron_strict_barcode is the setting, but the code is looking for ui.circ.hide_patron_strict_barcode |
16:43 |
Dyrcona |
mmorgan++ |
16:43 |
eeevil |
mmorgan++ |
16:43 |
Bmagic |
no way! OMG |
16:43 |
Dyrcona |
It's always the little details. |
16:43 |
eeevil |
Bmagic: but really, please combine that and the next one into one call to the server |
16:43 |
StomproJ |
mmorgan++, nice pattern matching. |
16:44 |
Dyrcona |
Bmagic: Also, what eeevil said. |
16:44 |
Bmagic |
mmorgan++ |
16:44 |
mmorgan |
Dev console: core.bundle.js:1 No server setting type exists for ui.circ.hide_patron_strict_barcode |
16:44 |
* mmorgan |
should quit while ahead!! |
16:45 |
Bmagic |
Dyrcona eeevil: sure! Combining it! Though, scottangel is the dev on this one. It is just one setting. Or at least it should be just one setting |
16:47 |
Dyrcona |
You can get as many settings as you like in one call and up to a point it is more efficient than getting them individually. |
16:48 |
Bmagic |
I'm slowly realizing what you're saying. You're saying: edit the pre-existing code that gets a setting and drop our setting in the array, in order to cut back on the trips to the server |
16:49 |
Dyrcona |
Yeah. Exactly. |
16:51 |
Bmagic |
roger that |
16:54 |
Dyrcona |
I'd say get it working first, then have scottangel combine the code. |
16:59 |
Bmagic |
I updated the setting name in the database on bugsquash2, and violla, like magic, it worked |
17:01 |
Dyrcona |
Well, is changing the setting name in the database the right solution or should the JS code be changed to use the setting name that was in the database? |
17:01 |
Bmagic |
I did that just as a proof of concept. The setting name needs to be updated anyways. We don't like "patron" being in the name |
17:02 |
Dyrcona |
OK. Sounds good to me. I'm signing out. |
17:02 |
Dyrcona |
Have a great weekend, everyone! |
17:02 |
Bmagic |
I think "ui" should be part of the setting name. Other settings use that convention |
17:05 |
pinesol |
News from commits: LP2031935 - Update webservices page with Z39.50 and OAI-PMH <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=24cad8bca4c10d236fe714648fc05103361fc4cd> |
17:06 |
|
mmorgan left #evergreen |
17:33 |
|
stompro joined #evergreen |
23:55 |
|
Guest79 joined #evergreen |