| Time |
Nick |
Message |
| 02:20 |
|
tsadok joined #evergreen |
| 07:11 |
|
kworstell-isl joined #evergreen |
| 07:51 |
|
kworstell-isl joined #evergreen |
| 08:02 |
|
BDorsey joined #evergreen |
| 08:21 |
|
sleary joined #evergreen |
| 08:31 |
|
rfrasur joined #evergreen |
| 08:32 |
csharp_ |
@quote add < bgillap_> Hey, I want to look at beautiful opacs. |
| 08:32 |
pinesol |
csharp_: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
| 08:32 |
csharp_ |
grr |
| 08:32 |
csharp_ |
@quote add < bgillap_> Hey, I want to look at beautiful opacs. |
| 08:32 |
pinesol |
csharp_: The operation succeeded. Quote #238 added. |
| 08:38 |
|
rfrasur joined #evergreen |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:43 |
|
collum joined #evergreen |
| 08:46 |
Dyrcona |
I disagree with Lp 2024657 being a bug. I want to convert it to a question. |
| 08:46 |
pinesol |
Launchpad bug 2024657 in Evergreen "Wishlist: ungroup permissions in the Everything staff permission" [Wishlist,Confirmed] https://launchpad.net/bugs/2024657 |
| 08:51 |
Dyrcona |
And, I did. |
| 09:28 |
csharp_ |
Dyrcona++ #agreed |
| 09:28 |
csharp_ |
@who knows the answer to life, the universe and EVERYTHING? |
| 09:28 |
pinesol |
berick knows the answer to life, the universe and EVERYTHING. |
| 09:29 |
csharp_ |
pinesol: for sure |
| 09:29 |
pinesol |
csharp_: Try running autogen |
| 09:33 |
|
Christineb joined #evergreen |
| 09:35 |
Dyrcona |
csharp_++ |
| 09:35 |
Dyrcona |
pinesol++ |
| 09:35 |
|
mantis joined #evergreen |
| 09:35 |
* Dyrcona |
spent so long editing a draft email, that I decided to print it out to proofread it before hitting "Send." |
| 09:36 |
csharp_ |
haha |
| 09:51 |
Dyrcona |
I think it will be a better message because of that editing, too. |
| 10:02 |
|
sleary joined #evergreen |
| 10:06 |
csharp_ |
do we even need the EVERYTHING perm? Seems like the superuser flag on actor.usr should cover that use case and remove all confusion |
| 10:07 |
Dyrcona |
I want to remove the superuser flag. |
| 10:08 |
Dyrcona |
In my opinion, the EVERYTHING permission is safer and easier to remove from an account. |
| 10:09 |
Dyrcona |
Permission checks also have to check for superuser, and I thought there was Lp bug to remove/deprecate superuser, but I'm not finding it. |
| 10:10 |
csharp_ |
I guess because we have never used the EVERYTHING perm except for troubleshooting I don't understand the use cases for it in the Real World™ |
| 10:10 |
csharp_ |
as in, the only user that "needs" all perms is the admin user |
| 10:10 |
Dyrcona |
Same use case as superuser, but better if you also get rid of superuser. |
| 10:11 |
csharp_ |
which we treat like a UNIX-ish root account |
| 10:11 |
berick |
same as csharp_ here. i've never EVERYTHING. |
| 10:11 |
berick |
*never used |
| 10:12 |
Dyrcona |
Right, and I disagree with treating it as "root" account. I also think the default admin account should be eliminated. |
| 10:12 |
berick |
and superuser = true / false is delightfully simple |
| 10:13 |
Dyrcona |
And what happens when you leave the organization and you're still using that account as a patron? Will they remember to remove the superuser flag, and who can do it since it pretty much has to be done in the database? |
| 10:13 |
csharp_ |
we just never assign it to end users |
| 10:13 |
Dyrcona |
csharp_: What if your admin is also an end user, as I was at MVLC? |
| 10:14 |
csharp_ |
I would probably rethink the model in that case |
| 10:14 |
Dyrcona |
EVERYTHING is far safer in my opinion. |
| 10:14 |
berick |
whoa, admin was your personal library account? |
| 10:14 |
Dyrcona |
No, my personal library was also an admin. |
| 10:14 |
Dyrcona |
account^^ |
| 10:14 |
berick |
ah |
| 10:15 |
csharp_ |
we have a GlobalAdmin perm class that is not EVERYTHING/super-user but has the perms needed for system administration |
| 10:15 |
Dyrcona |
csharp_: I am rethinking the model. |
| 10:16 |
Dyrcona |
csharp_: That is fine. Like I said on Lp, you don't have to use the permission. (I still think superuser should go.) |
| 10:17 |
csharp_ |
Dyrcona: so in your case, no generic/default "admin" user, just individuals assigned EVERYTHING that would need to be removed after leaving employment? |
| 10:17 |
Dyrcona |
csharp_: Basically, yes, but we usually do more than just remove permissions. In most cases our work account is separate from the patron account, but at MVLC, I had one account that did both. |
| 10:18 |
csharp_ |
(in any case, sounds like Diane's situation is squirrely :-/) |
| 10:18 |
Dyrcona |
What it sounds like is there are permissions checks that are not using the back end permissions check functions. |
| 10:18 |
csharp_ |
Dyrcona: yeah, we have individual accounts that are meant to accommodate both staff and patron functions |
| 10:19 |
Dyrcona |
In the case of 1 account serving two functions, the main profile is the patron profile, then you add them to the admin/working group as a second group/profile. When they no longer work there, remove the second profile. |
| 10:20 |
Dyrcona |
That's much safer than setting a flag in actor.usr. |
| 10:21 |
Dyrcona |
My second promised email about our rusty future might go into some detail about issues I have with the current staff client, but I might save that for yet another email. |
| 10:21 |
Dyrcona |
I have examples of bad API design and even worse use or bypassing of existing API. |
| 10:22 |
berick |
we have exactly 2 accounts w/ superuser. one for logging in/testing/etc and one a backend utility account. not following the use case where a standard human person would get superuser. |
| 10:24 |
jeff |
seconding deprecation and possibly eventual removal of actor.usr.superuser, if only for simplicity and for the sake of having permissions in fewer places. |
| 10:24 |
Dyrcona |
berick: Doesn't matter if you don't get it. Doesn't mean it's wrong. When someone is on the phone wanting something fixed, that permission comes in handy. |
| 10:25 |
jeff |
and yes, both EVERYTHING and superuser should be rarely handed out / relied upon. |
| 10:25 |
Dyrcona |
jeff++ both times |
| 10:26 |
jeff |
also, last time I looked I think they differ slightly, so that is probably worth looking into again as part of that. |
| 10:26 |
Dyrcona |
If they differ right now, that's a bug in my opinion. They should be the same. |
| 10:27 |
Dyrcona |
Functionally the same that is. |
| 10:27 |
berick |
from the security perspective, the argument boils down to the fact that EVERYTHING can be managed via the UI? |
| 10:27 |
jeff |
the UI-side permission checks for disabling menu options or checkboxes (like the circ.collections.exempt checkbox in the user editor) might also benefit from a more convenient way to check perms than always saying "does this user have this perm or do they (have EVERYTHING/superuser status) -- even after deprecating superuser. |
| 10:28 |
jeff |
that's not the argument I was making, so I don't know. |
| 10:28 |
Dyrcona |
berick: 1 reason. It boils down to something that is added to an account and more easily removed. |
| 10:29 |
jeff |
I had it in my head (from a comment, or a bug, or whatnot) that EVERYTHING was the new way to go, so that's the direction I've had in my head. One of the reasons to deprecate actor.usr.superuser in my mind is that it simplifies some things by having permissions exist in one less place -- possibly "exist in one place", but I might be missing something so I wasn't making that assertion yet. :-) |
| 10:29 |
csharp_ |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;h=43f3584d73672c3a6400ab694e658b883238d3f9;hb=HEAD#l1296 is the perl check for superuser/EVERYTHING |
| 10:30 |
csharp_ |
I'm confused by the "if" for superuser and the "unless" for EVERYTHING - looks like they aren't the same |
| 10:30 |
jeff |
also, I don't have a branch prepared, so I haven't cut my fingers on the sharp edges yet. there might be complications I've not seen or have forgotten since I last looked. |
| 10:30 |
Dyrcona |
jeff: There should be a standard function to check permissions. It takes a list and checks for those as well as EVERYTHING. The developer doesn't have to think about it. The checks in AppUtils should be doing this already. |
| 10:31 |
Dyrcona |
csharp_: There should 1 piece of code to check permissions that gets used everywhere, then these issues/bugs are avoided. |
| 10:31 |
jeff |
another complication that may or may not give reason to keep superuser is that I'm pretty sure EVERYTHING can be scoped, where superuser probably cannot. |
| 10:32 |
jeff |
also, nothing says that the "1 piece of code to check permissions" can't check both EVERYTHING and superuser. |
| 10:32 |
Dyrcona |
Superuser isn't magical. If some piece code doesn't check it, then whatever was going to happen doesn't happen. |
| 10:32 |
Dyrcona |
jeff: That's precisely the point, it should check for EVERYTHING and/or superuser, but I'd like superuser to go away. |
| 10:32 |
* csharp_ |
is learning lots of stuff about everyone's assumptions today :-) |
| 10:33 |
berick |
yeah most perm checks happen in the stored procs. that bit of perl is rare. |
| 10:33 |
Dyrcona |
berick just scratched off another my scabs wrt Evergreen's "eclectic" code base. |
| 10:34 |
berick |
heh |
| 10:34 |
Dyrcona |
Again, this is my opinion, but I don't think we should be doing application level permission checks in the database. |
| 10:34 |
jeff |
csharp_: that "unless" bit around the check_perms call is because check_perms returns undef on success. if the return value is truthy, it means that the user doesn't have the perm. it's... perhaps less than intuitive. |
| 10:35 |
csharp_ |
jeff: ah - out of context it was really throwing me |
| 10:35 |
Dyrcona |
Another unpopular opinion: I think we should ditch Perl for the back end (other than utility scripts). |
| 10:36 |
jeff |
Dyrcona: I don't object to PL/pgSQL functions being used to test "does this user have this perm at X location" and such. It seems efficient and not an egregious "that doesn't BELONG in the database!" kind of thing. |
| 10:36 |
csharp_ |
Dyrcona: preview of your "rusty" email? :-) |
| 10:36 |
Dyrcona |
csharp_: yes, but I'll have to write it. It might take me a few more days. |
| 10:38 |
|
kworstell_isl joined #evergreen |
| 10:38 |
Dyrcona |
berick and sleary may regret that they've opened the floodgates and made me think hard about the things that have annoyed me with Evergreen development over the past 12 years. |
| 10:40 |
berick |
not at all. i appreciate questioning my views |
| 10:44 |
Dyrcona |
berick: I think you're really on to something with the Rust code. I've glanced at it. If we decide to go that way, I think we should go all the way to replace all of the C and the majority of Perl with Rust. |
| 10:46 |
Dyrcona |
Of course, I'm not saying we do that day 1 of course. We start it with 4.0 and hopefully finish by 5.0, which means we could hit 4.100 before we get there. (Hopefully it doesn' take 50 years.) |
| 10:48 |
berick |
Dyrcona: glad to hear it |
| 10:48 |
* Dyrcona |
feels extra animated by this conversation. I think it has been a good one, even if we disagree and haven't decided anything. |
| 10:49 |
Dyrcona |
I also have a better perspective to approach my email about "the future." |
| 10:50 |
Dyrcona |
berick++ csharp_++ jeff++ |
| 10:50 |
berick |
Dyrcona++ |
| 10:51 |
csharp_ |
Dyrcona++ |
| 10:51 |
jeff |
Dyrcona++ berick++ csharp_++ sleary++ ddisbro++ |
| 10:52 |
Dyrcona |
sleary++ ddisbro++ |
| 10:54 |
Dyrcona |
i wonder if the superuser Lp bug was changed to 'opinion' and doesn't show up in the bug search. |
| 10:55 |
Dyrcona |
I swear tsbere or I opened one years ago, because I seem to recall he mostly agreed that superuser was odd. I'll look. |
| 10:56 |
Dyrcona |
Nope. Still didn't find it with expanded statuses. Guess we never made it. |
| 10:59 |
sleary |
Dyrcona no, please, do rethink things that are hard for newcomers to figure out! |
| 10:59 |
sleary |
+1 to "1 piece of code to check permissions" |
| 11:02 |
Dyrcona |
oh! I just realized another advantage of EVERYTHING over superuser. The permission should obey depth. Superuser is global/consoritum wide. You could give some EVERYTHING at their book mobile and no where else. |
| 11:37 |
eeevil |
berick: I'm seeing the server-store service's getItemBatch just kinda fail to return some of the settings I ask for. they're definitely set as YAOUSen, the settings editor is showing them. no perms attached or anything "fancy" going on, just asking for 3 related settings, 2 of which exist, and not getting 1 of them |
| 11:37 |
eeevil |
have you seen that behavior? |
| 11:38 |
Dyrcona |
eeevil: Is this with Ejabberd or Redis? (I want to know if I'm missing some possibly important context, plus I'm just nosy.) :) |
| 11:38 |
berick |
eeevil: hm, it does cache stuff in indexeded. could be related |
| 11:39 |
berick |
i haven't seen that otherwise, though |
| 11:39 |
eeevil |
Dyrcona: ejabberd |
| 11:39 |
berick |
a logout and back in should clear the cache |
| 11:39 |
eeevil |
berick: I did flush the Object and Settings indexdbs, and I'm seeing one of the setting values come back... |
| 11:40 |
berick |
huh, not sure then |
| 11:41 |
berick |
curious if the API call it's making returns the expected results |
| 11:44 |
eeevil |
welp, it was log-out-and-back-in (well, flush auth cookies and reload) |
| 11:44 |
* berick |
nods |
| 11:45 |
eeevil |
I don't like YAOUSen being cached... :( ... but that's a problem for another day |
| 11:46 |
berick |
eeevil: https://bugs.launchpad.net/evergreen/+bug/1975833 |
| 11:46 |
eeevil |
user settings, WS settings, 100% |
| 11:46 |
pinesol |
Launchpad bug 1975833 in Evergreen "IndexedDB caching of settings by Angular (and AngularJS?) should be reconsidered" [Undecided,New] |
| 11:47 |
eeevil |
ah, thanks! |
| 11:47 |
eeevil |
I'll weigh in there once I'm over this hump |
| 12:01 |
jeffdavis |
the amount of open-ils.actor traffic that was generated before settings were cached was unsupportable, if we're going to revisit that decision then we'll need an approach that doesn't result in hundreds of thousands of redundant lookups |
| 12:01 |
Dyrcona |
Yeahp. Settings don't change that often, either. |
| 12:03 |
Dyrcona |
jeffdavis: Are there cases where the UI was grabbing settings for every grid row or something like that? |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:06 |
jeffdavis |
no, it was more like looking up timezone or date formats on every page load - some examples in bug 1848550 |
| 12:06 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,Fix released] https://launchpad.net/bugs/1848550 |
| 12:09 |
Dyrcona |
Yeah, we've definitely evolved past "works for me." |
| 12:25 |
|
collum joined #evergreen |
| 12:34 |
* eeevil |
mumbles something about the 2 hard things in software engineering |
| 12:53 |
Dyrcona |
@decide local vm or remote vm |
| 12:53 |
pinesol |
Dyrcona: go with local vm |
| 12:54 |
Dyrcona |
pinesol: I thought you'd say that. |
| 12:54 |
pinesol |
Dyrcona: uh huh.. please tell me more about that |
| 13:21 |
Dyrcona |
@decide redrust or redrum |
| 13:21 |
pinesol |
Dyrcona: go with redrust |
| 13:39 |
|
mantis left #evergreen |
| 14:17 |
Dyrcona |
Well, that's a new one. First time I've had a remote VM set up fail with a ssh error. |
| 14:21 |
Dyrcona |
Why do I think this actually has something to do with the new VM trying to use the same Spice port as another? |
| 14:22 |
Dyrcona |
Nope, and all the vms on that host are doing it. |
| 14:23 |
Dyrcona |
Crazy. Looks like I lost the host's host key some time today. |
| 14:25 |
|
kworstell-isl joined #evergreen |
| 14:31 |
Dyrcona |
Oh, I realize what it was. I edited my ssh config and removed an IP address. |
| 14:32 |
Dyrcona |
So, it had to get the key for the hostname. |
| 15:02 |
Dyrcona |
ooh... Someone is asking for the "read my mind" feature again. |
| 15:04 |
|
jvwoolf joined #evergreen |
| 15:42 |
rfrasur |
Hmm, we got that request a couple times today. |
| 15:54 |
|
jvwoolf left #evergreen |
| 16:00 |
Dyrcona |
Is it just me or does Ubuntu get more annoying with every release? |
| 16:16 |
Dyrcona |
berick: I think the OpenSRF Redis README could possibly use some clarification around the redis usernames and passwords. I'm assuming that the passwords are on the lines beginning:ACL SETUSER router on >..... |
| 16:17 |
Dyrcona |
if that's autogenerated during make or install, then it could be populated in the opensrf_core.xml, too. |
| 16:20 |
Dyrcona |
i'll save my other suggestions for Lp. |
| 16:30 |
Dyrcona |
Got Could not connect to Redis at private.localhost:6379: Connection refused. I'll have to try again tomorrow. |
| 16:45 |
berick |
@later tell Dyrcona opensrf_core.xml is populated w/ the autocreated redis passwords during the Evergreen part of the install. |
| 16:45 |
pinesol |
berick: The operation succeeded. |
| 16:46 |
berick |
well, unless you already have an opensrf_core.xml in which case it won't clobber it |
| 17:13 |
|
ACSpike left #evergreen |
| 17:46 |
|
jihpringle joined #evergreen |
| 17:56 |
|
jihpringle joined #evergreen |
| 19:11 |
|
sleary joined #evergreen |
| 22:14 |
|
sleary joined #evergreen |
| 22:20 |
|
sleary_ joined #evergreen |
