| Time |
Nick |
Message |
| 00:00 |
ssieb |
according to the edit interface, the user should have consortium login access |
| 00:00 |
ssieb |
I did later check the work OU of a branch, but that didn't make any difference |
| 00:00 |
dbs |
I wonder if that might be the issue; the consortium is more of an ephemeral thing, whereas people generally are granted permissions at a given physical location like a branch |
| 00:01 |
ssieb |
where would I change that? The home library is set to a branch |
| 00:02 |
dbs |
oh that's really weird then, if they can't log into their account through the catalog |
| 00:03 |
ssieb |
yes, the group permissions grant login at the consortium level |
| 00:04 |
dbs |
yeah, might be better to grant super user access and move on for now |
| 00:05 |
dbs |
assuming the whole start opensrf services, run autogen.sh, start apache, start staff client process in order from an everything having been stopped state, I have no idea why you're having trouble :/ |
| 00:05 |
ssieb |
ok, it's the Users group that grants consortium OPAC_LOGIN and the Staff group grants consortium STAFF_LOGIN |
| 00:06 |
ssieb |
I went beyond that, I reinstalled the whole thing again even |
| 00:06 |
ssieb |
is there anyone I could contact to get further help? |
| 00:06 |
ssieb |
Maybe the mailing list? |
| 00:09 |
ssieb |
you said the grantable checkbox meant the permission could be granted to others? |
| 00:09 |
dbs |
ssieb: correct |
| 00:10 |
ssieb |
in the Staff group, there is a consortium REGISTER_WORKSTATION permission with grantable unchecked, but the user (even yesterday) wasn't able to register the workstation |
| 00:10 |
ssieb |
I had to do it as egadmin |
| 00:11 |
ssieb |
I just checked the grantable checkbox for STAFF_LOGIN and now the user has login permission! |
| 00:11 |
dbs |
IRC is your best bet when people are active; we'll try to help on the mailing lists too but there's a lot of lag for questions like "Did you change the actor.org_unit hierarchy?" |
| 00:12 |
dbs |
(When we went live 7 years ago, on the first day one of our administrators managed to make their library a child of itself and brought everything down... hah) |
| 00:12 |
dbs |
But if you can put a lot of detail into an email looking for help, that can help people in IRC avoid re-asking the same questions :) |
| 00:13 |
ssieb |
btw, I'm using the beta version if that matters |
| 00:13 |
ssieb |
but it looks like there's a permission issue |
| 00:13 |
dbs |
beta? |
| 00:13 |
ssieb |
2.11.beta |
| 00:13 |
dbs |
oh 2.11 release candidate |
| 00:13 |
ssieb |
It still says beta on the website :-) |
| 00:14 |
ssieb |
but did you see what I did with grantable? |
| 00:14 |
dbs |
right. sorry I'm on 2.10.6, we were going to upgrade to 2.11 but made the call that there was still too much churn a few weeks back |
| 00:14 |
dbs |
ah, http://evergreen-ils.org/egdownloads/ says RC, I'm sure beta is somewhere though |
| 00:14 |
dbs |
what? |
| 00:15 |
dbs |
wow. Okay that's unexpected |
| 00:15 |
ssieb |
oh! it changed since I last refreshed the page :-D |
| 00:15 |
dbs |
(that checking off "grantable" enabled login) |
| 00:15 |
dbs |
hah! |
| 00:16 |
dbs |
there might still be some dragons to work out in this RC, but what better way to contribute to the community than to fearlessly charge ahead? heh. |
| 00:18 |
ssieb |
I thought by beta it should be pretty stable and I didn't want to have to upgrade it soon... :-( |
| 00:19 |
dbs |
Yeah, so all of the "grantable" values for STAFF_LOGIN and USER_LOGIN in our database's permission.grp_perm_map are FALSE. |
| 00:19 |
dbs |
So that's really weird what you're seeing. |
| 00:19 |
ssieb |
so the database query now returns true for usr_has_work_perm, but it still doesn't work |
| 00:19 |
dbs |
le sigh |
| 00:20 |
ssieb |
oh, never mind!!! urgh |
| 00:20 |
ssieb |
somewhere along the way I put 1 instead of 2... :-( |
| 00:20 |
dbs |
easily done. off-by-one errors are the most common plague for technical types right |
| 00:21 |
ssieb |
so that was an irrelevant side track |
| 00:21 |
ssieb |
ok, so I have to decide, super user or try 2.10 |
| 00:22 |
ssieb |
at this point 2.10 should be an easy change, since I've already reinstalled so many times... |
| 00:23 |
ssieb |
there is an interesting issue though. How do you edit the OUs before you start a staff client? Because the first staff client will be registered to the CONS OU which doesn't exist after you edit the OU structure. |
| 00:24 |
ssieb |
and yet somehow that client still works |
| 00:27 |
dbs |
I do almost all of my work directly with the database |
| 00:27 |
dbs |
But when you rename the consortium, the surrogate ID (1) in actor.org_unit still remains the same |
| 00:28 |
dbs |
Just keep it at the top level, and shuffle around all of the underlings if you're using the staff client to shift things around |
| 00:29 |
ssieb |
ok, that's what I've done |
| 00:31 |
dbs |
don't forget to crank down logging again :) |
| 00:31 |
ssieb |
yes! |
| 00:33 |
ssieb |
well, the only one that would matter is postgresql because everything else is going to be replaced anyway |
| 00:41 |
ssieb |
There is no configuration for full text search config, for the database version you have installed (95). |
| 00:41 |
ssieb |
2.11 did not give me that message |
| 00:42 |
dbs |
Ah, probably because when 2.10 was released, postgresql 9.5 didn't exist |
| 00:43 |
dbs |
or wasn't being shipped by default with any of the major distros we use |
| 00:43 |
ssieb |
hopefully it still works |
| 00:43 |
ssieb |
I'm using Fedora btw |
| 00:43 |
dbs |
yes, I don't think the fts config has changed since 9.0, we should probably make it less worrisome |
| 00:43 |
ssieb |
unfortunately this requires turning off selinux |
| 00:44 |
ssieb |
I did actually get it work on a Fedora system with selinux enabled, but it was way too much work |
| 00:44 |
dbs |
note that I think we officially recommend 9.4 |
| 00:44 |
dbs |
yeah! I wrote a good chunk of the fedora instructions, that's my day-to-day laptop OS |
| 00:44 |
ssieb |
there are some updates required though :-) |
| 00:44 |
ssieb |
particularly the use of yum |
| 00:45 |
dbs |
Oh I'm sure |
| 00:45 |
dbs |
My job changed and I have been unable to do much Evergreen dev work for a couple of years :( |
| 00:45 |
ssieb |
oh, I see |
| 00:46 |
dbs |
So F21/F22 era was probably the last time I really updated any fedora bits |
| 00:46 |
dbs |
patches welcome based on your experiences! |
| 00:47 |
ssieb |
oh, one big one that took me a long time to figure out |
| 00:47 |
ssieb |
by default httpd has private tmp |
| 00:47 |
ssieb |
That means uploads totally fail for no apparent reason :-) |
| 01:22 |
|
wsmoak joined #evergreen |
| 01:25 |
|
graced joined #evergreen |
| 01:25 |
|
ssieb joined #evergreen |
| 01:27 |
|
ssieb joined #evergreen |
| 01:28 |
ssieb |
The server I was on apparently got disconnected. |
| 01:28 |
ssieb |
dbs: I gave up and granted the user super user status for now. I'll try to solve it later... |
| 04:04 |
|
akilsdonk joined #evergreen |
| 04:04 |
|
eby joined #evergreen |
| 04:04 |
|
jonadab joined #evergreen |
| 04:04 |
|
pastebot joined #evergreen |
| 04:04 |
|
bshum joined #evergreen |
| 04:04 |
|
mceraso joined #evergreen |
| 04:05 |
|
Stompro joined #evergreen |
| 04:05 |
|
Bmagic joined #evergreen |
| 04:05 |
|
remingtron joined #evergreen |
| 04:05 |
|
Shae joined #evergreen |
| 04:05 |
|
b_bonner joined #evergreen |
| 04:05 |
|
rashma joined #evergreen |
| 04:05 |
|
bcormack joined #evergreen |
| 04:05 |
|
mnsri joined #evergreen |
| 09:29 |
|
Dyrcona joined #evergreen |
| 13:27 |
|
bmills joined #evergreen |
| 15:11 |
|
bmills joined #evergreen |
| 18:36 |
|
Dyrcona joined #evergreen |
