| Time |
Nick |
Message |
| 06:42 |
|
collum joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 10:19 |
|
sandbergja joined #evergreen |
| 11:00 |
|
Christineb joined #evergreen |
| 11:02 |
|
mmorgan joined #evergreen |
| 11:18 |
abneiman |
csharp_: serious question re bug maintenance - what's the reason to mark something Incomplete vs Won't Fix? |
| 11:23 |
abneiman |
(or anyone else with opinions / thoughts on the matter) |
| 11:37 |
|
jihpringle joined #evergreen |
| 11:39 |
Bmagic |
abneiman: do you have an example bug that we marked Incomplete ? |
| 11:40 |
abneiman |
https://bugs.launchpad.net/evergreen/+bug/2130454 |
| 11:40 |
pinesol |
Launchpad bug 2130454 in Evergreen "Holdings View tab: "Show" checkboxes aren't sticky" [Undecided,Incomplete] |
| 11:40 |
abneiman |
https://bugs.launchpad.net/bugs/2107346 |
| 11:40 |
pinesol |
Launchpad bug 2107346 in Evergreen 3.15 "Enhanced MARC Editor - Field tags, indicators, and subfield tags not saving consistently" [High,Incomplete] |
| 11:43 |
Bmagic |
ok, maybe "incomplete" means that the bug report can't be confirmed or replicated. Won't fix is a scenario where the issue is confirmed but (for whatever reason) the community isn't going to fix it. Probably due to the interface aging out. |
| 11:43 |
Bmagic |
does that sound logical? |
| 11:43 |
Bmagic |
csharp_ might have an opinion |
| 11:44 |
abneiman |
I was just curious. There's also "invalid" in the mix of statuses that could be applied to bugs that have aged out |
| 11:44 |
abneiman |
Bmagic++ |
| 11:44 |
mmorgan |
Bmagic: That sounds logical to me. |
| 11:45 |
Bmagic |
Invalid does "mean" / "track" more with the idea that it can't be confirmed |
| 11:45 |
Bmagic |
Maybe "invalid" "feels" too harsh. And it would make the bug report-person feel invalidated :) |
| 11:45 |
Bmagic |
"You've reported an invalid bug" |
| 11:46 |
mmorgan |
Won't fix makes sense to me for legitimate bugs that have aged out. |
| 11:47 |
abneiman |
might be a good hackaway talk |
| 11:47 |
Bmagic |
yep, it would |
| 11:48 |
Bmagic |
I have a question of my own, I'd like to ask |
| 11:49 |
Bmagic |
3.15: when switching from an AngularJS to an Angular interface (/eg/* -> /eg2/*) for example from patron search to search the catalog, I'm seeing a short delay in the loading screen. As much as 5 seconds of a white screen |
| 11:50 |
Bmagic |
watching the browser console closely, I see it hangs at "open-ils.pcrud.search.aou" for a bit before moving on. Looking deeper, it's waiting to get the org tree. It's worse on systems with more OU's of course. |
| 11:51 |
Bmagic |
confirmed this behavior on two different systems, both on 3.15.x. I understand that pcrud caches the aou request? Maybe the delay is somewhere in the construction of the large JSON response? |
| 11:54 |
eeevil |
pcrud does not cache anything. however, if either the ang or angjs UIs are not using the existing org tree cache in the BROWSER, that's an issue (and a problem for the org service to solve) |
| 11:55 |
Bmagic |
eeevil: is there a way to tell if my browser is using it's own cache or not? |
| 11:56 |
eeevil |
IOW, when you log in, the org service for the version of the page you enter through "absorb" the org tree. either every time, or after a cache invalidation time, I don't recall which. but it happens up front either /at/ login or the first time you hit a page that needs the org tree |
| 11:56 |
eeevil |
they share that cache -- it's the same data for the UIs, of course |
| 11:57 |
eeevil |
so, something on the UI side is either not seeing the cached data, or you're hitting the first page after login that needs the org tree and it's either not cached or expired |
| 11:57 |
Bmagic |
if I see a websockets request in the browser dev tools, then that means that the browser isn't consulting it's cache? |
| 11:57 |
eeevil |
no, it's not the built-in browser cache |
| 11:57 |
eeevil |
it's the indexeddb cache that we build |
| 11:58 |
Bmagic |
I see, so I would see the websockets request, just after the request, somewhere before firing off the request over the internet, it supplies the answer internally? |
| 12:01 |
* csharp_ |
appears |
| 12:03 |
csharp_ |
abneiman: I go by this (or my working memory of it): https://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq |
| 12:03 |
csharp_ |
Incomplete - The bug report is missing important information preventing it from being fixed. The submitter should be notified to provide additional information. |
| 12:03 |
csharp_ |
Won't Fix - Bug will not be fixed. Reasons may vary. |
| 12:04 |
csharp_ |
in the case of bug 2130454, jihpringle tested and could not reproduce, so I marked Incomplete |
| 12:04 |
pinesol |
Launchpad bug 2130454 in Evergreen "Holdings View tab: "Show" checkboxes aren't sticky" [Undecided,Incomplete] https://launchpad.net/bugs/2130454 |
| 12:05 |
csharp_ |
similar situation with bug 2107346 - the most recent comments indicate they aren't seeing the reported issue |
| 12:05 |
pinesol |
Launchpad bug 2107346 in Evergreen 3.15 "Enhanced MARC Editor - Field tags, indicators, and subfield tags not saving consistently" [High,Incomplete] https://launchpad.net/bugs/2107346 |
| 12:06 |
csharp_ |
also, just for the record, I'm cool with other people deciding that I'm wrong about choosing a status, etc. - it actually kind of happens a lot :-) |
| 12:06 |
csharp_ |
I just don't want to keep a bug in "New" or "Confirmed" if it doesn't appear to still be a real bug in recent testing |
| 12:07 |
csharp_ |
</my_opinion> |
| 12:08 |
csharp_ |
agreed that a review of statuses/wrangling expectations would be useful |
| 12:11 |
abneiman |
csharp_++ |
| 12:11 |
abneiman |
thanks! |
| 12:14 |
csharp_ |
re: 11:45 < Bmagic> Maybe "invalid" "feels" too harsh. And it would make the bug report-person feel invalidated :) |
| 12:14 |
csharp_ |
I think Invalid should just mean "the wrangler has determined that this is not a bug" |
| 12:14 |
csharp_ |
just-now example 2130669 |
| 12:14 |
csharp_ |
bug 2130669 |
| 12:14 |
pinesol |
Launchpad bug 2130669 in Evergreen "Wishlist: User permission specific to OPAC Alert library setting" [Undecided,Invalid] https://launchpad.net/bugs/2130669 |
| 12:15 |
csharp_ |
maybe include in any bug discussion: "try not to take bug statuses personally" |
| 12:16 |
csharp_ |
or maybe I'm just a heartless SOB |
| 12:23 |
csharp_ |
huh - was just searching the docs and don't see documentation on how you'd add a perm to an org unit setting |
| 12:24 |
csharp_ |
unless my antora search-fu is just bad |
| 12:33 |
csharp_ |
added a bug comment with bare-bones instructions: https://bugs.launchpad.net/evergreen/+bug/2130669/comments/3 |
| 12:33 |
pinesol |
Launchpad bug 2130669 in Evergreen "Wishlist: User permission specific to OPAC Alert library setting" [Undecided,Invalid] |
| 12:34 |
csharp_ |
re-marked the bug Confirmed with an added tag of documentation |
| 12:35 |
csharp_ |
this bug is a freakin' roller coaster y'all |
| 14:50 |
Bmagic |
csharp_++ |
| 15:09 |
Bmagic |
anyone have any ideas on deleting a bib that has an 856? Evergreen is throwing an error about holdings. There are none, other than the 856 |
| 15:17 |
csharp_ |
Bmagic: what's the error? |
| 15:18 |
Bmagic |
"holding is not empty" |
| 15:18 |
csharp_ |
hmm |
| 15:19 |
Bmagic |
the perl code clearly shows a check for non deleted call numbers |
| 15:21 |
csharp_ |
Bmagic: looking for the code - is it AssetCommon.pm? |
| 15:21 |
Bmagic |
the server call is record_entry.delete |
| 15:21 |
Bmagic |
Cat.pm around line 1363 |
| 15:23 |
csharp_ |
so 'select count(*) from asset.call_number where not deleted and record = <rec_id>' shows no rows? |
| 15:23 |
Bmagic |
it shows rows, yes, but only ##URI## |
| 15:23 |
csharp_ |
ah |
| 15:24 |
Bmagic |
so, when a cataloger wants to delete a bib that has one 856, obviously they want to delete the call number associated with the 856 too |
| 15:26 |
csharp_ |
possible to remove the call numbers first? |
| 15:26 |
csharp_ |
or maybe I'm misunderstanding the workflow |
| 15:27 |
Bmagic |
well, yes, it's possible to delete the call numbers first. Which requires an edit to the MARC, deleting the 856, then* deleting the bib |
| 15:27 |
csharp_ |
oh hmm |
| 15:27 |
Bmagic |
seems like more work than it should be to delete an otherwise empty bib |
| 15:28 |
csharp_ |
so maybe some sort of cascading deletion feature is needed? |
| 15:28 |
Bmagic |
I'm looking at this line: my $vols = $e->search_asset_call_number({record=>$rec_id, deleted=>'f'}); |
| 15:29 |
Bmagic |
It seems to me that it should make exceptions for '##URI##' volumes and not includes those in the check |
| 15:29 |
csharp_ |
or more properly, delete them if they exist? |
| 15:29 |
Bmagic |
that would presumabely happen later |
| 15:30 |
csharp_ |
around line 750 in that same pm there are examples of excluding ##URI## call numbers |
| 15:31 |
Bmagic |
nice, that makes the proposed change pretty straightforward |
| 15:31 |
csharp_ |
so the check would be for "real" call numbers (non URI), then remove the URI ones as you delete the bib? |
| 15:31 |
Bmagic |
add this to the editor call: , label => { '<>' => '##URI##' } |
| 15:32 |
Bmagic |
and then we're past the volume check |
| 15:32 |
csharp_ |
this assumes there's no inherent value in the '##URI##' cns other than being phantom holdings for the bib being deleted |
| 15:32 |
Bmagic |
I'm having a hard time believing that this is the first time this has come up |
| 15:33 |
csharp_ |
yeah, sounds pretty basic |
| 15:33 |
csharp_ |
maybe it is an unusual workflow |
| 15:33 |
csharp_ |
we don't do much with URI-ish records in PINES |
| 15:33 |
csharp_ |
ain't nobody got time for that |
| 15:33 |
Bmagic |
deleting a record that happens to have an 856? Seems like something a cataloger would do on the regular |
| 15:33 |
* csharp_ |
shrugs :-) |
| 15:34 |
Bmagic |
I guess I'll file a bug |
| 15:34 |
csharp_ |
Bmagic++ |
| 15:34 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1387725 |
| 15:34 |
pinesol |
Launchpad bug 1387725 in Evergreen "Bibliographic record merging for electronic resources should delete Located URIs" [Medium,Confirmed] |
| 15:35 |
Bmagic |
that's an oldie |
| 15:37 |
csharp_ |
oh, I guess the thing we don't do is the located URIs |
| 15:38 |
Bmagic |
funny: that's very popular in my world |
| 15:38 |
csharp_ |
maybe they shouldn't be volumes but something different, like monograph parts? |
| 15:38 |
Bmagic |
that notion would be a huge change in the code |
| 15:39 |
csharp_ |
asset.located_uri - treated differently? |
| 15:39 |
csharp_ |
yeah, obviously have zero investment beyond this discussion :-) |
| 15:40 |
Bmagic |
I'm verifying that deleting a bib (via delete from biblio.record_entry) will trigger-delete the volumes |
| 15:43 |
Bmagic |
it does not |
| 15:45 |
Bmagic |
I'm testing that little switcharoo in the $vols check |
| 15:49 |
Bmagic |
I think it's well overdue that Evergreen automatically delete it's URI's when BRE is deleted |
| 15:50 |
Bmagic |
imma fix it |
| 15:52 |
Bmagic |
found a couple old related bugs: https://bugs.launchpad.net/evergreen/+bug/761085 https://bugs.launchpad.net/evergreen/+bug/761130 |
| 15:52 |
pinesol |
Launchpad bug 761085 in Evergreen "cannot delete bib with ##URI## volumes" [Undecided,Invalid] |
| 15:52 |
pinesol |
Launchpad bug 761130 in Evergreen "immortal ##URI## entries in asset.call_number and related entries in asset.uri" [Undecided,Fix released] - Assigned to Dan Scott (denials) |
| 15:58 |
Bmagic |
I'm second guessing myself the more I read the history. I guess the community wants Evergreen to not* allow bibs to be deleted when there's an 856? The thinking is that maybe the cataloger doesn't realize it's an electronic bib? |
| 15:58 |
Bmagic |
or perhaps preventing automatic deletion due to library settings such as "Delete bib when empty"? |
| 15:58 |
csharp_ |
maybe a good hackaway candidate? |
| 15:59 |
csharp_ |
if we're not already booked with ALL THE THINGS |
| 16:04 |
jihpringle |
for manual deletions maybe it just needs an "are you absolutely sure you want to delete this record that has URIs?" prompt |
| 16:04 |
Bmagic |
the hackaway agenda was empty as far as I could tell? https://wiki.evergreen-ils.org/doku.php?id=hack-a-way:hack-a-way-2025 |
| 16:08 |
Bmagic |
jihpringle: Are you agreeing that the reason for blocking the deletion is to prevent catalogers from deleting a bib not realizing that it's electronic? |
| 16:09 |
jihpringle |
yes, that would be our concern - though I don't think our libraries delete records very often |
| 16:10 |
Bmagic |
a warning message would be nice |
| 16:10 |
jihpringle |
I'm always in favour of a warning notice when something is going to be deleted :D |
| 16:10 |
Bmagic |
I think* that means we need to implement the permission ".override" mechanism? |
| 16:13 |
jihpringle |
it makes sense in this situation to have a perm to control whether an e-record can be deleted |
| 16:14 |
Bmagic |
maybe if you have bib cataloging powers, that's enough, and we just need to offer that one warning message as a double check. No extra permission required? |
| 16:15 |
jihpringle |
I'd be in favour of the specific perm - all it takes is for one person who can edit a bib to delete a record that has 50 URIs on it when trying to remove it just for their library |
| 16:16 |
Bmagic |
yeah, that'd be bad |
| 16:16 |
jihpringle |
for context, we only have two cataloguing levels - copy editor and full cataloguing access |
| 16:16 |
jihpringle |
I think it would be less of a worry for a consortia with more granular cataloguing perm groups |
| 17:12 |
|
mmorgan left #evergreen |
