| Time |
Nick |
Message |
| 02:58 |
|
abowling1 joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:28 |
|
rlefaive joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
agoben joined #evergreen |
| 08:01 |
|
Dyrcona joined #evergreen |
| 08:31 |
Dyrcona |
So, I've got reports of the Home Library select list being empty in edit patron and register patron. |
| 08:31 |
Dyrcona |
AFAIK, it is only affecting 3 users: myself and two others at central site. |
| 08:32 |
Dyrcona |
If you try to save an updated patron in this state, you get a database error from the home_ou not being set. |
| 08:32 |
Dyrcona |
We're using the alt_patron_summary branch. |
| 08:33 |
Dyrcona |
I'm about to dive into the code and try retrieving the org tree as my own user with backend calls to see if any errors pop up. |
| 08:33 |
Dyrcona |
I thought I'd throw this situation out there in case someone else has encountered it before and has ideas where I should look. |
| 08:36 |
csharp |
Dyrcona: is it intermittent for the affected users? |
| 08:36 |
Dyrcona |
csharp: Nope. All the time. |
| 08:36 |
Dyrcona |
The person who reported it claimed it started at 9:50 am yesterday, but the logs don't show her trying to update a patron until about that time. |
| 08:37 |
Dyrcona |
At least, for yesterday. |
| 08:37 |
Dyrcona |
I have a hunch that I'm going to investigate before writing any code. |
| 08:37 |
Dyrcona |
I'm going to to check in the training database, too. |
| 08:38 |
Dyrcona |
Once I download the client. |
| 08:38 |
csharp |
autogen.sh is the only thing I can think of, but I've never seen that or had reports of it |
| 08:38 |
* csharp |
knocks on wood |
| 08:39 |
Dyrcona |
If autogen.sh would fix it, then everyone would have the problem, and the phones would be ringing off the hook. :) |
| 08:39 |
Dyrcona |
I think it's permissions/work_ou related. |
| 08:42 |
|
StomproJ joined #evergreen |
| 08:43 |
Dyrcona |
No training client on updates/manualupdate.html, so I'll just wipe out my workstation and register a new one in production to see if that makes a difference. |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:45 |
csharp |
oh, yeah - perms would explain that too |
| 08:45 |
|
krvmga joined #evergreen |
| 08:45 |
csharp |
empty dojo dropdowns usually means a missing perm in my experience |
| 08:47 |
Dyrcona |
csharp: Yeah, that's my angle, now. The workstation_ou is probably not the problem. |
| 08:48 |
Dyrcona |
I thought maybe it was registered an ou that can't have users or something, but you can't register those, and that's not the case in my account. |
| 08:48 |
Dyrcona |
I'll check home_ou on these users, too. Maybe those can't have users. |
| 08:48 |
Dyrcona |
To the database! |
| 08:50 |
Dyrcona |
And, it's cold in here. |
| 08:50 |
Dyrcona |
@weather |
| 08:50 |
pinesol_green |
Dyrcona: Methuen, MA :: Clear :: 2F/-17C | Wind Chill: -15F/-26C | Friday: Sunny. High 18F. Winds W at 10 to 15 mph. Friday Night: Partly cloudy skies this evening will give way to cloudy skies with snow developing overnight. Low near 15F. Winds light and variable. Chance of snow 80%. Snow accumulations less than one inch. |
| 08:51 |
* Dyrcona |
checks the heat. |
| 08:51 |
krvmga |
@weather |
| 08:51 |
pinesol_green |
krvmga: Worcester, MA :: Clear :: 1F/-17C | Wind Chill: -17F/-27C | Friday: Sunny. High 17F. Winds W at 10 to 15 mph. Friday Night: Partly cloudy skies this evening will give way to cloudy skies with snow developing overnight. Low 14F. Winds SW at 5 to 10 mph. Chance of snow 90%. Snowfall around one inch. |
| 08:53 |
Dyrcona |
"Ahh, but it's cold outside....." |
| 08:53 |
Dyrcona |
Anyone else sick of Christmas songs, yet? |
| 08:54 |
* csharp |
raises his hand |
| 08:54 |
* krvmga |
raises his hand. |
| 08:55 |
krvmga |
not that I have anything against Christmas songs but how many times to I have to hear "Santa, baby"? |
| 08:55 |
* mmorgan |
was already sick of them in early November ;-) |
| 08:55 |
Dyrcona |
Well, krvmga's is working and he's the same profile as two of us for whom it does not work. |
| 08:56 |
krvmga |
yes, it is working for me - confirmed |
| 08:56 |
mmorgan |
Dyrcona: Just a stab in the dark. Have you tried clearing the client cache? |
| 08:56 |
* Dyrcona |
checks for extra user permissions. |
| 08:57 |
Dyrcona |
mmorgan: I've quit the client and even blown out my openils_staff_client XUL profile directory. |
| 08:57 |
mmorgan |
That shoud cover it! |
| 08:57 |
Dyrcona |
One user wiped out his windows profiles and reinstalled the client. |
| 09:02 |
Dyrcona |
No usr_perm_map or usr_grp_map entries for krvmga, and all home_ous are regular branches.... |
| 09:02 |
Dyrcona |
So, we should have the same permissions.... |
| 09:03 |
mmorgan |
Dyrcona: When krvmga logs in at the workstation of a user that is seeing the problem, can he see the dropdown? |
| 09:03 |
Dyrcona |
mmorgan: I don't think that was done, but I'll ask him. |
| 09:03 |
krvmga |
sec, let me check... |
| 09:03 |
Dyrcona |
:) |
| 09:06 |
Dyrcona |
The other user with the same profile having the problem has a permission that krvmga and I do not have, but having an additional permission would not be it. |
| 09:08 |
krvmga |
ok, the user with the problem logged in on a machine of a user who was *not* having the problem; still had problem. |
| 09:08 |
krvmga |
seems to be following the login |
| 09:09 |
Dyrcona |
So, if the group was granted EVERYTHING at depth 0, why have other permission granted? |
| 09:10 |
Dyrcona |
krvmga: Thanks for checking. I'm stumped. :( |
| 09:10 |
mmorgan |
Any changes made to perms lately? |
| 09:10 |
Dyrcona |
Not by me, but the group that we're has EVERYTHING at depth 0, so it can't be permissions. |
| 09:11 |
Dyrcona |
I'm tempted to remove the other permissions on the group and see what happens. |
| 09:13 |
mmorgan |
Dyrcona: could lp 1480432 be related? |
| 09:13 |
pinesol_green |
Launchpad bug 1480432 in Evergreen "Staff users can have permission at a more restrictive depth than assigned via a permission group" [Undecided,New] https://launchpad.net/bugs/1480432 |
| 09:14 |
Dyrcona |
But that would affect everyone in the group, no? |
| 09:16 |
mmorgan |
Not necessarily. In my experience it's caused problems for individual users that had more than one group assigned. |
| 09:16 |
Dyrcona |
And none of the parent groups have any permissions assigned. |
| 09:17 |
mmorgan |
If your users don't have secondary groups, then it's probably not your issue. |
| 09:18 |
Dyrcona |
But we don't have more than 1 group assigned. |
| 09:18 |
krvmga |
i just did the opposite test from the previous one: i logged in as myself on a client where the user wasn't seeing the library dropdown list; saw it as me; didn't see it as the other user. |
| 09:19 |
Dyrcona |
krvmga: Thanks, again. ;) |
| 09:19 |
krvmga |
same permission group; network administrator |
| 09:19 |
mmorgan |
ok. It would be interesting to see what happens if you were to remove the extra permissions from the users seeing the problem. |
| 09:19 |
Dyrcona |
I'm going to remove the extra permissions from the group to a separate table. |
| 09:19 |
Dyrcona |
:) |
| 09:23 |
Dyrcona |
Nope. :( |
| 09:23 |
Dyrcona |
Unless memcached has entries that I need to delete.... That's asking too much. |
| 09:25 |
tsbere |
Dyrcona: Have you checked to see if there are any horribly broken things in the org tree? |
| 09:25 |
tsbere |
Or group tree |
| 09:25 |
tsbere |
Or whichever one you are having issues with |
| 09:25 |
* tsbere |
hasn't fully read the scrollback |
| 09:25 |
Dyrcona |
Well, I don't know what I'm having trouble with, and I would think either of those would cause problems for everybody, not just some people and not others. |
| 09:25 |
tsbere |
I once got "things don't load right" in my dev machine with a bad entry or two |
| 09:26 |
tsbere |
And they only applied to "Everyone" on the org tree one due to one of the issues being a permission def, so it wasn't loading that entry otherwise |
| 09:26 |
tsbere |
or Everything or whatever |
| 09:26 |
* tsbere |
is still too cold this morning |
| 09:26 |
Dyrcona |
Just to get everyone up to speed: I've got four accounts with the same permission group. It works for two of them and not for the other two. |
| 09:27 |
Dyrcona |
That have been definitively reported so far. |
| 09:27 |
tsbere |
That...sounds odd. How do their work OU sets vary? |
| 09:27 |
Dyrcona |
I've got two other users that say it doesn't work for them, but I don't know their permission group(s). |
| 09:31 |
Dyrcona |
tsbere: They vary, but it looks like I can work at every branch, including the one that I signed in at. |
| 09:34 |
|
yboston joined #evergreen |
| 09:42 |
|
mmorgan joined #evergreen |
| 09:47 |
|
maryj joined #evergreen |
| 09:56 |
|
mmorgan joined #evergreen |
| 10:42 |
|
mmorgan1 joined #evergreen |
| 10:47 |
Dyrcona |
tsbere: Turned out to be an org_unit was changed yesterday for testing. It was assigned an ou_type with the wrong depth when testing was done. |
| 10:47 |
Dyrcona |
Why this did not break the list for everybody is beyond me. |
| 10:50 |
tsbere |
Dyrcona: I assume it is in part due to work ous. How many of the people it was broken for were logged into or assigned their work OU at/below that org unit versus not at/below it? |
| 10:50 |
Dyrcona |
That's a good question. krvmga changed his ous after I last looked. I'm pretty sure that I could work at this ou. I'll check where the others can/can't work. |
| 10:52 |
|
bos20k joined #evergreen |
| 10:52 |
Dyrcona |
Ah ha! It was the sibling ou. |
| 10:52 |
Dyrcona |
We could all work at the ou in question, but only two of us could work at the sibling ou. |
| 10:53 |
Dyrcona |
The two ous having different depths and the same parent must have been what broke it. |
| 10:54 |
Dyrcona |
Hm... that's not exactly right when I look again. |
| 10:55 |
Dyrcona |
krvmga and I could work there, and krvmga added his permission after the trouble started, because id is above X. |
| 10:55 |
Dyrcona |
One of the other affected people could work there, but not the first one. Does that even make sense? |
| 10:56 |
Dyrcona |
Of the 3 people with the same problem, two of had permission at that ou. |
| 10:56 |
Dyrcona |
Well, it's fixed, now, and I know the rough cause. |
| 11:02 |
|
Christineb joined #evergreen |
| 11:02 |
Dyrcona |
tsbere++ csharp++ mmorgan++ |
| 11:03 |
Dyrcona |
DBI++ |
| 11:03 |
Dyrcona |
Data::Dumper++ |
| 11:03 |
Dyrcona |
diff++ |
| 11:03 |
Dyrcona |
krvmga++ |
| 11:03 |
Dyrcona |
perl_hashes_not_being_randomly_ordered++ |
| 11:08 |
berick |
they are randomly ordered now aren't they? well, undefined and potentially varried ordering |
| 11:10 |
Dyrcona |
berick: They didn't appear to be in my case. |
| 11:10 |
|
brahmina joined #evergreen |
| 11:11 |
Dyrcona |
I dumped the results of fetchall_hashref on actor.org_unit_descendants(1) from two databases and got practically identical files. |
| 11:11 |
Dyrcona |
But, yeah, I think newer Perl does randomize them a bit. |
| 11:12 |
berick |
yeah, just sayin i wouldn't count on it |
| 11:12 |
krvmga |
Dyrcona++ |
| 11:12 |
Dyrcona |
Well, then, I'd just have to sort the output by keys before calling Data::Dumper is all. :) |
| 11:13 |
berick |
that'll do it :) |
| 11:13 |
Dyrcona |
I actually wrote this line yesterday: |
| 11:13 |
Dyrcona |
my @results = sort {$b->{score} <=> $a->{score}} sort {$b->{id} <=> $a->{id}} values %merged; |
| 11:15 |
Dyrcona |
Perl is so readable.... ;) |
| 11:30 |
|
jvwoolf joined #evergreen |
| 11:53 |
|
mmorgan joined #evergreen |
| 11:59 |
|
mmorgan joined #evergreen |
| 12:03 |
|
bmills joined #evergreen |
| 12:05 |
* mmorgan |
needs a sanity check on hold matrix matchpoints. |
| 12:05 |
mmorgan |
config.hold_matrix_matchpoint.usr_grp seems to apply to action.hold_request.requestor |
| 12:05 |
mmorgan |
and |
| 12:05 |
mmorgan |
config.hold_matrix_matchpoint.requestor_grp seems to apply to action.hold_request.usr |
| 12:05 |
mmorgan |
Am I seeing this right? |
| 12:06 |
Dyrcona |
That's not my understanding. |
| 12:08 |
mmorgan |
I set up a matchpoint to make items with a certain circ lib NOT holdable for Users. |
| 12:09 |
mmorgan |
Then another matchpoint to make a certain permission group able to place holds for items with that circ lib. |
| 12:09 |
Dyrcona |
Looking at action.find_hold_matrix_matchpoint the requestor is the requestor and the user is the patron the hold is being made for. |
| 12:10 |
Dyrcona |
They can be the same user if the user is placing the hold on their own behalf, like a patron using the OPAC. |
| 12:11 |
|
Newziky joined #evergreen |
| 12:11 |
mmorgan |
Right. What I'm actually trying to do is fix a ComCat problem. |
| 12:11 |
Dyrcona |
What are you trying to do, exactly? |
| 12:11 |
|
Newziky left #evergreen |
| 12:12 |
miker |
mmorgan: do you have the global flag called circ.holds.usr_not_requestor enabled? |
| 12:12 |
miker |
if so, that swaps the meaning of the fields. it's from before we had matrix weights |
| 12:14 |
Dyrcona |
Last time I checked there were about 40 org settings that affect holds. |
| 12:15 |
miker |
well, yes |
| 12:15 |
miker |
but that one in particular is designed to cause exactly what mmorgan is describing |
| 12:15 |
mmorgan |
miker: Why yes, that is enabled. Not sure why it is. |
| 12:15 |
Dyrcona |
But, yeah, that is a good one to look at. I always forget about it because I've always had it false. |
| 12:15 |
mmorgan |
But that certainly explains it. |
| 12:16 |
Dyrcona |
miker++ |
| 12:16 |
mmorgan |
Dyrcona: I was trying to explicitly make ComCat items holdable for only the ComCat permission group as the requestor. |
| 12:16 |
mmorgan |
miker++ |
| 12:17 |
|
Newziky joined #evergreen |
| 12:17 |
|
Newziky left #evergreen |
| 12:17 |
miker |
mmorgan: if you use a lot of rules that involve groups, untangling that could become a ... job |
| 12:17 |
Dyrcona |
mmorgan: Makes sense. I think we might have done that at MVLC. I don't usually deal with the matrix at C/W MARS. |
| 12:17 |
miker |
or, rather, lots of matchpoints that have differing usr and requestor values |
| 12:18 |
Dyrcona |
Well, even adding something like a Local Use Only group becomes a headache very quickly. |
| 12:19 |
Dyrcona |
You quickly end up adding exceptions to other exceptions..... |
| 12:19 |
Dyrcona |
Rules aren't rules, apparently. ;) |
| 12:20 |
Dyrcona |
But, yeah, changing that setting might lead to some surprises with matrix matchpoints that "work," now.... I think that's where miker is going. |
| 12:20 |
miker |
indeed, it is :) |
| 12:20 |
mmorgan |
Yeah. sounds like ... a job ;-) |
| 12:21 |
Dyrcona |
I have a Perl script that will dump the circ and hold matrices, along with other settings, into an Excel workbook if you think that would be helpful. |
| 12:24 |
Dyrcona |
It's on my github: https://github.com/Dyrcona/evergreen_utilities/blob/master/perl/parameters.pl |
| 12:24 |
mmorgan |
Dyrcona: Thanks! I'll take a look at it. |
| 12:25 |
mmorgan |
Dyrcona++ |
| 12:25 |
mmorgan |
So it looks like by default that global flag is set to true? http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/950.data.seed-values.sql#l11536 |
| 12:27 |
|
kmlussier joined #evergreen |
| 12:27 |
Dyrcona |
Indeed it does. |
| 12:28 |
* mmorgan |
didn't remember changing it. |
| 12:30 |
mmorgan |
So with weighting, sounds like it should be set to false by default. |
| 12:30 |
Dyrcona |
I'd agree with that. |
| 12:31 |
mmorgan |
I can open a Launchpad bug. |
| 12:31 |
Dyrcona |
OK. |
| 12:31 |
Dyrcona |
At MVLC, I don't think we used requestor much. |
| 12:33 |
mmorgan |
We don't use requestor all that much either. Most of our hold policies are pretty general. |
| 12:34 |
Dyrcona |
I do know we turned that flag off. |
| 12:39 |
Dyrcona |
If it weren't for "backwards compatibility," I'd vote for just removing that flag. |
| 12:40 |
Dyrcona |
Maybe remove it from the base schema, but not remove it via upgrade script? |
| 12:45 |
mmorgan |
lp 1650641 |
| 12:45 |
pinesol_green |
Launchpad bug 1650641 in Evergreen "Global flag circ.holds.usr_not_requestor should not default to TRUE" [Undecided,New] https://launchpad.net/bugs/1650641 |
| 12:50 |
kmlussier |
mmorgan: I think you missed a 'not' in the description. |
| 12:51 |
mmorgan |
kmlussier: Indeed! Thanks for proofreading. |
| 12:51 |
mmorgan |
kmlussier++ |
| 12:52 |
kmlussier |
mmorgan++ |
| 12:53 |
Dyrcona |
mmorgan++ |
| 12:58 |
miker |
mmorgan++ |
| 12:59 |
* Dyrcona |
whips out his trusty git pickaxe to do some digging. |
| 13:02 |
|
Newziky joined #evergreen |
| 13:04 |
|
Newziky left #evergreen |
| 13:07 |
JBoyer |
If memory serves I was desperate for that holds flag, because the NULL / NOT NULL stuff for requestor_grp and usr_grp make no sense and we're never cared who requested anything; only who gets it. (I'm not saying requestor_grp shouldn't be in the holds matrix, I'm just complaining that it's NOT NULL and usr_grp is...) |
| 13:07 |
JBoyer |
And it's silly to just set requestor_grp=(Users) for every single row. |
| 13:08 |
tsbere |
JBoyer: I think that flag actually stemmed from when usr wasn't actually checked by the rules, only requestor, so that flipped the two to allow usr to be checked. <_< |
| 13:09 |
JBoyer |
tsbere, implying that now it does nothing but cause confusion, or that it doesn't do much? |
| 13:10 |
tsbere |
JBoyer: I think it still does the flip, but now that the hold rules can and do check both anyway... |
| 13:10 |
tsbere |
Really all it does now is make the hold matrix lie about which is which when set ;) |
| 13:11 |
mmorgan |
... and it does cause confusion.;-) |
| 13:11 |
tsbere |
May still be important for those who have rules that depend on it being true, but an upgrade script that swaps the two in the hold matrix when it is turned on could fix that |
| 13:12 |
miker |
tsbere: well, it's more complicated than that, unfortunately. it drives the creation of double rules (one for each direction) for some old-time users |
| 13:12 |
Dyrcona |
I will comment on the bug, but I think it should be removed from the base schema, and left untouched in existing installations. |
| 13:13 |
miker |
so I wouldn't recommend ripping it out entirely, but we could make it an internal flag to hide it from the UI |
| 13:13 |
miker |
and, +1 to false-by-default |
| 13:13 |
JBoyer |
I'd be all for a big fix that 1. swaps them or not depending on the setting, 2. deletes the setting, 3. makes requestor_grp nullable, and 4. adds a CHECK constraint to make sure that at least one of them is set. (Or, alternately, make usr_grp the NOT NULL field...) |
| 13:14 |
JBoyer |
But I'll admit that I barely ever see or think about chmm anymore, so I'm just grousing because it's "ugly." ;) |
| 13:15 |
* mmorgan |
agrees that it should be left untouched in existing installations. I wouldn't want an upgrade script to suddenly change the structure of the matrix. |
| 13:19 |
mmorgan |
What about a not null constraint on both usr_grp and requestor_grp, but defaulting both to Users? |
| 13:25 |
JBoyer |
That ends up working like the check constraint version; at least one is necessary. |
| 14:02 |
|
kmlussier joined #evergreen |
| 14:05 |
|
krvmga joined #evergreen |
| 14:06 |
|
kmlussier joined #evergreen |
| 14:09 |
Bmagic |
@weather 65203 |
| 14:09 |
pinesol_green |
Bmagic: Columbia, MO :: Fog :: 27F/-3C | Wind Chill: 16F/-9C | Friday: Cloudy skies. Patchy freezing drizzle possible. High 36F. Winds SE at 10 to 20 mph. Friday Night: Cloudy skies this evening. A few showers developing late. Low 34F. Winds SE at 10 to 15 mph. Chance of rain 40%. | Updated: 15m ago |
| 14:10 |
Dyrcona |
@weather |
| 14:10 |
pinesol_green |
Dyrcona: Methuen, MA :: Clear :: 14F/-10C | Wind Chill: 3F/-16C | Friday: Abundant sunshine. High 16F. Winds SW at 5 to 10 mph. Friday Night: Partly cloudy skies early then becoming cloudy with periods of snow late. Low 14F. Winds light and variable. Chance of snow 80%. Snow accumulations less than one inch. |
| 14:10 |
Dyrcona |
It warmed up! |
| 14:48 |
Dyrcona |
Question about the make_release script: If I do the -b (build only) option, the only other option that I need specify is -j, right? |
| 14:49 |
Dyrcona |
Guess I should specify the version (-v), too. |
| 15:06 |
Stompro |
Anyone have any suggestions for web meeting software? I've used join.me before and it seems pretty simple. |
| 15:06 |
Stompro |
In a good way... |
| 15:11 |
bmills |
Stompro: we do most of our online meetings with GoToMeeting |
| 15:14 |
Stompro |
Thanks bmills |
| 15:15 |
bmills |
Stompro: the pricing wasn't so bad for the amount of use we get out of it for committee meetings, council meetings, trainings, etc.. |
| 16:02 |
|
mmorgan joined #evergreen |
| 16:11 |
|
StomproJ joined #evergreen |
| 17:01 |
|
jvwoolf left #evergreen |
| 17:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:25 |
jonadab |
StomproJ: I believe freenode has a web client. |
| 17:26 |
StomproJ |
jonadab, is this in reference to my web meeting software question? |
| 17:30 |
|
bmills joined #evergreen |
