| Time |
Nick |
Message |
| 04:03 |
pinesol |
News from commits: LP#2093128 Reverts to Initial Flat/Enhanced MARC Editor on Save <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=61f227c985db74d705b293f5d07e8da95c0d59aa> |
| 04:03 |
pinesol |
News from commits: LP#2097391: fix the "Include items?" option with Angular record bucket export <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b277099f5cf21ff26e9b06a936756c86f9b9c94f> |
| 10:12 |
|
BAMkubasa joined #evergreen |
| 10:20 |
BAMkubasa |
I wanted to inquire about some behavior before submitting a Launchpad wishlist item. We've noticed instances where an item was in transit from branch A to branch B, but was mistakenly sent to branch X. When its scanned at branch X, a transit slip pops up saying to send it to branch B. We haven't been able to find evidence of it being scanned at |
| 10:20 |
BAMkubasa |
branch X in for instance the action.transit_copy table, or some other logging table. When weird things happen, or things go missing, it makes it hard to figure out where they were last scanned. Is there somewhere that stores this granular transit/scan data? |
| 11:19 |
|
redavis joined #evergreen |
| 12:08 |
jeff |
BAMkubasa: I believe in the case you describe, the only information would be in the logs, and the information is not recorded in any table where you could report on it or see it from the staff client. |
| 12:09 |
jeff |
I have a lot of general interest in tracking more detail on some of those kinds of things, so I'll look forward to your wishlist item. :-) |
| 13:04 |
eby |
yeah i was looking at putting in an auditor for the hold request table but then saw in code and launchpad that some people have it. still digging for docs on how to implement it after the fact though |
| 13:53 |
Bmagic |
eby: select * from auditor.create_auditor('action','hold_request'); |
| 13:53 |
Bmagic |
that should setup the auditor table and introduce all of the database triggers needed to begin auditing action.hold_request |
| 13:55 |
Bmagic |
a little warning though: that table is busy, and your auditor table will likely balloon rapidly. So, you'll probably want to introduce another cron job to clean the auditor table out on a nightly basis |
| 13:59 |
Bmagic |
eby: are you aware of the new feature having to do with tracking the hold lifecycle introduced in 3.14? https://bugs.launchpad.net/evergreen/+bug/2012669 and documented lightly here: https://docs.evergreen-ils.org/docs/latest/circulation/basic_holds.html#hold_reset_reasons |
| 13:59 |
pinesol |
Launchpad bug 2012669 in Evergreen "Hold request reset entries" [Wishlist,Fix released] |
| 14:06 |
|
redavis_reloaded joined #evergreen |
| 14:07 |
eby |
yeah was hoping to avoid the hold targeter fields in the audit but will look. Mostly tracking user/ws for who tweaked things like frozen, pickup_lib, etc. But looks like that hold reset would track everything I was looking for |
| 14:08 |
eby |
thanks for the info |
