| Time |
Nick |
Message |
| 01:47 |
|
remingtron__ joined #evergreen |
| 03:11 |
|
gsams joined #evergreen |
| 03:46 |
|
dbwells_ joined #evergreen |
| 03:46 |
|
remingtron_ joined #evergreen |
| 07:16 |
|
dbwells_ joined #evergreen |
| 07:25 |
|
Callender joined #evergreen |
| 07:27 |
* csharp |
applies "I Voted" sticker to front of shirt |
| 07:42 |
|
ericar joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:57 |
|
dbwells joined #evergreen |
| 07:57 |
|
remingtron joined #evergreen |
| 08:04 |
|
JBoyer joined #evergreen |
| 08:12 |
|
mrpeters joined #evergreen |
| 08:32 |
|
mdriscoll joined #evergreen |
| 08:38 |
mrpeters |
hey, yeah sorry writing an email to Deanna |
| 08:38 |
mrpeters |
whoops ;P wrong window |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:57 |
|
Dyrcona joined #evergreen |
| 09:34 |
|
sandbergja joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 09:42 |
|
mmorgan1 joined #evergreen |
| 09:43 |
|
maryj joined #evergreen |
| 10:18 |
|
tspindler joined #evergreen |
| 10:21 |
tspindler |
I was wondering if anyone has done work getting the Evergreen OPAC to authenticate against a student system at an academic institution. kmlussier thought maybe dbwells or dbs had done something with this. |
| 10:22 |
berick |
tspindler: you can set up EG to authenticate via LDAP. |
| 10:22 |
dbwells |
tspindler: We authenticate our students via LDAP. |
| 10:23 |
dbwells |
tspindler: We also create and manage our student accounts via a custom sync process which gathers its data from our LDAP system. |
| 10:23 |
tspindler |
Since we are in a consortium environment, what are the issues with pointing to difference LDAP servers for different institutions |
| 10:24 |
tspindler |
dbwells: so you have scripts that keep your student data in the patron database in sync with the LDAP server? |
| 10:24 |
dbwells |
tspindler: AuthProxy.pm can have one or more authenticators defined for every org unit, so multiple LDAP auth should be possible. |
| 10:24 |
dbwells |
tspindler: yes |
| 10:26 |
tspindler |
thanks dbwells |
| 10:33 |
kmlussier |
csharp++ |
| 10:33 |
dbwells |
tspindler: I'm always happy to help troubleshoot Evergreen LDAP issues. My LDAP experience is framed by what we do locally, so I'm eager to work through issues others may have to help make the code more robust. |
| 10:34 |
tspindler |
Thanks dbwells, our next step will be to see if each academic institution will even allow access ot LDAP servers |
| 10:36 |
yboston |
tspindler: shum told me they were using LDAP in Bibliomation too. I am actually about to launch a test of it very soon too |
| 10:36 |
jeff |
Hrm. There is a Welcome to Night Vale live show in Raleigh on April 20. |
| 10:37 |
tspindler |
thanks yboston, bshum just told me that ;) |
| 10:37 |
tspindler |
yboston, have you looked at it at Berklee |
| 10:37 |
jeff |
tspindler: If the institutions are hesitant to do LDAP, I'd be interested in hearing what they are open to -- SAML, CAS, OAuth 2.0, other... |
| 10:38 |
jeff |
I can see them hesitant to do LDAP outside their organizational boundaries. |
| 10:38 |
tspindler |
jeff: i'm really not sure until we ask |
| 10:39 |
jeff |
tspindler: I figured -- I was just voicing my interest in hearing what they said after you ask. :-) |
| 10:39 |
tspindler |
jeff: once we know I can report back |
| 10:40 |
gsams |
jeff: I have tickets to see the show here in Dallas on July 11. I'm looking forward to it. |
| 10:41 |
yboston |
tspindler: I am just about to fire up a VM with our LDAP credentials then I ill try it in our test Vm hosted by ESI. The long term plan is to use SAML "single sign on" |
| 10:41 |
yboston |
BTW, anyone here using SAML "single signon" with EG? |
| 10:42 |
jeff |
gsams: I was looking at their schedule and thinking "Cleveland... that might be worth the trip... oh, Detroit's a bit closer... oh hey, Raleigh... wouldn't that be funny if it was while I'm already going to be there for... hah!" |
| 10:44 |
jeff |
yboston: I'm not aware of any Evergreen support for SAML (either as IdP or SP), but it is something that interests me. |
| 10:54 |
|
Christineb joined #evergreen |
| 11:09 |
|
mmorgan joined #evergreen |
| 11:16 |
|
artunit_away joined #evergreen |
| 11:19 |
|
pdot joined #evergreen |
| 11:22 |
pdot |
Hey everyone, after adding "EVERYONE" at the branch level to circulation admins (by group) none of said users appear to be able to login. I get a "PERM_ERROR" in my logs, but I'm not certain how to troubleshoot from there |
| 11:23 |
tsbere |
pdot: Did you assign work ous? |
| 11:24 |
* tsbere |
also isn't 100% sure what was meant by the original statement |
| 11:25 |
pdot |
one moment, I'll clairify |
| 11:28 |
pdot |
so in server administration -> permission groups -> staff -> circulation administrator -> group permissions, I've added "everything" at depth branch. |
| 11:29 |
Dyrcona |
pdot: You probably don't want to do that, but did you quit the client and start it up, again? |
| 11:30 |
Dyrcona |
Or, did you get the perm error trying to add the permission? |
| 11:30 |
pdot |
now said users get a generic "login failed" error on login. |
| 11:32 |
pdot |
ah, so my use case (there's probably a better way to set permisions?) is that I have a branch managed entirely by volunteers, as such they need a great deal of permissions" |
| 11:32 |
Dyrcona |
Volunteers are usually the last people who need a great deal of permissions. :) |
| 11:33 |
pdot |
until you have literally no staff ;) they handle registration, sign in/ out restocking, etc. |
| 11:34 |
Dyrcona |
I'll go back to tsbere's question, do these users have permission.usr_work_ou_map entries in the database? |
| 11:35 |
Dyrcona |
Could they login before you changed the permissions? |
| 11:35 |
pdot |
(yes, if the latter was directetd at me) |
| 11:37 |
Dyrcona |
It was. |
| 11:37 |
pdot |
after changing permissions like that, do I need to run autogen.sh? |
| 11:37 |
csharp |
pdot: I understand your question is a technical one and you're probably not looking for advice, but I would strongly recommend against giving volunteers more than just the perms they would need to do their jobs |
| 11:38 |
phasefx |
pdot: this is a tangent, but worth mentioning, I don't think the EVERYTHING permission actually grants all permissions like it used to. That shouldn't be the case here, but just fyi |
| 11:39 |
Dyrcona |
pdot: I suggest you check the osrfsys.log for failures related to auth for these accounts. |
| 11:39 |
phasefx |
pdot: you don't need to run autogen for changing permissions |
| 11:40 |
Dyrcona |
I can't think of why adding a permission would break login. |
| 11:40 |
phasefx |
pdot: oh, and I misread EVERYONE as EVERYTHING, so ignore me :) |
| 11:41 |
phasefx |
and I do see "everything" mentioned later, so ignore me again |
| 11:41 |
Dyrcona |
phasefx: I'm not aware of an EVERYONE keyword for permissions. |
| 11:42 |
* phasefx |
could imagine EVERYTHIGN with a restricted depth trumping a better permission with a better depth and somehow breaking things |
| 11:42 |
pdot |
just grepped the osrfsys.log for fail, oddly, nothing for the users exhibiting issues |
| 11:42 |
jeff |
pdot: For the users in question, does their user "Home Library" (actor.usr.home_ou) match the branch where they have been assigned the EVERYTHING permission? |
| 11:43 |
csharp |
of course, if EG were developed today, it would probably be "ALL_THE_THINGS" |
| 11:43 |
Dyrcona |
phasefx: That is possible. I'd have to really look at the perm check code to be sure. |
| 11:43 |
Dyrcona |
csharp: Heh. |
| 11:44 |
Dyrcona |
phasefx: If that is the case, I'd consider it a bug. |
| 11:46 |
phasefx |
Dyrcona: I feel like overlapping permissions are already buggy; meant to dig into and map out the actual behavior. I don't think it was ever well defined |
| 11:47 |
Dyrcona |
phasefx: It has been a while since I last looked at the permissions code. I vaguely recall there being some weird thing with EVERYTHING that was fixed a couple of years ago. |
| 11:47 |
Dyrcona |
It was in one of the database functions, IIRC. |
| 11:47 |
yboston |
jeff: thanks for your earlier reply about SAML |
| 11:47 |
phasefx |
Dyrcona: I think pcrud perms don't get included/considered |
| 11:48 |
Dyrcona |
OATRTA, the only acronym/backronym you need. ;) |
| 11:48 |
Dyrcona |
phasefx: Yeah, I've not looked into pcrud that much. |
| 11:48 |
pdot |
trying Jeff's solution might be an issue |
| 11:48 |
mmorgan |
Possibly related permision bug lp 1480432 |
| 11:48 |
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 - Assigned to Michele Morgan (mmorgan) |
| 11:48 |
|
brahmina joined #evergreen |
| 11:48 |
kmlussier |
mmorgan: I was just looking for that one. |
| 11:49 |
jeff |
pdot: my question/suggestion probably isn't directly relevant, but if you're going to try it anyway i'd be interested in hearing the results :-) |
| 11:50 |
jeff |
yboston: you're welcome! |
| 11:50 |
gsams |
csharp++ #I can imagine a conversation with an admin and making sure ALL_THE_THINGS is set properly. |
| 11:51 |
gsams |
I may start refering to it that way anyway. Of course, I'm the only one with ALL_THE_THINGS at the moment. |
| 11:51 |
|
wjr joined #evergreen |
| 11:52 |
|
tspindler left #evergreen |
| 11:54 |
pdot |
gsams (haha for those of us in small environments, the individual permissions list does seem a little insane ;) ) |
| 11:55 |
mmorgan |
pdot: It's not so much fun for those of us in larger environments either ;-) |
| 11:56 |
gsams |
I'm actually about to be embarking on a task to audit our permissions structure. It is a little off balance and needs some fine tuning. I also want to take better advantage of secondary groups. |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:57 |
|
bmills joined #evergreen |
| 13:03 |
kmlussier |
@dessert |
| 13:03 |
* pinesol_green |
grabs some Coconut Cream Cake for kmlussier |
| 13:11 |
|
jihpringle joined #evergreen |
| 13:36 |
csharp |
gsams: a few days late for April Fools, but in the same spirit: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=e977046fc4fe23a97e2dd7b4ccd9a9798e9536ce |
| 13:40 |
kmlussier |
csharp++ |
| 13:42 |
jeff |
i suppose a followup bugfix commit would be taking it too far. |
| 13:43 |
* csharp |
stopped just short of the "somebody's going to think I'm serious about this" line |
| 13:44 |
Dyrcona |
:) |
| 13:44 |
jeff |
we have thing explainer! |
| 13:45 |
* tsbere |
is half tempted to grab that and make the "ALL_THE_THINGS" -2, then put special logic in that makes "ALL_THE_THINGS" apply at a depth one less than it was granted, just for lulz ;) |
| 13:45 |
jeff |
(of course we do. why wouldn't we?) |
| 13:45 |
csharp |
tsbere++ |
| 13:48 |
tsbere |
and going from there: "REALLY_ALL_THE_THINGS_I_MEAN_IT_THIS_TIME" as -3 making it act like the superuser flag. ;) |
| 13:50 |
* Dyrcona |
just grants everyone EVERYTHING at depth 0..... |
| 13:50 |
* Dyrcona |
sits back and watches the world burn. ;) |
| 13:55 |
pdot |
Dyrcona, with hourly db / host backups, who cares? ;) |
| 14:03 |
pdot |
some days, I'm seriously tempted to put egadmin on a post-it, and walk away slowly from the explosion. |
| 14:04 |
pinesol_green |
[evergreen|Jason Boyer] LP1564378: Silence Hash Init Warning - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ae927ad> |
| 14:09 |
JBoyer |
So would it be too meta to open a debug window and set a Watch on a global variable named World for when it's changed to "Burn"? |
| 14:09 |
JBoyer |
Asking for a friend. |
| 14:09 |
csharp |
JBoyer++ |
| 14:09 |
Dyrcona |
heh |
| 14:23 |
pdot |
and clearing the 'everything' permission restores the ability to log in! |
| 14:25 |
pdot |
so, my question revised: "how does one create an operator group with enough permissions to run a branch as a one-person job?" |
| 14:27 |
pdot |
so, registering patrons, sign-in and out of books, shelving returned books, creating marc records, adding and removing inventory :D |
| 14:28 |
Dyrcona |
You give them all of the permissions that they need at the branch level. |
| 14:28 |
* Dyrcona |
wouldn't be too surprised if the permissions bug is his fault, btw. |
| 14:29 |
kmlussier |
Some permissions need to be set at a depth of 0 to work correctly. |
| 14:29 |
csharp |
pdot: Admin -> Server Administration -> Permission Groups - it's going to take some trial and error |
| 14:29 |
kmlussier |
For example creating march records needs to be set at 0 depth. Same is true for managing parts |
| 14:30 |
Dyrcona |
kmlussier: It's April already, but you wouldn't know by looking out the window. :) |
| 14:31 |
kmlussier |
LOL - glad to see my typos are starting so early in the week. |
| 14:31 |
Dyrcona |
:) |
| 14:33 |
* mmorgan |
thinks STAFF_LOGIN might be one of those permissions that needs to be at the consortium level, too. |
| 14:33 |
tsbere |
pdot: Take the user(s) and use secondary groups to grant them all the various permission groups they need? |
| 14:33 |
pdot |
so I might be looking in an outdated place, but is there an equivlent of http://docs.evergreen-ils.org/2.1/html/permissions_appendix.html that has permission depthe depth requirements listed somewhere? if not I'll take one for the team and create it. |
| 14:33 |
kmlussier |
pdot / mmorgan: Well, then, that might explain why logging in isn't working with the Everything permission set at the branch level. |
| 14:34 |
* tsbere |
suspects it is "workstation creation needs to be global" more than "staff login", but hasn't checked if the former uses the latter |
| 14:34 |
mmorgan |
yes, what kmlussier said :) |
| 14:34 |
pdot |
kmlussier: yup |
| 14:41 |
|
kmlussier left #evergreen |
| 15:08 |
pdot |
Can anyone speak to this as being a good baseline for single-staff permissions? http://en.flossmanuals.net/evergreen-in-action/appendix-a-suggested-profile-permissions/ |
| 15:14 |
Dyrcona |
pdot: Do you have multiple branches or is this Evergreen for a single site? |
| 15:15 |
pdot |
I have one branch currently, there are plans for another however |
| 15:17 |
pdot |
(beyond hirearchy, calling these branches would be a stretch, ~2000 bibliographic records between them) |
| 15:17 |
Dyrcona |
Ok. I just thought if you really had only 1 location, then logging in as the admin would be a quick solution. :) |
| 15:19 |
Bmagic |
That list is a good starting point for sure |
| 15:21 |
Bmagic |
pdot: at every level, we use an "admin" account with "EVERYTHING" permissions at the system/consortium level. We created a permission group for each of those aka "System Administrator" "Global Administrator" |
| 15:26 |
pdot |
Bmagic, Interesting. I'll give that a go first to see if it meets our needs |
| 15:31 |
|
jlitrell joined #evergreen |
| 15:42 |
Dyrcona |
JBoyer: A propos Novelist On the Shelf, this may interest you: http://pastebin.com/KEzDDyS1 |
| 15:42 |
Dyrcona |
That's what I came up with based on rjackson_isl's script. |
| 15:42 |
Dyrcona |
Note that it uses a function that has not been committed to master, yet. |
| 15:43 |
|
kmlussier joined #evergreen |
| 15:48 |
JBoyer |
Dyrcona, that does look handy. |
| 15:49 |
Dyrcona |
It solves a bunch of my problems by using asset.opac_visible_copies, too. ;) |
| 15:49 |
JBoyer |
We'll probably look at using it once we either upgrade or just throw that func in the db. |
| 15:51 |
Dyrcona |
Cool. It's LP 1564402 if you want to sign off. :) |
| 15:51 |
pinesol_green |
Launchpad bug 1564402 in Evergreen "A Database Function to Return ISBN13" [Wishlist,New] https://launchpad.net/bugs/1564402 |
| 15:53 |
|
graced joined #evergreen |
| 15:54 |
|
maryj joined #evergreen |
| 15:56 |
Dyrcona |
It took about 13 minutes to dump 3,141,888 copies from my development DB, btw. |
| 16:01 |
dbs |
@later tell tspindler Yep, we're using LDAP authentication, and when Windsor was with us they were using CAS ticket auth (which would be way better than LDAP but our uni doesn't have such a solution so...) |
| 16:01 |
pinesol_green |
dbs: The operation succeeded. |
| 16:04 |
dbs |
You can trace down some of artunit's CAS mechanism in http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=shortlog;h=refs/heads/user/artunit/rel_2_3_owa_cas_conifer_dynamic_links_support |
| 16:27 |
pdot |
dbs: cool! I didn't know CAS was a supported auth mechanism |
| 16:28 |
jeff |
I think I knew then forgot. |
| 16:28 |
jeff |
Hrm. |
| 16:50 |
dbs |
pdot: it's not officially supported, as I don't think it was ever made generic enough to contribute to core Evergreen |
| 16:50 |
dbs |
but the bones are there |
| 16:55 |
dbs |
Hah, that thing where you explain parts and people go "Oh cool!" and then go ahead and create separate call numbers for each part |
| 16:56 |
dbs |
transfer_items_to_previously_marked_volume++ |
| 17:01 |
pinesol_green |
Showing latest 5 of 10 commits to Evergreen... |
| 17:01 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564685 Repair patron editor checkboxes sizing - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9bb3dc3> |
| 17:01 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564685 New Address button is always accessible - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=93cb40c> |
| 17:01 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564685 Prevent edit of linked addresses - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fa13169> |
| 17:01 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564685 Avoid referencing out-of-scope stat cats - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0aab213> |
| 17:01 |
pinesol_green |
[evergreen|Bill Erickson] LP#1564685 Prevent linked address edit on reload - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8605e7d> |
| 17:07 |
|
mmorgan left #evergreen |
| 17:08 |
jeff |
berick++ kmlussier++ gmcharlt++ |
| 17:18 |
Bmagic |
has anyone already developed some perl code that checks various things on an app server. Like, test circ, test patron edit, test renew etc? I'm looking at OpenILS::Utils::Cronscript. |
| 17:20 |
berick |
Bmagic: you might want to look at the stuff in Open-ILS/src/perlmods/live_t/ |
| 17:33 |
Bmagic |
berick: ty |
| 21:33 |
|
geoffsams joined #evergreen |
| 22:56 |
|
bmills joined #evergreen |
