| Time |
Nick |
Message |
| 07:41 |
|
collum joined #evergreen |
| 07:45 |
JBoyer |
Coming in late to the JSON discussion, but I suspect jsonb totally fine for use in the *_settings tables. The whitespace that's lost is between tokens; it's not like it would strip stings, and if we're depending on key order for anything today then we're probably just doing json wrong. (Want to change the order they appear in a dropdown? .keys().sort() or whatever) |
| 07:45 |
JBoyer |
Similar for losing duplicate keys, if losing dupes causes problems then that needs addressed by losing that dependency. |
| 08:18 |
|
BDorsey joined #evergreen |
| 08:22 |
|
kworstell-isl joined #evergreen |
| 08:40 |
|
rfrasur joined #evergreen |
| 08:46 |
csharp_ |
JBoyer++ # I was thinking the same thing |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:51 |
csharp_ |
and to clarify, I'm not necessarily advocating for JSONB, and if I were, it wouldn't be to make JSON updates easier, but it sounds like it's worth considering for other reasons |
| 09:58 |
|
sleary joined #evergreen |
| 10:40 |
csharp_ |
today in cool git stuff: if you change branches, you can do "git checkout -" to get back to the previous branch (much like "cd -") |
| 10:40 |
pinesol |
News from commits: LP2018694: remove unused npm package ngx-i18nsupport <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=72941bf986f059451822badf40aae7135fcbc038> |
| 10:42 |
csharp_ |
my current use case: developing a new feature and wanted to rebase against current main - git checkout main, git pull, git checkout -, git rebase -i origin/main |
| 10:43 |
jeff |
i think you could also accomplish that with: git fetch origin && git rebase -i origin/main |
| 10:44 |
csharp_ |
does fetch apply the commits to the local copy? |
| 10:44 |
jeff |
it does not. |
| 10:44 |
csharp_ |
or is origin/main referring to the remote? I've always assumed origin/main was local |
| 10:44 |
jeff |
which is why I prefer it, though the git-pull behavior has changed in a few ways since I stopped using it. |
| 10:45 |
csharp_ |
as in, I'm unclear on the difference between "origin main" and "origin/main" |
| 10:48 |
berick |
origin/main is the "main" branch on the remote called "origin" |
| 10:48 |
berick |
i.e. not local |
| 10:49 |
jeff |
right. not a local branch, but the data exists locally thanks to the fetch. |
| 10:49 |
csharp_ |
https://stackoverflow.com/a/18137512 - seems to confirm what I thought, but I'll play around with it |
| 10:49 |
csharp_ |
I see |
| 10:49 |
csharp_ |
yeah, that makes sense |
| 10:50 |
csharp_ |
so fetching does update origin/main locally, but doesn't affect "main" |
| 10:50 |
* csharp_ |
eyes rolling around in head |
| 10:51 |
jeff |
to help further that eyeroll, you can (and should not) create a local branch called origin/main |
| 10:51 |
csharp_ |
haha |
| 10:51 |
jeff |
in which case, when you do something like "git rebase origin/main" you'll have warnings: |
| 10:51 |
berick |
hah, we gonna say the same |
| 10:51 |
jeff |
warning: refname 'origin/main' is ambiguous. |
| 10:51 |
jeff |
warning: refname 'origin/main' is ambiguous. |
| 10:52 |
csharp_ |
I can see why I hated git when we first started using it |
| 10:52 |
csharp_ |
that would have been absolutely incomprehensible back then |
| 10:53 |
csharp_ |
@love git |
| 10:53 |
pinesol |
csharp_: But csharp_ already loves git! |
| 10:53 |
jeff |
(Branch contained (ambiguous) live bobcat. Would not buy again.) |
| 10:53 |
csharp_ |
@love git more |
| 10:53 |
pinesol |
csharp_: The operation succeeded. csharp_ loves git more. |
| 10:54 |
csharp_ |
https://www.youtube.com/watch?v=OYIKdQcqbjI |
| 10:58 |
csharp_ |
@dunno add it's origin/main all the way down |
| 10:58 |
pinesol |
csharp_: The operation succeeded. Dunno #78 added. |
| 11:13 |
jeff |
and what's more fun than creating an ambiguous branch named origin/main? |
| 11:13 |
jeff |
(deleting it!) |
| 11:13 |
jeff |
(thankfully, it's not ambiguous in that context.) |
| 11:21 |
|
mantis1 joined #evergreen |
| 11:23 |
mantis1 |
As anyone had any problems with an issuance failing to receive on the staff side but the existing item entry in serial.issuance exists? |
| 11:30 |
|
Christineb joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:29 |
csharp_ |
mantis1: we don't use serials, but I would look at the logs (if available) for when the item was processed - maybe something went wrong then system-wise |
| 12:36 |
mantis1 |
csharp++ |
| 12:36 |
mantis1 |
one other question |
| 12:37 |
mantis1 |
'One library wants to know when an item is marked Lost after being marked missing. Whatever is set up in the notification / action triggers should determine the marking lost, but if it is marked "missing" before the system marks it lost, does Evergreen mark an item Lost after a period?' |
| 12:39 |
mantis1 |
tldr: Does an item go into Lost status after marked as Missing? |
| 12:39 |
jihpringle |
mantis1 - I wouldn't think a missing item goes to lost - at least the way we use it missing means you can't find the item in the library, lost means the patron has never returned it (missing doesn't have the connection to the patron that lost does) |
| 12:40 |
jihpringle |
I would be more inclined to think that claimed returned goes to lost (but I don't know if that can be done automatically) |
| 12:41 |
mantis1 |
I didn't think so either |
| 12:43 |
mantis1 |
jihpringle++ |
| 12:45 |
mantis1 |
Claimed returned goes to missing |
| 12:50 |
csharp_ |
mantis1: we don't age Missing to any other status - some libraries probably run reports and manually do it - for us "Lost" means a patron checked it out and never returned it |
| 12:50 |
csharp_ |
we also don't age Claim Returned items to anything either |
| 12:54 |
csharp_ |
these changes *can* be automated - either by direct SQL (nightly cron job) or by A/T (passive hook) |
| 12:55 |
csharp_ |
Lost requires a circ, though - Missing usually means "not found on the shelf by library staff" in my experience |
| 13:03 |
|
Dyrcona joined #evergreen |
| 13:54 |
|
sleary joined #evergreen |
| 13:55 |
|
jeff joined #evergreen |
| 14:23 |
|
collum joined #evergreen |
| 16:18 |
Dyrcona |
Well, it's kind of hard to test something that requires searching in the catalog when your search results don't display. |
| 16:18 |
Dyrcona |
Oh, wait. They're showing up 1 by 1 now. |
| 16:55 |
|
mantis1 left #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 17:14 |
|
dmoore_doppel joined #evergreen |
| 18:13 |
pinesol |
News from commits: LP2011056 Color contrast for links in tooltips <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4a6550fb9e7ce5570be4c627b86a1583aa0285d0> |
| 21:07 |
|
dmoore_doppel joined #evergreen |
| 22:03 |
|
dmoore_doppel joined #evergreen |
