| Time |
Nick |
Message |
| 01:56 |
|
tsbere joined #evergreen |
| 07:10 |
|
sbrylander joined #evergreen |
| 07:27 |
|
graced joined #evergreen |
| 07:49 |
|
rjackson_isl joined #evergreen |
| 07:58 |
|
jboyer-isl joined #evergreen |
| 07:59 |
|
mrpeters joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:33 |
|
akilsdonk joined #evergreen |
| 08:36 |
|
collum joined #evergreen |
| 08:37 |
|
RoganH joined #evergreen |
| 08:41 |
|
Newziky joined #evergreen |
| 08:46 |
|
Shae joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 09:08 |
jeff |
csharp: looking at the bug, i'm going to need to refresh my memory and review the conversation :-) |
| 09:14 |
|
maryj joined #evergreen |
| 09:15 |
Dyrcona |
I missed the conversation. |
| 09:15 |
jeff |
bug 1446860 |
| 09:15 |
pinesol_green |
Launchpad bug 1446860 in Evergreen "staff users can edit their own accounts" (affected: 1, heat: 6) [High,New] https://launchpad.net/bugs/1446860 - Assigned to Chris Sharp (chrissharp123) |
| 09:15 |
Dyrcona |
But, the bug description sounds OK to me, if it only affects the staff client. |
| 09:16 |
csharp |
it only affects the staff client, yet |
| 09:16 |
csharp |
s/yet/yes/g |
| 09:18 |
jeff |
If the concern is that staff are able to edit their own accounts, then I'd point out that the branch in that bug does nothing to prevent the behavior as-currently-designed that permits that at the API level. |
| 09:18 |
jeff |
So if it's concensus that Evergreen should prevent that (and I suppose the reasons why should be stated), then a more complete set of changes would be in order. |
| 09:19 |
jeff |
I think that the previous discussion on this issue trailed off and wasn't resumed that I can remember. |
| 09:20 |
tsbere |
I think there are issues with being able to edit anything about yourself, but editing some of your stuff as a staff member seems fine most of the time. <_< |
| 09:21 |
tsbere |
Though I wouldn't mind a way to say "these accounts can't edit themselves" :/ |
| 09:21 |
jeff |
Other than permissions-related things -- which should already be prevented at the API level -- what concerns are there with staff users being able to edit themselves? Short of "prevent these accounts from self-edit (or even from self-password-change)", which might be a nice addition. |
| 09:21 |
tsbere |
Maybe a new flag or permission on groups for "self edit" compared to "anyone edit" |
| 09:22 |
jeff |
Though on that last part, I'm hesitant, because I think it might encourage use of generic role accounts, which I'm not a huge fan of. :-) |
| 09:22 |
tsbere |
jeff: My main concern is that our members insisted on generic accounts, we don't want them changing a lot of stuff on those |
| 09:22 |
tsbere |
As we already *have* generic accounts.... |
| 09:23 |
tsbere |
I could also see "staff-ish member that isn't allowed full staff rights". Volunteers may only be permitted to do certain staff actions, for example... |
| 09:25 |
jeff |
In your volunteer example, can you be more specific about what the concern is with the volunteer user self-editing? |
| 09:27 |
|
akilsdonk joined #evergreen |
| 09:27 |
tsbere |
Honestly, my main concern would likely be stat cats. |
| 09:27 |
tsbere |
<_< |
| 09:28 |
tsbere |
Beyond that they may not be trusted to replace barcodes, edit their username, etc |
| 09:28 |
jeff |
So, they'd be permitted to edit those items on other patron accounts but not their own? |
| 09:29 |
csharp |
jeff: in the original EG design for PINES, it was designated that staff would need another staff member of higher permission levels to edit their accounts (for accountability reasons) |
| 09:30 |
csharp |
so for us it's kind of a dogmatic assumption that staff can't edit themselves ("us" being the PINES library staff) |
| 09:31 |
|
yboston joined #evergreen |
| 09:31 |
Dyrcona |
jeff: I think the volunteer account thing is a bit convoluted, we don't actually have volunteer accounts. They would just use the generic circ accounts at our libraries. |
| 09:32 |
jeff |
csharp: Can you detail any specific concerns with staff editing their own user account? |
| 09:32 |
csharp |
in the issue that sent me off looking for the fix that never got finished, a staff member had edited her agency affiliation to make changes on another system's patron account, and according to our policies and expectations, she should not have been allowed by the software to do what she did |
| 09:32 |
Dyrcona |
But, yeah, I can see there being accounts that we don't want to self-edit and others we don't mind if they do. |
| 09:33 |
jeff |
csharp: Ah, so she edited her home_ou? |
| 09:33 |
csharp |
jeff: yep |
| 09:33 |
jeff |
Okay, so if that were addressed -- any other concerns? |
| 09:33 |
csharp |
if another staff member had to have been involved, I don't think the issue (which has caused some serious tension in an already fraught relationship between the two systems) would have even happened |
| 09:34 |
Dyrcona |
well, in some sense that makes it worse, 'cause it would require a conspiracy of two. |
| 09:35 |
csharp |
Dyrcona: well it would definitely change the tone of the conversation from "oops!" to "we definitely meant to do this" |
| 09:35 |
tsbere |
csharp: The more I look at the "fix" the more I disagree with it. <_< |
| 09:35 |
jeff |
csharp: the issue which you are beginning to veer off into may not be a technical issue and may not have a technical solution. :-) |
| 09:35 |
Dyrcona |
Well, technically, you can stop staff from editing their own accounts. |
| 09:35 |
csharp |
jeff: I agree with that |
| 09:36 |
Dyrcona |
So there is in some sense a technical solution. |
| 09:36 |
Dyrcona |
You can also stop other staff from editing staff accounts. |
| 09:36 |
csharp |
it's definitely "software enforcing where management doesn't want to" |
| 09:36 |
Dyrcona |
We've given special profiles to staff with elevated permissions so that the generic accounts cannot edit them. |
| 09:37 |
csharp |
tsbere: at the risk of sounding pedantic, I think the "fix" is actually just correcting the original intent of the code |
| 09:38 |
csharp |
so the real argument is probably with the original solution's intent |
| 09:38 |
tsbere |
csharp: I disagree. But I am going to comment via Launchpad instead. |
| 09:38 |
csharp |
ok |
| 09:39 |
Dyrcona |
Well, people will do whatever the software allows, and the best way to enforce policy is through the software. |
| 09:40 |
eeevil |
fwiw, the original intent was, indeed, to disallow self-edits, except via the restricted email/phone/username API calls. pcrud opens an API hole ... I haven't looked at the code to see if pcrud is used to edit au's anywhere, but if not (yet) we could remove pcrud as a controller and tighten the API inside open-ils.actor |
| 09:41 |
tsbere |
csharp: https://bugs.launchpad.net/evergreen/+bug/1446860/comments/2 |
| 09:41 |
pinesol_green |
Launchpad bug 1446860 in Evergreen "staff users can edit their own accounts" (affected: 1, heat: 6) [High,New] - Assigned to Chris Sharp (chrissharp123) |
| 09:41 |
eeevil |
and the original intent was actually not driven by policy, but security. require a conspiracy and you reduce the incidents |
| 09:41 |
Dyrcona |
FWIW, I'm not concerned about the API (as jeff is). If you're using the API, then you can probably do a lot of things that the client or other methods would not allow. |
| 09:42 |
Dyrcona |
And that probably should be "definitely." |
| 09:42 |
eeevil |
well, even if we adjust the API, we should also adjust the client (change && to ||) so we can disable the buttons |
| 09:44 |
jeff |
Almost by definition, the API allows many things that the UI does not. Most reasonable APIs do. I think the impotatnt distinction is that in cases where the API allows bypass of either security or policy, these are (IMO) bugs. |
| 09:45 |
eeevil |
I don't see, personally, where the burden is in having to have another staff member adjust your staff account. I can't see how it's not very rare. and seemingly-safe changes can have "bad" consequences; see: csharp's example |
| 09:45 |
jeff |
And yes, it should be a goal to have the UI not offer users the option to do things that we "know" will fail -- agreeing with eeevil on the "UI should be adjusted", but in a more general sense also. :-) |
| 09:46 |
Dyrcona |
eeevil: I'm not sure anyone is arguing that it is a burden. |
| 09:46 |
eeevil |
Dyrcona: I thought jeff was, but I may be misunderstanding his position |
| 09:46 |
Dyrcona |
My comment about the conspiracy was more of a moral quip, i.e. two people now have to compromise themselves. |
| 09:47 |
eeevil |
or rather, I thought jeff was saying his staff expect to be able to self-edit |
| 09:47 |
jeff |
if memory serves, early patron editor let you self-edit, then it didn't, then it did again -- in our eyes, it was a bug that was fixed. I haven't made time to troll through history to see if my memory is correct or if there was a comment/bug confirming tha fix. I suspect it was just part of the overhaul. |
| 09:47 |
Dyrcona |
Well, if pcrud is removed from the actor.usr object, NCIPServer will need to be rewritten. |
| 09:47 |
Dyrcona |
It uses pcrud quite extensively. |
| 09:47 |
eeevil |
for update? |
| 09:47 |
Dyrcona |
And that will, should be changed to "may" |
| 09:48 |
jeff |
But re-stating something from the original conversation, it's a more common use case when staff are using one account for "patron-y" and "staff-y" things, and I like to discourage that locally. |
| 09:48 |
eeevil |
jeff: gotcha, sorry for misrepresenting you |
| 09:48 |
jeff |
No, it's easy to do. :-) |
| 09:49 |
Dyrcona |
jeff: We originally wanted staff to use one account for both their staff and patron logins, but some of them went ape at that suggestion. |
| 09:49 |
Dyrcona |
They couldn't wrap their heads around it, and one even wrongly claimed it was illegal. |
| 09:49 |
csharp |
the main disadvantage to keeping staff from self-edits has been when someone needs to adjust the expiration date on their account and there's no one around with higher perms to do it - that causes endless staff frustration |
| 09:49 |
jeff |
Any new staff have been getting a "only for staff things" user in Evergreen and a "here's your patron user" in Evergreen. |
| 09:49 |
Dyrcona |
We have always had generic staff accounts and they insisted we do that with Evergreen, too. |
| 09:50 |
Dyrcona |
csharp: That reminds me: I "expire" in August this year. ;) |
| 09:50 |
eeevil |
csharp: sounds like a job for cron :) |
| 09:50 |
tsbere |
"Staff move around the desks frequently and don't have time to be logging in over and over" is one of the common arguments, at least for circ. |
| 09:51 |
Dyrcona |
Anyway, we're getting off topic. |
| 09:51 |
* tsbere |
thinks that cataloging accounts could easily be switched away from generic accounts at MVLC, but this isn't the place to discuss that ;) |
| 09:51 |
Dyrcona |
I really have no issue with the proposed changes. |
| 09:51 |
Dyrcona |
Except I would be very careful about changing the API. |
| 09:52 |
Dyrcona |
You'll likely break stuff other people are doing. :P |
| 09:52 |
Dyrcona |
tsbere: I think it is too late for changing the cataloging accounts. |
| 09:52 |
csharp |
tsbere: eeevil: you're both correct - I'll adjust my branch from '&&' to '||' |
| 09:53 |
dbwells |
When we migrated, I think I set all of our "perpetual" alumni accounts to expire in 2020, which was really meant as some unimaginably far date into the future. I'm sure I'll remember to deal with that before it blows up in my face ;) Tick, tick, tick, tick, tick... |
| 09:53 |
Dyrcona |
We have some migrated patron accounts that don't expire until 2033 or something, 'cause our libraries were doing all kinds of crazy stuff with expiration. |
| 09:54 |
Dyrcona |
During migration we got them to agree on the same time for patron accounts. |
| 09:54 |
Dyrcona |
I think we gave generic accounts something like a 50 year expiration. |
| 09:54 |
tsbere |
We have some accoutns right now that expire in 5015. <_< |
| 09:54 |
tsbere |
er, accounts |
| 09:55 |
Dyrcona |
Typoes, obviously. :) |
| 09:55 |
tsbere |
Not to mention 30xx, 29xx... |
| 09:55 |
|
Callender joined #evergreen |
| 09:56 |
jeff |
misread, thought you had patrons expiring in 29 pixels |
| 09:59 |
* csharp |
saw that the staff member involved in the issue referenced above has a birth year of 1000 |
| 09:59 |
csharp |
however, THERE CAN BE ONLY ONE |
| 10:00 |
graced |
heh |
| 10:09 |
jonadab |
Birthdates is another thing some people might use as a reason to disallow self-edit. |
| 10:10 |
jonadab |
Currently, we don't have a problem, but in the past we have had staff who deliberately sabotaged their own birthdate data in the ILS, to conceal their age. |
| 10:11 |
csharp |
our libraries use the dummy date of 1901-01-01 for that |
| 10:19 |
RoganH |
csharp: I use 1911-01-01 |
| 10:23 |
* jonadab |
has cleverly concealed his birthdate by saving it in his patron record under the "birthdate" field. No one will think to look for it there! |
| 10:43 |
|
krvmga joined #evergreen |
| 10:52 |
jeff |
Now you're veering off into "this staff user shouldn't be able to edit this patron user because the two user objects represent the same person" territory. :P |
| 10:56 |
* phasefx |
registers some fake patrons for evil purposes :) |
| 10:59 |
phasefx |
can't stop everything |
| 11:12 |
dbs |
jeff: time to migrate actor.usr to linked data |
| 11:22 |
|
vlewis joined #evergreen |
| 11:37 |
|
bmills joined #evergreen |
| 11:39 |
|
akilsdonk joined #evergreen |
| 11:55 |
|
jwoodard joined #evergreen |
| 12:00 |
|
Dyrcona1 joined #evergreen |
| 12:14 |
Dyrcona |
Too much wifi saturation in the office. Hopefully it will be better in the new offices. |
| 12:20 |
|
bmills joined #evergreen |
| 12:31 |
dbs |
Looking at http://docs.evergreen-ils.org/2.8/_managing_holds.html trying to find evidence for my brain which is telling me the "Last notify time" on the holds screen only gets populated when explicitly set through "Edit phone notification", and not when an email is automatically sent. |
| 12:33 |
* dbs |
looks at action.hold_notification instead |
| 12:33 |
tsbere |
dbs: I thought "Last notify time" was pulled from action.hold_notification and would be updated when the post-email "create a notification entry" cleanup ran in A/T |
| 12:33 |
tsbere |
assuming your A/T is using said cleanup, anyway... |
| 12:36 |
* dbs |
wonders if his A/T is using said cleanup. |
| 12:41 |
* dbs |
checks action_trigger log, sees "reacted":0 for the notification event in question |
| 12:43 |
tsbere |
dbs: Specifically, "Success Cleanup" of "CreateHoldNotification" - We have it on our email and sms notification event defs |
| 12:49 |
dbs |
okay, right, action_trigger.event_definition.cleanup_success is set to 'CreateHoldNotification'; presumably that's what I need |
| 12:50 |
dbs |
and cleanup_failure is NULL |
| 12:50 |
* dbs |
goes to check email logs to see if it's just been failing |
| 12:53 |
|
jihpringle joined #evergreen |
| 13:16 |
tsbere |
dbs: Just for the sake of sanity: Did you make sure that the hold(s) in question have email notification turned on? |
| 13:16 |
tsbere |
(or SMS as the case may be, I suppose) |
| 13:21 |
|
buzzy joined #evergreen |
| 13:25 |
buzzy |
critically-important conference-related question: what did you guys use for the twitter/instagram/whatever hashtag? |
| 13:28 |
csharp |
buzzy: last year's was #egils14 |
| 13:29 |
csharp |
(twitter only afaik) |
| 13:29 |
gmcharlt |
berick: I want to call your attention to user/gmcharlt/lp741788_wip -- it overlaps with some of the cleanup you've got going in bug 1384740 |
| 13:29 |
pinesol_green |
Launchpad bug 1384740 in Evergreen "Add authority records support to marc stream importer (Connexion)" (affected: 2, heat: 12) [Wishlist,New] https://launchpad.net/bugs/1384740 |
| 13:38 |
buzzy |
thanks, csharp! |
| 13:39 |
gmcharlt |
buzzy: given trends in hashtag usage, if you haven't suggested one yet for this conference, I recommend #evgils15 |
| 13:41 |
berick |
gmcharlt: thanks for the heads up. /me mentally prepares for some merging |
| 13:42 |
buzzy |
gmcharlt: rather than #egils15? |
| 13:42 |
gmcharlt |
buzzy: correct |
| 14:20 |
|
mglass joined #evergreen |
| 14:29 |
|
dMiller_ joined #evergreen |
| 14:52 |
dbs |
tsbere: yeah, I think I found the problem. An updated template introduced a linefeed at the start of the email. |
| 15:14 |
* dbs |
carefully tweaks a few [%- blah blah -%] parts of the template |
| 15:14 |
dbs |
Hoping not to end up with To: dbs example.orgFrom: libraryexample.org |
| 15:35 |
|
Callender_ joined #evergreen |
| 15:52 |
|
bmills joined #evergreen |
| 16:06 |
|
ningalls joined #evergreen |
| 16:49 |
|
neopsyche joined #evergreen |
| 16:49 |
neopsyche |
Evergreen:? |
| 16:52 |
neopsyche |
library sys/ |
| 16:53 |
neopsyche |
Is ayone able to assist with developing education network for delivery of ebooks? |
| 17:11 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
|
mmorgan left #evergreen |
| 18:04 |
|
mglass_ joined #evergreen |
| 18:11 |
|
mglass joined #evergreen |
| 19:12 |
|
jihpringle joined #evergreen |
| 20:47 |
jeff |
neopsyche: what you describe isn't quite something that Evergreen handles. depending on your need, you might have more luck in #code4lib -- other than that, I don't have many suggestions for you. |
| 20:52 |
jonadab |
In a perfect world, a library's ILS would handle that sort of thing. But currently I don't think that is legally possible, unless all your ebooks are public domain. |
| 20:53 |
jonadab |
I'd like to be wrong about this... |
| 21:04 |
jeff |
sometimes you need to stop cramming EVERYTHING into your ILS and just start integrating things with your ILS. :-) |
| 21:11 |
|
akilsdonk joined #evergreen |
| 21:13 |
|
bmills joined #evergreen |
| 21:14 |
jonadab |
jeff: Ok, fair. |
| 21:15 |
jonadab |
Although, we think of ebook checkouts as circulations -- heck we report them to the state as circulations. |
| 21:16 |
jonadab |
Patrons use a library card to check them out, and they're not available to the next patron until they're returned or the loan period expires, etc. |
| 21:17 |
jonadab |
If you don't know anything about the underlying technology, it _feels_ like it ought to be something the ILS would do, from a layperson's perspective. |
| 21:20 |
jonadab |
But as I said, I don't think it's currently legally possible anyway. The publishers would never put up with _libraries_ having that much control over the ebooks. |
| 22:46 |
|
akilsdonk joined #evergreen |
