2011-10-10T01:19:11 *** jeffdavis has quit IRC 2011-10-10T01:26:19 *** jeffdavis has joined #evergreen 2011-10-10T08:26:18 *** collum has joined #evergreen 2011-10-10T08:40:55 *** Shae has joined #evergreen 2011-10-10T08:51:06 *** gdunbar has joined #evergreen 2011-10-10T08:54:01 *** asimon has joined #evergreen 2011-10-10T08:58:22 We're having a problem deleting patron records. With a user that has the VIEW_USER_FINES_SUMMARY permission, we get the error: 2011-10-10T08:58:36 Error: Could not load 'fieldmapper:AutoIDL'; last tried '../fieldmapper/AutoIDL.js', followed by: TypeError: robj is null 2011-10-10T08:59:01 An administrative user can delete patrons with no error. 2011-10-10T08:59:51 The user is able to delete the patron despite the error messages. 2011-10-10T09:02:04 *** dbwells_ is now known as dbwells 2011-10-10T09:02:10 The user gets the following exception: Permission Denied: VIEW_USER_FINES_SUMMARY 2011-10-10T09:03:07 Does anyone have any ideas why this is occurring? 2011-10-10T09:06:17 asimon: What does the depth associated with the staff account set to? 2011-10-10T09:08:03 does/is *good golly it's early on a Monday :( 2011-10-10T09:17:47 *** akilsdonk has joined #evergreen 2011-10-10T09:43:08 *** sfortin has joined #evergreen 2011-10-10T09:45:26 bshum: It's set to 'Group' , which is depth 3 of 7 (counting from 0) and is the depth above 'Library' and two depths above 'Library Building,' which is the circ_lib. 2011-10-10T09:45:59 asimon: Which version of Evergreen are you using again? (just checking) 2011-10-10T09:47:59 bshum: 2.0.9 2011-10-10T09:48:20 And when you say you're deleting a patron, you're using the "obliterate" option? 2011-10-10T09:49:03 Just thinking that maybe that permission error is due to not having a high enough depth to view the deleted patron at the end. I think they become consortium level owned. 2011-10-10T09:49:17 During a purge action 2011-10-10T09:49:21 *** jenny1 has joined #evergreen 2011-10-10T09:50:08 In our system, our depth is set to 0 - consortium. Which may not necessarily be best practice if you don't like people sharing viewing of other library patron's fines. 2011-10-10T09:50:41 bshum: We're using 'Delete Patron Account' in the 'Other' list on the patron screen. 2011-10-10T09:50:57 asimon: Yep, that's the purge/obliterate that I'm thinking of then. 2011-10-10T09:51:31 bshum: The depth of the staff user or the depth of the VIEW_USER_FINES_SUMMARY permission? 2011-10-10T09:51:51 asimon: The permission itself. 2011-10-10T09:52:18 asimon: Unless you have unique permissions assigned to that particular staff user account, that it otherwise didn't inherit. 2011-10-10T09:52:34 asimon: From its permission group. 2011-10-10T09:54:25 bshum: OK. We'll try that. Thanks. 2011-10-10T09:54:52 dbwells: could you advise if http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=499ee94372592a8ed6eb6fda826314f4fde5b6af is a reasonable way to describe the serials enahncements for 2.1? 2011-10-10T09:55:35 also, I'm a little unclear on what unit-less receiving means for the librarian, so anything you can expand on for that would be useful 2011-10-10T09:58:38 gmcharlt: summary looks great. Units are EG copies with serial issue information attached, so unit-less receiving allows one to track and receive issues for reading room / non-circulating use. 2011-10-10T10:02:03 dbwells++ 2011-10-10T10:02:08 I'll tweak accordingly and commit 2011-10-10T10:02:29 *** asimon has quit IRC 2011-10-10T10:31:33 @later tell dbs for your consideration - http://evergreen-ils.org/dokuwiki/doku.php?id=dev:release_notes_checklist 2011-10-10T10:31:34 gmcharlt: The operation succeeded. 2011-10-10T10:33:32 *** lisah_ has joined #evergreen 2011-10-10T11:18:20 *** youdonotexist has joined #evergreen 2011-10-10T11:50:09 tsbere: how crazy an idea would it be to offer a stock auto-updating staff client? I can think of a couple objections, including additional bandwidth usage and a need to ensure the security of the community update source, but is there anything else that would make it not a good idea in principle? 2011-10-10T12:20:27 gmcharlt: What about a configuration setting that a confident admin could turn on to allow stock auto-updating of the staff client? 2011-10-10T12:32:04 gmcharlt: A stock auto-updating staff client would likely become a problem if it auto-updated into incompatibility. 2011-10-10T12:33:36 moodaepo: See autoupdate.js, it defines all the nice variables needed. 2011-10-10T12:33:42 tsbere: in that case, am I now guessing correctly that it checks *only* the update server to see if there is a new update? 2011-10-10T12:34:03 gmcharlt: Yes. MVLC has a hostname *just* for updates that nobody uses for normal staff client use, in fact. 2011-10-10T12:35:12 tsbere: right then - thanks for clarifying 2011-10-10T12:35:34 * tsbere could likely easily write a block of code to change that, but then again custom.js work could as well 2011-10-10T12:36:12 gmcharlt: Would you like me to rig up a "include this for automatic update enabling of a stock client" block for custom.js? 2011-10-10T12:36:31 gmcharlt: client upgrades often need to be tightly coupled with server upgrades. that would be one reason against. 2011-10-10T12:37:14 though perhaps "often" is inaccurate. 2011-10-10T12:37:23 tsbere: yes, I'd be interested in seeing that 2011-10-10T12:38:10 huh. we've no "library phone number" macro for receipt templates. 2011-10-10T12:38:38 jeff: of course, hence the need for making sure that you wouldn't get auto-updated into incompatiblity, as tsbere pointed out 2011-10-10T12:38:51 *nod* 2011-10-10T12:39:47 an auto-update by default to your library/consortium's server would likely be more useful than auto-updating to a community location. 2011-10-10T12:41:04 jeff: indeed, and that's something that I expect most of our customers will want and get, but I'm just doing some thinking aloud for the use case of somebody who runs a small, stock EG setup 2011-10-10T12:45:32 tsbere: Oye maybe I'm just lost as usual...are we talking about auto-update for the default client that get's downloaded from the evergreen website? 2011-10-10T12:46:30 moodaepo: Wait for my example I am working on ;) 2011-10-10T12:47:23 *** agJohn has joined #evergreen 2011-10-10T12:52:31 Is there some kind of 2.0.9 setting that might be messed up so that users logging in with the workstation info set to a particular library can't see some shared reports and all others can? 2011-10-10T12:52:32 More detailed explanation in paste: http://paste.lisp.org/display/125219 2011-10-10T12:54:48 gmcharlt / moodaepo : http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/custom_updater 2011-10-10T12:54:55 agJohn: I don't recall any settings that were changed, but they did alter the way that reports was presented sometime around 2.0.5+ Something to do with alphabetical (or some other) reordering of reports. 2011-10-10T12:55:24 agJohn: Perhaps something in the way the report data was shared could be weird though. 2011-10-10T12:56:17 Very odd that it's only affecting this one library and that it's related to the workstation's library--I see more digging ahead.... 2011-10-10T12:56:19 agJohn: I suspect your org tree is slightly screwy (or you need to run autogen) - Perhaps with org depth compared to type depth or something? Could be wrong, though. 2011-10-10T12:56:21 tsbere++ 2011-10-10T12:57:17 tsbere: I trust it can't be autogen--that's been run many times as we've tried to clear out other issues; but the depth issue seems like a possibility. Thanks for the tip. 2011-10-10T12:59:39 gmcharlt: Feel free to review/commit that. Feeling lazy enough to not hit up launchpad on a day off for it ;) 2011-10-10T13:00:05 heh - fair enough 2011-10-10T13:00:54 * tsbere did give it a test or two, though, and saw all the settings show up 2011-10-10T13:01:23 Hmmm 2011-10-10T13:01:31 I wonder if that should get an extra warning in front of it 2011-10-10T13:02:08 "THIS IS NOT COMPATIBLE WITH MULTIPLE VERSIONS OF THE STAFF CLIENT BEING INSTALL ON THE SAME COMPUTER" type deal. Because it will no longer be a default, and thus will override *all* installed clients.... 2011-10-10T13:02:15 s/INSTALL/INSTALLED/ 2011-10-10T13:07:20 gmcharlt: The above is one reason why I don't think I documented this method before. Breaking all other installed auto-updating staff clients (which, if you enable the settings, likely attempts to include 1.6/2.0 clients) :/ 2011-10-10T13:11:38 tsbere: maybe set the prefs if they're not already set 2011-10-10T13:11:59 so first encounter of custom.js will lock your client in 2011-10-10T13:12:21 phasefx: Won't help. 2011-10-10T13:12:32 * phasefx fades back into the shadows, "bummer 2011-10-10T13:13:07 All you need is to ever connect a server with that code in custom.js *without* an already automatic update enabled client and they get set....with a URL that is likely *not* the default on your others if you have any that do automatically update. 2011-10-10T13:14:02 AKA, when using "non-default-pref" settings all it takes is once and you trigger every other client you have installed to look at that one server. 2011-10-10T13:14:50 * phasefx didn't know prefs were shared like that 2011-10-10T13:15:11 They are stored in prefs.js *in the profile directory*. Most people don't keep multiple profile directories around. 2011-10-10T13:15:12 profile directory? 2011-10-10T13:15:21 hmmm 2011-10-10T13:16:33 Also, enabling the prefs won't enable write access to the install directory, if you don't have that already. 2011-10-10T13:16:49 * tsbere feels it is just safer to enable it at installer build time 2011-10-10T13:17:00 Or rather, client build time. 2011-10-10T13:21:33 *** lisah_ has quit IRC 2011-10-10T13:23:13 phasefx: I did look for non-preference ways to interact with the hostname settings, didn't find any. 2011-10-10T13:27:33 huh. is util/print.js really client-side? that would be unfortunate. 2011-10-10T13:29:15 jeff: Tis both. 2011-10-10T13:29:40 Gets copied server-side. Remote XUL uses the server side version, local XUL uses the client side version, I believe. 2011-10-10T13:30:05 alas, test changes not showing up after editing both. i'm doing something else wrong. 2011-10-10T13:30:05 * tsbere can't think of anything other than the offline client that uses the local copy off the top of his head 2011-10-10T13:30:22 did you clear cache? 2011-10-10T13:30:34 and then reload whatever page you are printing from? 2011-10-10T13:30:41 first time connecting to this server, but that'll be my next step. 2011-10-10T13:30:47 Hmmm 2011-10-10T13:30:56 Bad code? 2011-10-10T13:31:13 * tsbere occasionally goes "why isn't this working?" only to find he had a typo that caused a hidden error 2011-10-10T13:31:46 yeah. i'm suspecting that i'm trying to replace with a param that doesn't exist, and it's reverting in the try/catch 2011-10-10T13:32:44 make the catch an alert for testing? 2011-10-10T13:32:59 went with "try replacing with a hardcoded string" -- worked. 2011-10-10T13:33:08 tsbere: want to swap pullrequests? I'll trade you a https://bugs.launchpad.net/evergreen/+bug/870072 for a https://bugs.launchpad.net/evergreen/+bug/787542 2011-10-10T13:33:10 so, on to inspecting the object :-) 2011-10-10T13:34:15 eeevil: My knowledge of authority anything hovers around "they exist" 2011-10-10T13:35:05 * tsbere doesn't know how to *get* authority data into a test system, let alone get it in right 2011-10-10T13:35:25 tsbere: fair enough ... I'll take 787542 for free, then 2011-10-10T13:36:35 * tsbere avoids acq pullrequests for the same basic reason - complete lack of a clue how to use that part of the system 2011-10-10T13:37:01 grabbing 0636 2011-10-10T13:44:54 grabbing 0637 for reworking of https://bugs.launchpad.net/evergreen/+bug/822918 2011-10-10T13:45:39 eeevil++ 2011-10-10T14:05:13 *** collum has quit IRC 2011-10-10T14:25:16 *** sal_ has joined #evergreen 2011-10-10T14:28:23 eeevil: On 870029, if that is the *intended* behavior for title-based holds than the system is broken for what is intended. 2011-10-10T14:32:36 Remind me, but to reindex bib records after adding new metabib definitions would be as simple as running the "reingest_metabib_field_entries" function against all the non-deleted bib records we have? Or a bit more complicated than that? 2011-10-10T14:34:17 tsbere: eh? 2011-10-10T14:34:32 * tsbere is updating the ticket 2011-10-10T14:37:16 bshum: that's it -- we could make it more complicated for you if you want ;) 2011-10-10T14:37:26 gmcharlt: No, I like uncomplicated :) 2011-10-10T14:37:37 bshum: more seriously, a vacuum analyze when it's done is advisable 2011-10-10T14:37:39 *** Callender_ has joined #evergreen 2011-10-10T14:37:49 gmcharlt: Our catalogers asked me to add some new title index that I couldn't find in the existing structure. 2011-10-10T14:38:29 To avoid conflict, we should be creating custom indexes above ID 100 right? 2011-10-10T14:38:56 that would be a good idea 2011-10-10T14:39:19 eeevil: Posted my update. 2011-10-10T14:39:34 gmcharlt: On a side note, I think auto vacuum isn't working right on our db; or at least I haven't seen an autovacuum timestamp show up anywhere on some of our tables in a really long time. 2011-10-10T14:41:03 *** Callender has quit IRC 2011-10-10T14:41:15 *** Callender_ is now known as Callender 2011-10-10T14:43:48 tsbere: sidebar ... so, there's a difference between _check_title_hold_is_possible and other *hold_is_possible methods? that's disconcerting, and maybe wrong ... in any case, do you have any feelings on the strict/non-strict mode flags (of either type)? 2011-10-10T14:46:22 eeevil: From what I saw check_title_hold_is_possible is the only one that filters on the holdable flags when loading a list of potential copies. As for strict/non-strict mode flags....wouldn't that be solved already by granting override permissions? 2011-10-10T14:46:41 gmcharlt: So something like http://paste.lisp.org/display/125221 would probably do what you suggested for vacuum analyze afterwards, right? 2011-10-10T14:47:16 bshum: yep 2011-10-10T14:47:39 gmcharlt: Cool, thanks! 2011-10-10T14:47:41 *** Callender has quit IRC 2011-10-10T14:49:11 oh bah. the org tree is cached. forgot. 2011-10-10T14:49:57 thus, even though i added a phone number to BR1, nothing will notice unless... looks like unless i restart memcached? 2011-10-10T14:50:28 You may need to run autogen 2011-10-10T14:50:44 and you will need to log out of and back into the client. Maybe restart it or clear the cache in it before doing so. 2011-10-10T14:51:49 nothing client-side will have an effect, because it's being cached in memcached. autogen might overwrite the cached data, though. 2011-10-10T14:51:59 or i could remove it by hand, or restart memcached. 2011-10-10T14:52:15 i don't know if there's a default ttl on this or not. i don't see an explicit ttl specified. 2011-10-10T14:52:26 this is get_org_tree in AppUtils.pm 2011-10-10T14:54:03 tsbere: hrm.. override perms is an interesting way to look at it ... we'd have to auto-retry, I guess? 2011-10-10T14:55:11 eeevil: TPac prompts anyway, doesn't it? 2011-10-10T14:56:06 *** sal_ has quit IRC 2011-10-10T14:56:41 tsbere: no idea on tpac, I've not been involved in the nuts and bolts of that code 2011-10-10T14:57:43 My understanding is that TPac tries to determine if you have override perms. If so, it says "these holds couldn't be placed, but you can force them". Haven't checked the full list of what it can force, granted. 2011-10-10T14:58:09 * berick concurs 2011-10-10T14:58:10 I tied into that for the "allow holds on age-protected" branch 2011-10-10T14:58:22 For JSPac I had to write a prompt for that branch 2011-10-10T14:58:24 okay, lacking an explicit ttl, max_cache_size from opensrf.xml is used, default is 1d 2011-10-10T14:58:30 But TPac I just added a custom message, basically 2011-10-10T14:58:49 *** Callender has joined #evergreen 2011-10-10T14:59:03 and missing from that is targeter logic for "for this hold, disregard holdable flags" -- otherwise you're still just letting staff place unfillable holds, right? 2011-10-10T14:59:39 tsbere: ahh... ok 2011-10-10T15:00:17 jeff: I did that for force and recall holds in another branch. 2011-10-10T15:00:25 * tsbere has been busy with holds, apparently 2011-10-10T15:00:43 tsbere: I feel like this needs documenation ;) ... but, given all that up there -^ I like your branch and will note so on the bug 2011-10-10T15:01:24 throwing this out there, may not be relevant to this specific conversation: staff-placed copy level holds being placed and filled for staff can be useful. 2011-10-10T15:02:04 jeff: For a non-holdable copy? 2011-10-10T15:02:11 yes. 2011-10-10T15:02:33 though, arguably such "workflow" needs should have something other than holds/circs to make use of. 2011-10-10T15:02:36 Apply my force and recall branch, then place a force hold. Bypasses 100% of hold rules. Also cuts in line majorly. 2011-10-10T15:03:04 internal "this is on the problem shelf in department X" style things, which currently get done with pseudopatrons and then are manually excluded from stats, etc. 2011-10-10T15:03:05 Recall holds would do the same, but when they get checked in jump to cataloging and auto-fill the hold. 2011-10-10T15:03:51 *** sal_ has joined #evergreen 2011-10-10T15:04:09 jeff: https://bugs.launchpad.net/evergreen/+bug/870032 if you want to see what I am talking about 2011-10-10T15:05:14 tsbere: great! does it still need some UI, or was the UI already there? 2011-10-10T15:05:47 UI is already there. Several points where "request item" is available bring up a copy/recall/force hold placement UI, such as from Item Status. 2011-10-10T15:06:27 tsbere: can you explain the last paragraph of your commit, "Also, some re-ordering of logic should result in a fix for issues with capturing holds as transits and/or suppressing holds and the hold shelf logic."? 2011-10-10T15:06:51 was the display of items on hold shelf showing items that were not actually there, when it came to force/recall? 2011-10-10T15:06:59 jeff: That was an oversight from the suppress transit code. It was checking that *after* the transit or non-transit was assumed in at least one place. 2011-10-10T15:07:13 gotcha. 2011-10-10T15:08:11 Before that branch the entire system treats force and recall holds as copy holds. 2011-10-10T15:08:37 The few points something special was done for force or recall it didn't end up mattering 2011-10-10T15:09:01 currently opportunistic capture checks the nearest/next 10 holds at check-in. this causes problems on popular items where both fifo and age hold protection are in use. anyone have an objection to allowing a YAOUS to override that limit of 10? 2011-10-10T15:09:10 * jeff digs for a link to the code in question 2011-10-10T15:10:17 That might be a different issue. Shouldn't opportunistic capture only check holds that the current copy is *valid* for? And age protected copies shouldn't be on that list. 2011-10-10T15:10:42 ah, i've touched on that before. they are on the list. :-) 2011-10-10T15:11:10 copies which are unsuitable due to ahp are included in ahcm for holds. 2011-10-10T15:11:21 That something you did, or something the system has been doing, because I don't think I saw that happen on our system. 2011-10-10T15:11:32 i think some/all permit checks are bypassed with ahcm entries are generated. 2011-10-10T15:11:58 that was my observation as recently as 1.6, and i'm seeing symptoms that suggest it now on 2.1ish. 2011-10-10T15:12:11 i can confirm and re-visit 2011-10-10T15:13:05 sub nearest_hold does a LIMIT 10 by default: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Publisher/action.pm;h=eff589c35bbb7181ee3753b3d80806c9afccbaa0;hb=HEAD#l290 2011-10-10T15:13:27 Hmm. Looks like the hold targeter does minimal checks, but then those checks are done at capture time instead. 2011-10-10T15:13:33 * jeff nods 2011-10-10T15:13:57 might be more efficient to do more of them at targeting time, at the expense of not picking up very recent item changes. 2011-10-10T15:14:04 both might be good. 2011-10-10T15:14:27 Would make targeting do the full set of checks for every copy every day by default. 2011-10-10T15:15:02 Maybe teach the targeter about the age hold protection field, and run *only* those copies through? 2011-10-10T15:15:13 what we run into is popular items with >10 holds for pickup at LIB2 being checked in at LIB3 and none of the 10 holds are suitable (because of ahp) and thus the copy isn't captured at all. 2011-10-10T15:15:29 my 1.6 workaround was to check 100 items. 2011-10-10T15:15:34 * tsbere can see reasons to run it for every copy, though, such as transit-limited copies or transit-stopping hold rules 2011-10-10T15:15:39 (but that only goes so far) 2011-10-10T15:15:54 (as workarounds tend to do) 2011-10-10T15:24:26 going back to my orgtree caching fun, indeed "memcrm --servers localhost orgtree.en-US" let me see the changes. 2011-10-10T15:49:14 jeff: Which version of EG did you have orgtree caching problems? Apologies for being a broken record, but maybe this was your problem? https://bugs.launchpad.net/evergreen/+bug/842910 2011-10-10T15:51:07 dbwells: a stale-now copy of rel_2_1, before your fix. i was adding a phone number to BR1 and not seeing the change in open-ils.actor.org_tree.retrieve due to the default 1d cache, and due to my not running autogen/etc (though it probably wouldn't have helped without that fix) 2011-10-10T15:51:59 jeff: cool, thanks. Just making sure there isn't some other problem going on. 2011-10-10T15:52:13 dbwells: i was deliberately ignoring the "usual" steps as a learning measure :-) 2011-10-10T15:52:47 :) 2011-10-10T15:52:53 i wanted to know where it was being cached, and wanted to know which step was 'normally' clearing it / expiring it. 2011-10-10T15:53:15 i do share your thought regarding "why didn't this break more often before?" 2011-10-10T15:54:12 with the fix, that probably makes some instances of "restart all services" no longer needed. 2011-10-10T15:54:46 *** akilsdonk has quit IRC 2011-10-10T15:55:14 okay, given a valid receipt template macro, and undefined data, i think replacing it with '' is best, rather than leaving the macro itself or having 'undefined' show up. 2011-10-10T15:56:55 *** akilsdonk has joined #evergreen 2011-10-10T16:02:04 *** akilsdonk_ has joined #evergreen 2011-10-10T16:03:58 *** akilsdonk has quit IRC 2011-10-10T16:03:59 *** akilsdonk_ is now known as akilsdonk 2011-10-10T16:12:19 *** sfortin has quit IRC 2011-10-10T16:15:35 *** akilsdonk_ has joined #evergreen 2011-10-10T16:17:19 *** akilsdonk has quit IRC 2011-10-10T16:17:30 *** akilsdonk_ is now known as akilsdonk 2011-10-10T16:26:35 *** akilsdonk_ has joined #evergreen 2011-10-10T16:29:03 *** akilsdonk has quit IRC 2011-10-10T16:29:16 *** akilsdonk_ is now known as akilsdonk 2011-10-10T16:50:32 *** Shae has quit IRC 2011-10-10T17:02:56 *** akilsdonk has quit IRC 2011-10-10T17:11:39 *** _bott_ has quit IRC 2011-10-10T17:12:06 *** _bott_ has joined #evergreen 2011-10-10T17:16:51 *** fortin has joined #evergreen 2011-10-10T17:33:32 *** fortin has quit IRC 2011-10-10T17:35:14 *** fortin has joined #evergreen 2011-10-10T17:53:16 *** jenny1 has left #evergreen 2011-10-10T19:18:06 *** youdonotexist has quit IRC 2011-10-10T19:31:59 *** moodaepo has quit IRC 2011-10-10T19:36:36 *** sal_ has quit IRC 2011-10-10T20:05:38 *** fortin has quit IRC 2011-10-10T20:42:55 *** agJohn has quit IRC 2011-10-10T21:20:16 *** atz__ has joined #evergreen 2011-10-10T21:24:18 *** atz has quit IRC 2011-10-10T22:24:13 *** ktav has joined #evergreen 2011-10-10T22:25:51 *** ktav has left #evergreen 2011-10-10T22:30:48 *** ktvnav has joined #evergreen 2011-10-10T22:39:24 *** ktvnav has quit IRC 2011-10-10T22:39:32 *** ktvnav has joined #evergreen 2011-10-10T23:11:06 @later tell moodaepo I just realized that reingest snippet is actually very much like the one constructed from the reingest.sql we created during the 1.6-2.0 upgrade process. Either way, might be magic spell worthy. 2011-10-10T23:11:06 bshum: The operation succeeded.