| Time |
Nick |
Message |
| 00:00 |
|
sandbergja joined #evergreen |
| 03:11 |
|
yar joined #evergreen |
| 05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 05:37 |
|
yar joined #evergreen |
| 07:07 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 08:19 |
|
bos20k joined #evergreen |
| 08:45 |
|
Dyrcona joined #evergreen |
| 08:54 |
|
bos20k joined #evergreen |
| 09:21 |
|
aabbee joined #evergreen |
| 09:21 |
|
Christineb joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 10:17 |
|
sandbergja joined #evergreen |
| 11:09 |
JBoyer |
Maybe someone here can tell me if I'm mis-remembering. I was under the impression that TCNs were set on initial import and then essentially never touched again, even if you edit the 001 or anything like that. Am I having a fever dream? |
| 11:25 |
|
khuckins joined #evergreen |
| 12:03 |
Dyrcona |
JBoyer: There *might* be a trigger for that. |
| 12:04 |
Dyrcona |
Too many triggers on that table if you ask me, which you didn't. |
| 12:05 |
JBoyer |
There are multiple, and an OUS and a global flag to mix in. |
| 12:06 |
JBoyer |
What I'm seeing is that since last Monday (our latest update to 3.2.mumble) is that now every time you click Save whatever happens to be in the 001 is turned into the tcn, even if you don't actually edit the marc. |
| 12:07 |
Dyrcona |
That hasn't been happening to us on 3.2.4+backports |
| 12:07 |
JBoyer |
The fact that we've had the "Maintain 001, 003, and 005 according to the MARC Specification" enabled for quite some time means that now we're playing TCN musical chairs suddenly. |
| 12:08 |
Dyrcona |
Or, rather, no one has noticed if it has. |
| 12:08 |
JBoyer |
I suspect that if that setting were never enabled at a site nothing would happen, since the 001 would always be what you initially brought in anyway. |
| 12:10 |
Dyrcona |
I'm not certain what that setting does, because I don't know the labels, just the database names. We have it set to use the id as the TCN. |
| 12:10 |
JBoyer |
Oh yeah, sorry. |
| 12:11 |
JBoyer |
with that setting turned on, the 001 is set to the bre.id, the 003 is set to the root of your consortium (it would be the owning lib if bibs were scoped that way), and the 005 is just the last edit date |
| 12:11 |
Dyrcona |
So, that's what we're doing, IIRC. |
| 12:12 |
JBoyer |
The end result being that you could import a record with an OCLC tcn, and then the first time it's edited locally the tcn switches to the id, which makes people who want to look things up by OCLC TCN extremely unhappy. |
| 12:13 |
Dyrcona |
Actually, the TCN is changed on import, IIRC. |
| 12:13 |
JBoyer |
But yeah, if you're using the bre.id == tcn setting then your system is doing this intentionally and that's fine. |
| 12:14 |
Dyrcona |
We did it at MVLC because there were too many duplicate TCNs from OCLC in our legacy system. |
| 12:15 |
Dyrcona |
I believe it's done at CW MARS for similar reasons, plus LoC "recommends" it. |
| 12:15 |
JBoyer |
But we weren't and now it's starting to flip things anyway, which is increasingly irritating. (especially since some TCNs are "just" database ids from other non-OCLC systems, waiting like little time bombs to prevent you from saving bib edits because record A's id number was already record B's foreign tcn...) |
| 12:16 |
Dyrcona |
You have verified that the flag is turned off? |
| 12:16 |
JBoyer |
That makes sense, since all it is is someone else's database id, but apparently people get very attached to OCLC's database ids. :/ |
| 12:16 |
JBoyer |
Very much. |
| 12:17 |
Dyrcona |
DIGO... :) |
| 12:17 |
JBoyer |
DIGO is a new one on me. |
| 12:17 |
Dyrcona |
Data In/Garbage Out. :) |
| 12:18 |
JBoyer |
Ah. |
| 12:18 |
Dyrcona |
That sounds like a bug, obviously. I'd start by checking that the database triggers are all there and are correct on the bre table. |
| 12:19 |
JBoyer |
That's the worst part, I looked at all of the diffs from what I loaded and nothing appeared to touch any of that. Much irritation. |
| 12:19 |
Dyrcona |
I was gonna say, GIGO, but thought DIGO captured the meat grinder effect of cataloging better. :) |
| 12:19 |
JBoyer |
But yeah, I'll give everything another once over and then just throw what I know at LP and see what happens. |
| 12:20 |
JBoyer |
I suppose now would be a good time to make sure csharp sees this though, I wouldn't want to be in the state if / when this started happening there. |
| 12:36 |
* csharp |
feels inescapable pull to look at #evergreen for some reason... |
| 12:37 |
|
sandbergja joined #evergreen |
| 12:37 |
csharp |
JBoyer: has anyone been monkeying around with match sets? might be that some sort of dupe checking got borked |
| 12:38 |
JBoyer |
Nope, this is open a record from an opac search, click the edit tab, click Save, lose you TCN. |
| 12:39 |
csharp |
ouch |
| 12:39 |
JBoyer |
Which I finally made myself take the time to verify against one of our other test installs and of course that doesn't happen, so it's time for some spelunking fun... |
| 12:39 |
csharp |
sorry :-( |
| 12:40 |
rjackson_isl |
spelunking used to be fun - several decades ago... |
| 12:40 |
csharp |
it is ringing some sort of bell - maybe we saw something like that during our test phase |
| 12:40 |
* csharp |
blows the dust off 3.2 testing issue spreadsheet |
| 12:43 |
csharp |
JBoyer: probably not it, but can you verify that the fix for https://bugs.launchpad.net/evergreen/+bug/1764542 was applied? |
| 12:43 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Fix released] |
| 12:43 |
csharp |
should have been included in 3.2.2+ |
| 12:45 |
JBoyer |
I'm 1000% certain that's already in our db, because I applied that one the day *after* we upgraded to a version affected by it. I believe you helped me narrow down what was happening while everything was aflame. |
| 12:46 |
csharp |
ah |
| 12:47 |
JBoyer |
Whatever changed would have to have been committed within the last couple of months, I lost track of what commits to rel_3_2 were added during that update, it may have been more than the ones rebased in that morning. |
| 12:47 |
csharp |
I seem to remember a UI issue that had similar symptoms to what you're describing |
| 12:47 |
JBoyer |
I'll sift through the logs and see if anything stands out. |
| 12:47 |
csharp |
might be worth adding JS-level console.logs too |
| 12:48 |
JBoyer |
There still are display issues with TCN labels and bib id values in the Z39.50 importer, but that's just a UI issue, it isn't doing anything crazy. |
| 12:48 |
csharp |
Elaine is out today - otherwise I'd ask her about it |
| 12:58 |
|
yboston joined #evergreen |
| 13:14 |
dbwells |
JBoyer: I am interested in testing what you are seeing, but not sure I understand. You are saving a record and seeing tcn_value in biblio.record_entry get updated somehow? |
| 13:15 |
JBoyer |
Aha. commit 4877cfe904483e181697cc48754395f34f28faf9 changed a pcrud.update call to an open-ils.cat.biblio.record.marc.replace api call for record edits. And sub biblio_record_replace_marc in Open-ILS/Application/Cat/Bibcommon.pm cares very much about tcns. |
| 13:15 |
pinesol |
JBoyer: [evergreen|Bill Erickson] LP1693580 Marc editor notify and API changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4877cfe> |
| 13:16 |
JBoyer |
dbwells, What was happening here was that we had the "Cat: Maintain 001/003/035 according to the MARC21 specification" global flag enabled, and the "Cat: Use Internal ID for TCN Value" global flag disabled. |
| 13:17 |
JBoyer |
So when we would import records from OCLC (for example) the record's TCN would be set to the old value of the 001, and the new record would have its 001 set to the Eg database id. |
| 13:18 |
JBoyer |
Subsequent edits never seemed to change the TCN (which makes me wonder if the XUL client used that api or another for it's bib updates?) even if you change or remove the 001. |
| 13:19 |
JBoyer |
After we updated to a version that included that commit, any edit to a record that had an 001 of its bib id but another value in its TCN would have it's TCN changed to match the bib id. |
| 13:20 |
dbwells |
JBoyer: Thanks for explanation. And yes, FWIW, we're seeing the same behavior. |
| 13:21 |
JBoyer |
(I'm not sure why I thought it was looking at the 005 earlier, I should have looked it up.) |
| 13:23 |
dbwells |
Seems like a problem to me as well. If the tcn_value isn't stable, it doesn't have much point. |
| 13:24 |
JBoyer |
I'm half wondering if you're not supposed to maintain control numbers according to the marc21 spec, unless you're ALSO planning to use the bib id for the TCN anyway. |
| 13:24 |
|
jamesrf joined #evergreen |
| 13:24 |
JBoyer |
Otherwise you've got 2 settings, one that means "set TCN = bre.id now" and one that means "set TCN = bre.id at some later undetermined time" |
| 13:25 |
JBoyer |
I'll try to see what was going on in the xul editor and why this never seemed to happen in the past. |
| 13:26 |
dbwells |
JBoyer: Also, I am curious, have you seen benefits to having the "Cat: Maintain 001/003/035 according to the MARC21 specification" global flag enabled? Ours is off, as I've never understood the practical value (while having minor costs for some workflows). |
| 13:28 |
JBoyer |
Unfortunately I don't have any good documentation as to when / why it was enabled. I suspect it's going to stay disabled and I'm probably going to have to strip out every 001 and 003 in our database, unless this is actually a significant deviation from the way things used to work. |
| 13:28 |
JBoyer |
Now my eventual LP bug is more likely going to be about tying those two things together more closely than the fact that the editor is behaving differently. |
| 13:31 |
dbwells |
JBoyer++ |
| 13:32 |
JBoyer |
Thanks for the feedback/help everyone. |
| 13:32 |
JBoyer |
Dyrcona++ |
| 13:32 |
JBoyer |
csharp++ |
| 13:32 |
JBoyer |
dbwells++ |
| 13:35 |
|
stephengwills joined #evergreen |
| 13:51 |
|
_sandbergja joined #evergreen |
| 14:10 |
gmcharlt |
berick: _sandbergja: dbwells: I've got a big set of Angular pull requests out now that I'd appreciate review of |
| 14:10 |
gmcharlt |
the branch is collab/gmcharlt/angular-widget-improvements-2019-06 |
| 14:10 |
gmcharlt |
and the bugs it addresses are |
| 14:10 |
gmcharlt |
bug 1831780 |
| 14:10 |
pinesol |
Launchpad bug 1831780 in Evergreen "angular: improvements to date-select" [Wishlist,New] https://launchpad.net/bugs/1831780 |
| 14:10 |
gmcharlt |
bug 1831781 |
| 14:10 |
pinesol |
Launchpad bug 1831781 in Evergreen "angular: add eg-help-popover component" [Wishlist,New] https://launchpad.net/bugs/1831781 |
| 14:10 |
gmcharlt |
bug 1831783 |
| 14:10 |
pinesol |
Launchpad bug 1831783 in Evergreen "angular: improvements to org-select" [Wishlist,New] https://launchpad.net/bugs/1831783 |
| 14:11 |
gmcharlt |
bug 1831784 |
| 14:11 |
pinesol |
Launchpad bug 1831784 in Evergreen "angular: fix formatting of dob (date of birth) field" [Medium,New] https://launchpad.net/bugs/1831784 |
| 14:11 |
gmcharlt |
bug 1831785 |
| 14:11 |
pinesol |
Launchpad bug 1831785 in Evergreen "angular: add automatic pcrud-based data sources to eg-combobox" [Wishlist,New] https://launchpad.net/bugs/1831785 |
| 14:11 |
gmcharlt |
bug 1831786 |
| 14:11 |
pinesol |
Launchpad bug 1831786 in Evergreen "angular: add demo of cross-tab communications" [Wishlist,New] https://launchpad.net/bugs/1831786 |
| 14:11 |
gmcharlt |
and last but definitely not least, bug 1831788 |
| 14:11 |
pinesol |
Launchpad bug 1831788 in Evergreen "angular: add filtering, sticky headers, and other improvements to eg-grid" [Wishlist,New] https://launchpad.net/bugs/1831788 |
| 14:12 |
gmcharlt |
given the obvious potential for repeated rebasing issues, I'd appreciate prompt review |
| 14:12 |
_sandbergja |
phew, that's a lot! |
| 14:12 |
_sandbergja |
gmcharlt++ |
| 14:12 |
gmcharlt |
in turn, I'm more than happy to do the same for other patches that touch base Angular components for eg2 |
| 14:13 |
_sandbergja |
These will be fun to review. :-D |
| 14:37 |
|
pinesol` joined #evergreen |
| 14:50 |
_sandbergja |
...and that's the first time I've ever been rickrolled by a commit message |
| 14:53 |
JBoyer |
Never gonna delete your branch, never gonna conflict your merge, never gonna revert you... |
| 14:53 |
JBoyer |
(needs some work.) |
| 14:54 |
_sandbergja |
JBoyer++ |
| 14:56 |
|
sandbergja joined #evergreen |
| 14:58 |
|
yboston joined #evergreen |
| 15:10 |
gmcharlt |
_sandbergja++ # looking at the patches |
| 15:11 |
gmcharlt |
needless to say, while the rickroll is amusing at this point in the process, I certainly have no objection to swapping out that example help-popover link to example.org or evergreen-ils.org |
| 15:14 |
_sandbergja |
gmcharlt: I have only started to peek at these, but I do have a philosophical question about the validation in the date-select widget |
| 15:14 |
gmcharlt |
_sandbergja: go for it |
| 15:15 |
_sandbergja |
Angular has some pretty cool validation functionality built-in, especially if we use reactive forms |
| 15:15 |
_sandbergja |
I'm wondering if we should start inching our way in that direction |
| 15:16 |
_sandbergja |
(see also bug 1831390) |
| 15:16 |
pinesol |
Launchpad bug 1831390 in Evergreen "Make Angular combobox, date-select, etc. implement ControlValueAccessor" [Undecided,New] https://launchpad.net/bugs/1831390 |
| 15:17 |
* jeff |
scratches head at a failure of the catalog search iframe to load |
| 15:17 |
_sandbergja |
(not that adding validation powers to date-select means that we can't also start investigating Angular's Validators too) |
| 15:17 |
jeff |
incognito window seemed to fix it but then i reproduce it in that tab also after a reload or two. |
| 15:17 |
gmcharlt |
_sandbergja: yeah, I think we have a decision to make about either fully adopting Bootstrap form validation or Reactive Forms and ideally sticking with just one approach |
| 15:18 |
jeff |
(just talking aloud, don't mind me) |
| 15:18 |
gmcharlt |
but in the short term, for that specific patch, I kinda view as at least it adding a form-validated signal for noting that we've got a form to convert later |
| 15:19 |
_sandbergja |
that makes sense |
| 15:19 |
_sandbergja |
thanks for talking it through with me! |
| 15:20 |
_sandbergja |
Perhaps we can talk about bootstrap validation vs. Angular validation at a developer meeting soon. |
| 15:21 |
gmcharlt |
sure, toss it on the agenda |
| 15:24 |
jeff |
oh neat. after upgrading from Chrome 74 to Chrome 75 on another machine, i see the same issue. |
| 15:24 |
jeff |
...but not always, so we'll hope that's a red herring. |
| 15:34 |
Dyrcona |
gmcharlt++ # I was gonna take care of that ssh key request after I did something else, but forgot about it. |
| 15:44 |
|
khuckins_ joined #evergreen |
| 15:51 |
jeff |
neat. loading /eg/staff/cat/catalog/index the first time works. select Cataloging -> Search the Catalog, end up with an iframe that contains itself (because 3.1.x, and no commit 554e7a1 / bug 1797923). |
| 15:51 |
pinesol |
jeff: [evergreen|Bill Erickson] LP#1797923 Browser client iframe initial loading page - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=554e7a1> |
| 15:51 |
pinesol |
Launchpad bug 1797923 in Evergreen 3.1 "Browser client iframe (catalog, etc.) loading page" [Medium,Fix released] https://launchpad.net/bugs/1797923 |
| 15:52 |
jeff |
empty cache and hard reload with devtools open, success -- get search screen. |
| 15:52 |
jeff |
select Cataloging -> Search the Catalog... nested iframe again. |
| 15:52 |
gmcharlt |
jeff: <iframe loading="eager"> ? |
| 15:53 |
Dyrcona |
Meh.... Template's a mess.. I need some key strokes to match END with the construct that it's closing..... |
| 15:53 |
jeff |
gmcharlt: possibly! testing! |
| 15:54 |
jeff |
gmcharlt++ even if this isn't the issue... |
| 15:54 |
gmcharlt |
yeah, BigRig just mentioned the advent of lazy loading in Chrome 75 as being a potential problem |
| 15:55 |
jeff |
i see more Canary Yellow in my future |
| 15:59 |
jeff |
alas, simply adding loading="eager" to templates/staff/share/t_eframe.tt2 didn't seem to resolve the current symptoms. |
| 15:59 |
jeff |
(again, this is 3.1, not master/etc) |
| 16:07 |
jeff |
potentially: https://bugs.chromium.org/p/chromium/issues/detail?id=971368 |
| 16:23 |
jeff |
trying to find the issue/commit where they fixed it. |
| 16:24 |
jeff |
but I think I'm going to try adding the loading page bug 1797923 and if needed play with setTimeout as a workaround (which hopefully isn't needed because I'm not sure it will be simple) |
| 16:24 |
pinesol |
Launchpad bug 1797923 in Evergreen 3.1 "Browser client iframe (catalog, etc.) loading page" [Medium,Fix released] https://launchpad.net/bugs/1797923 |
| 16:28 |
jeff |
Slightly good news is that I can't seem to get it to break on one of Bmagic's hosts, https://bugsquash.missourievergreen.org/eg/staff/cat/catalog/index |
| 16:37 |
jeff |
That seems to have done the trick. |
| 16:42 |
jeff |
er, I also left loading="eager" in there... unclear if it's required, but I'd be interested to hear more about BigRig's experience there. |
| 16:44 |
jeff |
so, looking at that bug it's likely anyone on 3.1.7 or higher was not even affected. |
| 16:44 |
BigRig |
jeff not much experience. It was reported by a customer. I upated my chrome to v75 and did not get any issues. but I did not really do an indepth testing. |
| 16:44 |
BigRig |
that might explain why I did not have any issues. |
| 17:24 |
|
yar joined #evergreen |
| 17:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 17:49 |
|
jonadab joined #evergreen |
| 17:49 |
|
yboston joined #evergreen |
| 17:53 |
|
jamesrf joined #evergreen |
| 18:06 |
|
egbuilder joined #evergreen |
| 18:08 |
|
jweston joined #evergreen |
| 19:29 |
|
jamesrf joined #evergreen |
| 19:33 |
|
stephengwills joined #evergreen |
| 20:02 |
|
stephengwills joined #evergreen |
| 20:33 |
|
yar joined #evergreen |
| 20:43 |
|
jamesrf joined #evergreen |
| 22:19 |
|
jamesrf joined #evergreen |
| 23:02 |
|
sandbergja joined #evergreen |
| 23:44 |
|
jamesrf joined #evergreen |
