| Time |
Nick |
Message |
| 06:36 |
|
csharp joined #evergreen |
| 06:54 |
|
csharp joined #evergreen |
| 06:57 |
|
jboyer-isl joined #evergreen |
| 07:36 |
|
rjackson_isl joined #evergreen |
| 07:46 |
|
ericar joined #evergreen |
| 08:05 |
|
collum joined #evergreen |
| 08:32 |
|
mrpeters joined #evergreen |
| 08:34 |
|
Dyrcona joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:50 |
pinesol_green |
[evergreen|Mike Rylander] LP#1522538: Improper detection of jtitle search type - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a841f7e> |
| 09:08 |
|
graced joined #evergreen |
| 09:12 |
|
maryj joined #evergreen |
| 09:32 |
|
yboston joined #evergreen |
| 10:03 |
csharp |
@who wants to do my upgrade this weekend I can go on vacation? |
| 10:03 |
pinesol_green |
pastebot wants to do your upgrade this weekend I can go on vacation. |
| 10:03 |
csharp |
pastebot: rock on |
| 10:33 |
|
jwoodard joined #evergreen |
| 10:45 |
csharp |
here's something fun about working in a huge consortium: |
| 10:45 |
csharp |
evergreen=# delete from auditor.asset_copy_history where audit_time < (now() - '6 months'::interval); |
| 10:45 |
csharp |
DELETE 75229450 |
| 10:46 |
csharp |
that's about 2 years worth of data |
| 10:46 |
tsbere |
csharp: We have a script that does that kind of cleanup. Nightly. |
| 10:46 |
csharp |
yeah - we're moving to that |
| 10:46 |
miker |
csharp: don't even look in the general direction of money.billing ... |
| 10:47 |
csharp |
yeah that table is 34G right now |
| 10:47 |
miker |
or mrfr ;) |
| 10:47 |
csharp |
33G :-) |
| 10:48 |
csharp |
actually, our largest table right now is action.circulation at 41G, but that will change this weekend when we start regular aging of circ & hold data |
| 10:49 |
csharp |
aged.circulation is currently 30G |
| 10:52 |
|
rlefaive joined #evergreen |
| 10:56 |
|
graced joined #evergreen |
| 11:37 |
|
mdriscoll joined #evergreen |
| 11:42 |
|
graced joined #evergreen |
| 11:48 |
|
Christineb joined #evergreen |
| 11:49 |
|
bmills joined #evergreen |
| 12:15 |
|
ericar_ joined #evergreen |
| 12:17 |
|
ericar joined #evergreen |
| 12:34 |
|
graced joined #evergreen |
| 12:53 |
* mmorgan |
is trying to add some granular permissions to allow viewing and editing some library settings. |
| 12:55 |
mmorgan |
I have assigned a view_perm and an edit_perm to the library setting in question, but it looks like I need the all encompassing VIEW_ORG_SETTING to see them. |
| 12:55 |
mmorgan |
And that exposes all of them for view. |
| 12:56 |
mmorgan |
I just want to expose the subset of library settings that I have assigned a view permission to. Am I missing something? |
| 12:58 |
csharp |
mmorgan: you *should* be able to do something like VIEW_ORG_SETTING.setting_name |
| 12:58 |
csharp |
at least our UPDATE_ORG_UNIT_SETTING perms are like that |
| 12:58 |
csharp |
not sure if that convention is still followed though |
| 13:01 |
mmorgan |
csharp: Do your users see only the subset of the Library Settings they are able to update in the client? Or do they see all of them, but are only able to update those they have permission to? |
| 13:03 |
|
jihpringle joined #evergreen |
| 13:04 |
mmorgan |
I have added the permission VIEW_ORG_UNIT_SETTING.receipt_template.circ.staff_client.receipt.header_text and have updated config.org_unit_setting.view_perm with the id of the new permission. |
| 13:05 |
mmorgan |
But the user that has that permission gets "You do not have permission to view org settings" |
| 13:07 |
jboyer-isl |
mmorgan: I haven't looked at how the credit card settings work recently, but they do something similar to what you're describing. They do still appear as settings, but there are no values unless you have specific permission to view them. (So you do currently need VIEW_ORG_SETTING also) |
| 13:12 |
mmorgan |
I'm able to grant the edit permission I need to, but I was hoping to spare the user seeing the ou settings in all their glory. We haven't yet allowed our staff users into library settings at all. I will play around a little more. |
| 13:12 |
mmorgan |
csharp++ jboyer-isl++ |
| 13:17 |
|
graced joined #evergreen |
| 13:18 |
|
Christineb joined #evergreen |
| 13:18 |
|
eby joined #evergreen |
| 13:55 |
|
ericar_ joined #evergreen |
| 14:02 |
|
rlefaive left #evergreen |
| 14:03 |
|
mmorgan left #evergreen |
| 14:03 |
|
ericar_ joined #evergreen |
| 14:52 |
|
rlefaive joined #evergreen |
| 14:58 |
|
jboyer_isl joined #evergreen |
| 15:04 |
|
rlefaive joined #evergreen |
| 15:18 |
|
jlitrell joined #evergreen |
| 15:39 |
|
jboyer-isl joined #evergreen |
| 15:46 |
|
ericar_ joined #evergreen |
| 16:07 |
|
graced joined #evergreen |
| 16:11 |
* jeff |
thinks about unfillable holds |
| 16:12 |
jeff |
specifically, patron notification that their (perhaps once-fillable) holds are unfillable. |
| 16:12 |
bshum |
jeff: Do you have any max retries before cancellation? Or will patrons not be notified if a hold is canceled? |
| 16:13 |
jeff |
and things like not jumping the gun and notifying patrons / cancelling holds on items where there is not currently an item but will be an item next week... |
| 16:13 |
* bshum |
thought there was a stock A/T available for hold cancelation notification |
| 16:13 |
jeff |
bshum: we do not have a default hold expiry, and we do not make use of max retries, and also do not at present have an A/T for cancellation. |
| 16:16 |
tsbere |
jeff: We offer an unfillable holds report, both in template and out of evergreen form. |
| 16:16 |
* jeff |
nods |
| 16:17 |
tsbere |
The out of evergreen one I think has "can only be filled by system X" functionality as well, for when a specific system is having issues and thus isn't filling holds but no other system can supply a copy |
| 16:17 |
jeff |
i'm suspecting that some amount of manual process is likely to be required, at least at first. |
| 16:17 |
jeff |
and that automating the notification could be a good start. |
| 16:18 |
jeff |
of course, patrons without an email address... oof. |
| 16:18 |
tsbere |
Note that while we have the report available, that doesn't mean I know what they do with it. |
| 16:18 |
jeff |
hold cancellation notification does not lend itself well to phone notification. |
| 16:20 |
tsbere |
jeff: As a general note, I believe both our template based and out of evergreen reports use "no copy maps" as a determination of "unfillable". That is obviously not comprehensive. |
| 16:21 |
jeff |
right, since copy maps may contain copies that are not (yet) eligible to fill a hold. |
| 16:22 |
jeff |
(thinking specifically of age hold protection here) |
| 16:22 |
jeff |
(which of course goes away after a time -- usually) |
| 16:22 |
tsbere |
Or will never fill the hold because they aren't holdable by hold matrix rules |
| 16:23 |
tsbere |
Say, a hold that needs a transit, but the copy won't transit that far. Or the copy won't fill for that patron type. Or other such things. |
| 16:25 |
jeff |
One day I'll have read enough code that I understand why targeting places ineligible copies in the copy map, or I'll feel confident that there's no practical reason to continue doing so. :-) |
| 16:26 |
tsbere |
jeff: Basically, if the holdable *flags* say "no" it doesn't put them in. But it doesn't run the hold *rules* for every copy before putting them in the map. |
| 16:27 |
tsbere |
So a holdable false copy, location, or status means "no map created". The copy always hitting "not holdable" in the hold matrix won't stop maps from being created. |
| 16:44 |
|
bmills joined #evergreen |
| 16:57 |
jeff |
and ahcm is used for at least: opportunistic hold capture, checkout fills related hold, and hold queue stats. also, copy-hold ratios in circ matrix tests. |
| 16:59 |
|
mdriscoll left #evergreen |
| 17:12 |
|
jeffdavis joined #evergreen |
| 19:04 |
|
rlefaive joined #evergreen |
| 19:32 |
kmlussier |
@quote random |
| 19:32 |
pinesol_green |
kmlussier: Quote #114: "<Dyrcona> If TCP/IP were standardized like most library standards, we'd all be using AOL/CompuServe." (added by berick at 02:43 PM, May 04, 2015) |
| 20:05 |
kmlussier |
@sortinghat |
| 20:05 |
pinesol_green |
Hmm... kmlussier... Let me see now... GRYFFINDOR! |
| 20:42 |
bshum |
@sortinghat |
| 20:42 |
pinesol_green |
Hmm... bshum... Let me see now... GRYFFINDOR! |
| 21:08 |
|
graced joined #evergreen |
| 21:12 |
miker |
jeff: tl;dr -> flags are likely to stay the same over hold-ish time periods, so no map. rule based disqualification is both more complicated and less static (or, that's the supposition) so we make the mapping in hopes that the copy will test "OK for hold" in hold-ish time periods. |
| 21:13 |
miker |
hth |
| 21:52 |
|
eeevil joined #evergreen |
| 21:53 |
|
jeff_ joined #evergreen |
