| Time |
Nick |
Message |
| 06:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rfrasur joined #evergreen |
| 08:08 |
|
agoben_ joined #evergreen |
| 08:15 |
|
Dyrcona joined #evergreen |
| 08:35 |
|
mantis joined #evergreen |
| 08:59 |
|
jvwoolf joined #evergreen |
| 09:06 |
|
jvwoolf1 joined #evergreen |
| 10:24 |
Dyrcona |
jboyer++ gmcharlt++ Lp 1880035 |
| 10:24 |
pinesol |
Launchpad bug 1880035 in Evergreen 3.4 "Monograph parts page does not display with fix for JQuery upgrade" [High,Confirmed] https://launchpad.net/bugs/1880035 |
| 11:31 |
jvwoolf1 |
I've asked this here at least once, but I'm giving it one more shot. We're having a problem with library staff cloning report templates. Super users can clone without an issue. All staff have the CREATE_REPORT_TEMPLATE permission at the System level. I tried giving permission at the consortium level with no luck. The template screen loads, but there is no data in it. Console gives the error: TypeError: Cannot read property 'data' |
| 11:31 |
jvwoolf1 |
ndefined |
| 11:32 |
csharp |
jvwoolf1: were the templates in question created in XUL? |
| 11:33 |
jvwoolf1 |
Most of them are, so probably yes |
| 11:33 |
csharp |
and cloning is happening in the web client? |
| 11:33 |
jvwoolf1 |
Yes |
| 11:34 |
csharp |
jvwoolf1: there's a JS process that converts the "old" template format to the "new" template format and that might not be working for some reason for those |
| 11:35 |
jvwoolf1 |
Huh. OK. Any idea why it would only be happening for staff accounts? I a can clone the same templates with my superuser account and it works fine. |
| 11:37 |
csharp |
oh - hmm |
| 11:37 |
csharp |
that means it's not a problem with the conversion |
| 11:38 |
csharp |
try changing the perm depth to Consortium |
| 11:38 |
csharp |
oh oops |
| 11:38 |
csharp |
you did that |
| 11:39 |
csharp |
jvwoolf1: do they also have RUN_REPORTS? |
| 11:40 |
jvwoolf1 |
csharp: They do. That's still set to system. |
| 11:40 |
csharp |
jvwoolf1: have you tried changing that to consortium? |
| 11:41 |
jvwoolf1 |
Not yet. Worth a shot. |
| 11:41 |
csharp |
based on what I'm seeing in fm_IDL.xml, it should do it |
| 11:42 |
csharp |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/examples/fm_IDL.xml;h=560d372eab3a5637e8ea8ac754e4bad655c96ee8;hb=HEAD#l10286 |
| 11:42 |
csharp |
permission="RUN_REPORTS" owning_user="owner" global_required="true" |
| 11:43 |
Dyrcona |
Is the owner not changed in the cloned template, then? |
| 11:44 |
Dyrcona |
Just spitballin'. |
| 11:44 |
jvwoolf1 |
Well, I'll be |
| 11:44 |
jvwoolf1 |
That did it |
| 11:44 |
csharp |
fwiw, we give our LocalAdmins (highest admin account within a system) RUN_REPORTS at Consortium, Grantable = true so they can assign to trusted staff |
| 11:44 |
jvwoolf1 |
csharp ++ |
| 11:44 |
csharp |
jvwoolf1: glad to help! |
| 11:45 |
jvwoolf1 |
csharp: This has been driving me nuts for at least a month! Thanks! |
| 11:45 |
csharp |
sorry I missed you asking about it before! |
| 11:45 |
jvwoolf1 |
No worries! |
| 12:14 |
|
jihpringle joined #evergreen |
| 12:29 |
Bmagic |
hard boundary question - if a library doesn't want any of their holds getting filled by any other copies other than their own, a hard boundary setting of "1" at the system level for them should prevent that right? |
| 12:30 |
|
khuckins joined #evergreen |
| 12:35 |
|
dbwells joined #evergreen |
| 12:35 |
csharp |
Bmagic: yes |
| 12:36 |
csharp |
having just looked at boundaries for PINES libraries, I feel like I can be fairly definitive :-) |
| 12:37 |
Bmagic |
for some reason - it's not. I am playing with one example. I remove all rows in action.hold_copy_map. Set the system hard boundary setting, then run request open-ils.hold-targeter open-ils.hold-targeter.target {"hold":7307525} - it puts all the same rows back into the copy map AND targets a non-local copy |
| 12:37 |
jeff |
keep in mind that you'll need to adjust the selection_depth on any existing outstanding holds if you change the hard boundary, and you may also need/want to retarget. |
| 12:38 |
jeff |
the circ.hold_boundary.hard org unit setting comes into play at hold request time, not targeting. |
| 12:38 |
Bmagic |
hmmm |
| 12:38 |
jeff |
it's a little bit like needing to recalc penalties when you adjust a group penalty threshold. |
| 12:39 |
Bmagic |
selection_depth on this hold is 0 |
| 12:40 |
Bmagic |
needs to be 1? |
| 12:40 |
csharp |
right |
| 12:40 |
Bmagic |
ah, that would explain it. Setting only comes into play when the row is inserted, and it would be inserted with selection_depth=1 because hard_boundary |
| 12:41 |
Bmagic |
and there we go jeff++ csharp++ |
| 13:21 |
|
dbwells joined #evergreen |
| 13:53 |
* Dyrcona |
yawns. |
| 13:54 |
Dyrcona |
Not sure why I'm so tired, except maybe I should have eaten something instead of going for a walk at lunch time. |
| 14:10 |
|
sandbergja joined #evergreen |
| 14:50 |
|
dbwells joined #evergreen |
| 14:50 |
|
rfrasur joined #evergreen |
| 14:51 |
Dyrcona |
Has anyone ever put a filter on hold.available to limit notifications by pickup lib, for instance? |
| 14:52 |
Dyrcona |
I should say an action trigger filter, that is. |
| 15:31 |
|
mantis left #evergreen |
| 15:31 |
|
sandbergja joined #evergreen |
| 15:34 |
csharp |
hooray! I can't say anything works yet, but I've updated the Makefile.install for OpenSRF so that it successfully installs prereqs for CentOS/RHEL |
| 15:57 |
|
jihpringle joined #evergreen |
| 16:12 |
JBoyer |
csharp++ |
| 16:12 |
sandbergja |
csharp++ |
| 16:47 |
|
jihpringle joined #evergreen |
| 16:55 |
Bmagic |
csharp++ # that is amazing |
| 16:57 |
Bmagic |
What is the magic sauce to cause the system to default newly registered patrons with notification preferences? |
| 17:03 |
jihpringle |
Bmagic: take a look at User Setting Types (Admin -> Server Admin) |
| 17:04 |
jihpringle |
there's a setting "Hold Notification Format" and a field for Registration Default |
| 17:05 |
Bmagic |
I see that.... that must not be where this is happening. Because a library claiming that the UI is checking the email box by default during patron registration in the staff client. There is nothing set in User Settings Types |
| 17:07 |
jihpringle |
we tried to remove phone as a default through there and it didn't work for us either |
| 17:07 |
jihpringle |
but we just upgraded to 3.5 so weren't sure yet if it was a new bug or something else |
| 17:08 |
Bmagic |
Something somewhere is checking that box for them |
| 17:08 |
|
dbwells joined #evergreen |
| 17:09 |
Bmagic |
hmm, maybe it's just default Evergreen behavior |
| 17:09 |
|
jvwoolf joined #evergreen |
| 17:09 |
Bmagic |
Seems to be like that in at least two system's I've tried |
| 17:15 |
jihpringle |
if we figure out how to change it I'll let you know. We've had several libraries request that phone not be checked by default since it makes the Default Hold Notification Phone Number field a required field |
| 17:19 |
jihpringle |
Bmagic: https://bugs.launchpad.net/evergreen/+bug/1879993 |
| 17:19 |
pinesol |
Launchpad bug 1879993 in Evergreen "EG3.5 default value for opac.hold_notify ignored" [Undecided,New] |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
