2010-02-25T01:00:40 *** mck9 has left #evergreen 2010-02-25T01:04:31 *** dsadsd has joined #evergreen 2010-02-25T01:33:31 *** rsinger has quit IRC 2010-02-25T01:33:57 *** brendan_bywater has quit IRC 2010-02-25T03:24:57 *** Luca_ has joined #evergreen 2010-02-25T03:25:16 *** Luca_ has quit IRC 2010-02-25T07:52:14 *** grantjohnson has joined #evergreen 2010-02-25T07:52:54 *** sfortin has joined #evergreen 2010-02-25T07:54:00 *** mck9 has joined #evergreen 2010-02-25T08:35:16 *** brendan_bywater has joined #evergreen 2010-02-25T08:35:41 *** Melissa has joined #evergreen 2010-02-25T08:36:56 *** eguest309 has joined #evergreen 2010-02-25T08:43:10 *** brendan_bywater has quit IRC 2010-02-25T08:51:16 *** brendan_bywater has joined #evergreen 2010-02-25T08:57:17 *** eguest309 has quit IRC 2010-02-25T08:57:30 *** eguest309 has joined #evergreen 2010-02-25T08:58:43 *** Dyrcona has joined #evergreen 2010-02-25T09:09:39 *** rsinger has joined #evergreen 2010-02-25T09:10:58 *** gdunbar has joined #evergreen 2010-02-25T09:21:19 *** jenny has joined #evergreen 2010-02-25T09:36:38 *** atz has joined #evergreen 2010-02-25T09:36:44 *** atz has left #evergreen 2010-02-25T09:49:58 Figured out why I could not edit the holds and circulation policies yesterday. 2010-02-25T09:50:46 The permissions were being checked with permission.usr_has_perm_at() which requires the usr to be a super_user before actually checking the permissions. 2010-02-25T09:51:06 My user didn't have super_user set. Setting it to true solved that little problem. 2010-02-25T09:51:20 Thanks to phasefx for suggesting query logging. 2010-02-25T09:54:20 super_user shouldn't be required to use that interface :( 2010-02-25T09:54:48 a super_user is supposed to be able to do anything, bypassing permissions 2010-02-25T09:58:33 *** rsinger has quit IRC 2010-02-25T09:58:46 *** brendan_bywater has quit IRC 2010-02-25T10:01:33 well, that's what we found with logging on. 2010-02-25T10:02:20 It was checking perms with permission.usr_has_perm_at() which calls permission.usr_has_perm_at_nd() and the very first statements in that one looks for the super_user flag and if it isn't set, it bails. 2010-02-25T10:02:35 *** bshum has joined #evergreen 2010-02-25T10:04:43 Well, that's not exactly what the code says it does. It basically says if not found then return; 2010-02-25T10:04:56 if user not found, return 2010-02-25T10:05:13 yes, but I wonder if the false from the super_user field is throwing it off. 2010-02-25T10:05:17 otherwise, if the user is a super user, special consideration 2010-02-25T10:06:04 I am going to do a reload today. I'll get the users in first thing and see what happens with my account set to super_user on. 2010-02-25T10:06:15 It may be more complicated than I think. 2010-02-25T10:06:34 super_user defeats the purpose :-/ 2010-02-25T10:06:36 We'll set another admin to not have super_user and see what he gets. 2010-02-25T10:07:34 yeah, but super_user = true is the only real difference that I could between my account and admin yesterday afternoon. 2010-02-25T10:07:53 i even set my main profile to 1, and it still didn't work. 2010-02-25T10:08:32 may be talking past each other, super_user is why the one account was working, but you should be able to set up a user without it and get it working, otherwise, the code is broken 2010-02-25T10:08:52 that's what I'm saying. 2010-02-25T10:08:58 *8) 2010-02-25T10:09:07 *** brendan_bywater has joined #evergreen 2010-02-25T10:09:16 * phasefx sips more on his coffee 2010-02-25T10:09:24 I tried to set up my account to have permission for everything everywhere and everything but the holds and circulation policies works with that account. 2010-02-25T10:09:43 *** eguest309 has left #evergreen 2010-02-25T10:10:15 adding new holds and circulation policies only worked with the admin account. 2010-02-25T10:10:33 the org_unit and other drop downs come up empty when my account is used. 2010-02-25T10:11:39 I'll give it a good poking after I get some other stuff off my plate 2010-02-25T10:11:47 Maybe it isn't a permissions issue, but I changed everything about my account, including work_ou and home_ou to be the same as admin and restarted all the services and the client and still no dice. 2010-02-25T10:12:24 well, the admin only has one work_ou, the consortium. Some of these interfaces may not allow inheritance of perms by ancestor orgs 2010-02-25T10:12:32 well, i'm gonna look at this today. 'cause I've got not much else evergreen-related to do, and its now my job to look at these things for our consortium. 2010-02-25T10:12:40 which is definitely what that permission call seems to be saying 2010-02-25T10:12:57 Dyrcona++ 2010-02-25T10:13:10 Dyrcona: try giving your non super-user more work_ou's 2010-02-25T10:13:45 phasefx: i'm setting my work_ou to the consortium. maybe that didn't "take" in all the restarts yesterday. 2010-02-25T10:14:32 Dyrcona: right, I'm saying Consortium may not be enough. May need to get explicit, and have multiple work_ou's 2010-02-25T10:14:52 *** levacjeep has quit IRC 2010-02-25T10:17:37 phasefx: ok. we'll test it. i'm going to set myself as super_user and another guy here as non-super_user. otherwise we'll be the same. if it doesn't work for him, we'll add more work_ous to his account to see what happens. 2010-02-25T10:18:59 cool deal 2010-02-25T10:32:25 *** brendan_bywater has quit IRC 2010-02-25T10:35:16 *** frzosima has quit IRC 2010-02-25T11:31:37 *** eby has joined #evergreen 2010-02-25T11:47:54 *** agJohn has joined #evergreen 2010-02-25T12:22:34 Does anybody know what the "stop_blocked_user boolean" in the config.hold_matrix_matchpoint table does? 2010-02-25T12:26:33 *** agJohn has quit IRC 2010-02-25T12:39:15 I'm a little concerned that it seems to block users from a particular patron group from placing holds in the system, if enabled true and there are "bad" patrons in the group. 2010-02-25T12:39:49 Maybe we're not using it right? 2010-02-25T12:44:20 bshum: Is this under hold policies in the client? 2010-02-25T12:44:51 moodaepo: This is one of the missing fields from the staff client's interface, but it does show up in the corresponding table on the database. 2010-02-25T12:45:27 moodaepo: by missing, I just mean that it doesn't seem to show up in the interface 2010-02-25T12:45:48 Ok just making sure, we'd be interested in finding out what that does also then. I was looking through the code here > http://list.georgialibraries.org/pipermail/open-ils-commits/2008-November/003755.html 2010-02-25T12:46:26 Specifically in the change log for trunk/Open-ILS/src/sql/Pg/110.hold_matrix.sql 2010-02-25T12:46:53 Aha 2010-02-25T12:46:59 Wow that seems a long time ago now that I pay attention to the date : ) 2010-02-25T12:47:12 Heh, indeed 2010-02-25T12:48:17 If I'm understanding the code that you just referenced 2010-02-25T12:48:38 It seems to be writing up the ways in which that they're testing to see whether it applies 2010-02-25T12:49:38 *** bbonner has joined #evergreen 2010-02-25T12:50:11 There isn't a "config.hold_matrix_test" table is there? 2010-02-25T12:50:21 Or is that some sort of special view? 2010-02-25T12:55:01 *** pmplett has joined #evergreen 2010-02-25T12:56:10 Ah okay, it's creating hold_test from the matchpoint 2010-02-25T12:58:33 *** mrpeters-isl has quit IRC 2010-02-25T12:59:39 *** mrpeters-isl has joined #evergreen 2010-02-25T13:00:03 Was on the phone... 2010-02-25T13:01:35 moodaepo: I'm working through the information in that 110.hold_matrix.sql 2010-02-25T13:01:40 To see if I can figure it out. 2010-02-25T13:02:37 Will do, I'll look through and see if I understand anything in the actual file 2010-02-25T13:07:22 If I'm understanding it right, it seems like if that "stop_blocked_user" is set to true, it will run a check against the standing penalty table? 2010-02-25T13:07:38 But this is just SQL 2010-02-25T13:07:54 Maybe there's some other file that actually performs or calls these actions? 2010-02-25T13:29:56 *** jamesrf has joined #evergreen 2010-02-25T13:52:09 *** phasefx has quit IRC 2010-02-25T13:54:13 *** Dmagick_ has quit IRC 2010-02-25T14:01:23 moodaepo: Oh, I think I might have figured out our problem with our hold matrix. Apparently there were rules that had "max_holds integer" set to 0. 2010-02-25T14:01:48 When we removed the limitation, the items became holdable again. 2010-02-25T14:04:15 bshum: Yup that would make sense. You are live with the iun-db rules right? 2010-02-25T14:04:33 moodaepo: Yep, that's our plan to use the in-db rules 2010-02-25T14:05:02 moodaepo: I think the staff client inserted a 0 into the max_holds field whenever we created a rule and didn't specify an exact number 2010-02-25T14:05:44 We have ours setup I think need to see how it will work, the cron jobs are what I'm having issues with now. Some of them are working and other's don't : ) 2010-02-25T14:06:19 I despise the crons :) 2010-02-25T14:06:33 We've been having on and off troubles with them for awhile as well. 2010-02-25T14:06:46 Which ones are you guys having issues with? 2010-02-25T14:07:48 I just checked the holds matrix and ours has one entry and the max_holds column is empty not zero 2010-02-25T14:08:44 I think ours came with a default hold rule in place that was null, rather than zero 2010-02-25T14:09:04 But subsequent hold rules we created via the staff client inserted that zero into the field. 2010-02-25T14:09:12 I'm assuming 2010-02-25T14:09:23 Or maybe we were bad and somehow passed that 0 in there ourselves. 2010-02-25T14:09:24 Hmm 2010-02-25T14:09:47 Is there any way to edit the staff client's interface files that generate this stuff to pass to the database? 2010-02-25T14:10:15 Let me add one and check first 2010-02-25T14:10:49 I would try adding one in ours, but I can't open holds or circ policies in my staff client anymore due to the lag time of opening too many rules. 2010-02-25T14:10:56 and the cron jobs which aren't working are action_trigger_runner.pl & overdue/predue, is the action_trigger_runner.pl supported in 1.6.0.2 yet? 2010-02-25T14:12:10 *** phasefx has joined #evergreen 2010-02-25T14:13:00 Confirmed the hold circs does enter 0 for max_holds 2010-02-25T14:13:23 s/hold circs/hold policies/ 2010-02-25T14:13:38 So it is passing a zero by default if we don't specify a number there? 2010-02-25T14:14:07 Yes, I don't know where to change the defaults..I'd look server side in the xul area 2010-02-25T14:14:32 *** natschil has joined #evergreen 2010-02-25T14:15:46 *** greg-g has quit IRC 2010-02-25T14:16:15 Unless of course it's postgres defaulting it to 0, does it do that since max_holds is set as an integer? 2010-02-25T14:17:04 Ok it is not set as " interger NOT NULL" so it might not be postgres 2010-02-25T14:18:35 Well, if it was set to "integer NOT NULL" it wouldn't have allowed us to place null values in it. 2010-02-25T14:18:37 I think. 2010-02-25T14:18:53 On mine, it's just defined simply as "integer" 2010-02-25T14:20:29 *** mrpeters-isl has quit IRC 2010-02-25T14:20:41 *** mrpeters-isl has joined #evergreen 2010-02-25T14:20:53 Right that's what I mean 2010-02-25T14:28:32 *** mrpeters-isl has quit IRC 2010-02-25T14:30:47 *** sfortin has quit IRC 2010-02-25T14:31:48 *** mrpeters-isl has joined #evergreen 2010-02-25T14:37:58 moodaepo: I think this is something to do with conify; I've found something called hold_matrix_matchpoint.tt2 which is a template for that table. I think? 2010-02-25T14:39:22 *** natschil has quit IRC 2010-02-25T14:41:07 *** branflakes has quit IRC 2010-02-25T14:41:26 bshum: I just grepped for max_holds...and found a reference in fmcore.js nothing much there, maybe the request is posted and then passed to other serverside opensrf processors? 2010-02-25T14:45:39 Hmm 2010-02-25T14:53:15 ha, got a "Whoa, Google Chrome has crashed" alert 2010-02-25T14:54:36 unhappy folder? 2010-02-25T14:54:51 was just pulling hard on a scrollbar 2010-02-25T14:57:40 *** mrpeters-isl has quit IRC 2010-02-25T14:58:23 *** greg-g has joined #evergreen 2010-02-25T15:00:33 *** 14WAAAMKM has joined #evergreen 2010-02-25T15:00:46 *** 14WAAAMKM is now known as Dmagick 2010-02-25T15:04:24 *** mrpeters-isl has joined #evergreen 2010-02-25T15:05:27 *** natschil has joined #evergreen 2010-02-25T15:08:49 *** mrpeters-isl has quit IRC 2010-02-25T15:11:19 *** natschil has quit IRC 2010-02-25T15:16:37 *** mrpeters-isl has joined #evergreen 2010-02-25T15:24:20 phasefx: the circulation and hold policies still don't work for a non-super_user even when they have all work_ous assigned. 2010-02-25T15:24:58 the has_perm calls you see hitting the db, if you run them by hand in psql, do they return true? 2010-02-25T15:28:37 *** brendan_bywater has joined #evergreen 2010-02-25T15:31:37 evergreen=# select * from permission.usr_has_perm_at('51860', 'ADMIN_CIRC_MATRIX_MATCHPOINT'); 2010-02-25T15:31:37 usr_has_perm_at 2010-02-25T15:31:37 ----------------- 2010-02-25T15:31:37 (0 rows) 2010-02-25T15:31:48 It returns no rows at all. 2010-02-25T15:33:33 For me, it returns true: 2010-02-25T15:33:36 evergreen=# select * from permission.usr_has_perm_at('604362', 'ADMIN_CIRC_MATRIX_MATCHPOINT'); 2010-02-25T15:33:36 usr_has_perm_at 2010-02-25T15:33:37 ----------------- 2010-02-25T15:33:37 1 2010-02-25T15:33:37 (1 row) 2010-02-25T15:34:33 select * from permission.perm_list where code = 'ADMIN_CIRC_MATRIX_MATCHPOINT'; 2010-02-25T15:35:09 evergreen=# select * from permission.perm_list where code = 'ADMIN_CIRC_MATRIX_MATCHPOINT'; 2010-02-25T15:35:09 id | code | description 2010-02-25T15:35:09 ----+------+------------- 2010-02-25T15:35:09 (0 rows) 2010-02-25T15:35:23 So, we don't even have the permission in the database. 2010-02-25T15:35:28 okay, so it's looking for that perm, which doesn't exist. It doesn't exist for me either in trunk 2010-02-25T15:36:46 Dyrcona: could you bug that on launchpad? For now, you should be able to add that perm manually (there should be a UI for this), and grant it to the appropriate perm groups 2010-02-25T15:37:50 ok. 2010-02-25T15:37:55 the bug isn't just the lack of the perm, but the ungraceful handling of its lack in the UI 2010-02-25T15:37:59 Dyrcona++ 2010-02-25T15:46:23 Even after adding the permission, the usr_has_perm_at() fails for a usr in a group that has EVERYTHING permission. Does that need to be updated when new permissions are added later? 2010-02-25T15:47:34 hrmm, I'd expect for the EVERYTHING permission to work regardless of whether ADMIN_CIRC_MATRIX_MATCHPOINT was in perm_list or not 2010-02-25T15:47:49 IOW, a perm doesn't have to exist in perm_list to be tested 2010-02-25T15:48:40 it's possible that the perl services are caching the perm groups; maybe try a restart of the system? 2010-02-25T15:49:24 well that was run right in the database. does the database function talk to the perl services? 2010-02-25T15:49:55 oh yeah, good point 2010-02-25T15:50:00 Explicitly adding that permission to the group works. 2010-02-25T15:50:31 so EVERYTHING doesn't work like I'd expect it to (ie. another way of making a super_user) 2010-02-25T15:50:54 apparently. 2010-02-25T15:51:19 I'd be in favor of ripping one or the other out (super_user or EVERYTHING) 2010-02-25T15:52:20 permission.usr_has_perm_at() does NOT check for an EVERYTHING permission. 2010-02-25T15:53:29 something else in the stack may 2010-02-25T15:53:57 but, apparently not if it wasn't working for loading that UI 2010-02-25T15:54:17 *** peggi has joined #evergreen 2010-02-25T15:56:42 *** peggi has quit IRC 2010-02-25T15:57:05 permission.usr_has_pem_at() calls permission.usr_has_perm_at_nd() which in turn calls no other functions. 2010-02-25T15:57:50 In doing a quick scan, it looks like the other permission function have something like perm.id = id or permi.id = -1 in their where clauses. 2010-02-25T15:58:18 permission.usr_has_perm_at_nd() lacks the "or perm.id = -1" 2010-02-25T15:58:51 I'm going to modify my copy of the code and reload just the function to see if that fixes this. 2010-02-25T16:01:18 *** brendan_bywater has quit IRC 2010-02-25T16:11:12 *** natschil has joined #evergreen 2010-02-25T16:12:05 phasefx: should I submit a patch along with the bug report? I think I have fixed permission.usr_has_perm_at_nd(). 2010-02-25T16:12:09 *** Melissa has left #evergreen 2010-02-25T16:14:15 I'll do it anyway...against trunk. 2010-02-25T16:15:52 Oh, and if anyone is counting, I vote for getting rid of super_user. 2010-02-25T16:16:19 *** Dmagick has quit IRC 2010-02-25T16:18:19 *** bbonner has quit IRC 2010-02-25T16:21:47 *** jenny1 has joined #evergreen 2010-02-25T16:25:00 *** jenny has quit IRC 2010-02-25T16:25:25 *** jamesrf is now known as jamesrf-lunch 2010-02-25T16:31:50 *** grantjohnson has quit IRC 2010-02-25T16:40:19 *** sfortin has joined #evergreen 2010-02-25T16:57:06 Argh Any thoughts on why I'm getting "The requested URL /xul/server/util/rbrowser.xul was not found on this server." when I try to view any report output via client? But they show up via the browser. I'm guessing it started recently i.e. after upgrade to 1.6.0.1/2 2010-02-25T16:57:41 is there a /xul/server/util/ ? 2010-02-25T16:59:02 need to make sure /openils/var/web/xul/server/ exists as a symlink to BUILD/server, for some value of BUILD 2010-02-25T17:02:41 phasefx: thnx that was it for some reason I have "server -> rel_1.6.0.2" and rel_1.6.0.2 exists. Weird 2010-02-25T17:04:14 sounds like the machine John Craig was working with the other day 2010-02-25T17:05:24 when you build and install Evergreen from the top-level source directory, and specificy a STAFF_CLIENT_BUILD_ID, it'll take that value and create a matching directory in /openils/var/web/xul/. If STAFF_CLIENT_BUILD_ID is not specified, it'll get set to date/timestamp 2010-02-25T17:06:37 the files in that installed directory (xul, javascript, etc.) will contain URL's referring to that same value (for example src='/xul/rel_1_6_0_0/server/cat/bib_brief.xul' ) 2010-02-25T17:08:04 one mistake some folks will make is to rename that directory, and then those URL's will be getting 404's against apache 2010-02-25T17:08:41 * phasefx is spewing this for the benefit of the IRC logs 2010-02-25T17:09:21 by convention, the released cut versions of EG come with staff clients where the build id is set to match the subversion tag of the release (rel_1_6_0_0, rel_1_6_01, etc.) 2010-02-25T17:09:30 phasefx++ irc_logs++ 2010-02-25T17:09:47 moodaepo-- # for knowing all this AND making the mistakes 2010-02-25T17:10:19 some sites when they upgrade EG won't specify a build id, and will just create or recreate an appropriate symlink to the newly installed directory 2010-02-25T17:10:34 this allows them to quickly roll back to previous builds very easily 2010-02-25T17:11:53 so you might get something like /openils/var/web/xul/2010-02-25-17-11/, and have a symlink for rel_1_6_0_2 linked to that. And if you want to deprecate the previous staff client and force staff to upgrade, you may delete a symlink for rel_1_6_0_1 2010-02-25T17:13:00 *** bshum has quit IRC 2010-02-25T17:13:47 some code that was built independently of the original client and does not live in /openils/var/xul/ will try to invoke some of the xul interfaces, but they don't always know about the build id's, or were built in the days of "versionless" xul clients used for easy development. They'll look for /xul/server/, so we provide a symlink for that 2010-02-25T17:13:59 *** Dyrcona has quit IRC 2010-02-25T17:14:53 *** george_ has joined #evergreen 2010-02-25T17:15:08 the reporter is the main culprit here 2010-02-25T17:17:00 phasefx: Interesting I was thinking of using the "current" method I think dbs uses but I like what see. 2010-02-25T17:17:20 I tend to use "current" as my build id for trunk :) 2010-02-25T17:18:20 but I think something like rel_1_6_0_1 -> current -> timestamp and server -> current/server is sane 2010-02-25T17:21:11 for development, I have something like this current -> current.bzr -> /home/OpenSRF/bzr/ILS/working_branch/Open-ILS/xul/staff_client/build/ and I do make STAFF_CLIENT_BUILD_ID=current devbuild from the staff_client/ directory 2010-02-25T17:23:56 if you ever want to build the client independently of a machine running EG, you can do this in the top-level directory: (./autogen.sh if not from a released tarball &&) ./configure --disable-core --disable-web --disable-reporter && cd Open-ILS/xul/staff_client/ && make STAFF_CLIENT_BUILD_ID='foo' build 2010-02-25T17:24:59 * phasefx used to do this in cygwin before we went with autotools :) 2010-02-25T17:25:41 which at the time was wanting to see stuff from memcached, ejabberd, etc. May work now with the --disable-directives 2010-02-25T17:25:54 *** george_ has quit IRC 2010-02-25T17:29:55 phasefx: Nice! Talking about autotools do you know when the buildbot magic is coming back? 2010-02-25T17:32:49 *** jenny1 has left #evergreen 2010-02-25T17:34:35 I don't, but I can do some poking next week 2010-02-25T18:23:58 *** jamesrf-lunch has quit IRC 2010-02-25T18:47:39 does anyone know if the hackfests have been determined for the conference? 2010-02-25T18:53:57 * eby emails the list 2010-02-25T18:57:31 *** sfortin has quit IRC 2010-02-25T19:23:15 *** jamesrf has joined #evergreen 2010-02-25T20:03:06 *** frzosima has joined #evergreen 2010-02-25T20:27:12 eby: haven't seen your mail come through yet. perhaps the Great Greylist strikes again. 2010-02-25T20:27:54 fantastico 2010-02-25T20:28:26 jeff: on general 2010-02-25T20:28:30 i see it in the archive 2010-02-25T20:28:38 http://libmail.georgialibraries.org/pipermail/open-ils-general/2010-February/002561.html 2010-02-25T20:32:12 aha. i appear to have been staring at a day-old instance of my inbox. see it now. 2010-02-25T21:05:22 *** pmplett is now known as pmp_afk 2010-02-25T21:09:19 *** wlayton has joined #evergreen 2010-02-25T21:53:35 *** eby_ has joined #evergreen 2010-02-25T21:53:35 *** eby has quit IRC 2010-02-25T21:53:36 *** eby_ is now known as eby 2010-02-25T22:01:54 *** jamesrf has quit IRC 2010-02-25T22:12:28 *** wlayton has quit IRC 2010-02-25T23:23:07 *** frzosima has quit IRC 2010-02-25T23:34:42 *** phase_bb has quit IRC