| Time |
Nick |
Message |
| 03:12 |
|
book` joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:04 |
|
rjackson_isl joined #evergreen |
| 07:28 |
graced |
Happy Friday, #evergreen! |
| 07:32 |
|
agoben joined #evergreen |
| 07:49 |
|
kmlussier joined #evergreen |
| 07:58 |
|
Dyrcona joined #evergreen |
| 08:04 |
|
rlefaive joined #evergreen |
| 08:10 |
kmlussier |
Good morning #evergreen |
| 08:10 |
kmlussier |
@coffee [someone] |
| 08:11 |
* pinesol_green |
brews and pours a cup of El Salvador Los Planes Cup of Excellence 2006, and sends it sliding down the bar to eady |
| 08:11 |
kmlussier |
@tea [someone] |
| 08:11 |
* pinesol_green |
brews and pours a pot of Masala Chai, and sends it sliding down the bar to cesardv (http://ratetea.com/tea/rishi/masala-chai/4495/) |
| 08:11 |
kmlussier |
Happy Friday to you too graced! |
| 08:11 |
kmlussier |
@swill graced |
| 08:11 |
* pinesol_green |
grabs a forty of St. Ides and sends it sliding down the bar to graced |
| 08:23 |
graced |
kmlussier: I thought we were supposed to be day drinking yesterday? ;) |
| 08:23 |
kmlussier |
graced: You're supposed to limit the days when you day drink? :) |
| 08:24 |
graced |
that's what I hear... |
| 08:33 |
JBoyer |
The podcast I listened to about fake food yesterday makes the swill plugin really... interesting. o.O |
| 08:36 |
* graced |
is afeared |
| 08:38 |
JBoyer |
At least the way they alter alcohol tends to just be watering it down, heh. |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:52 |
Dyrcona |
kmlussier graced: https://www.youtube.com/watch?v=rnujhPypTfw |
| 08:52 |
|
bos20k joined #evergreen |
| 08:55 |
|
_adb joined #evergreen |
| 09:00 |
|
maryj joined #evergreen |
| 09:05 |
graced |
Dyrcona++ |
| 09:08 |
Dyrcona |
RE gitlab: I can report that this https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/raketasks/import.md works. |
| 09:09 |
jeff |
Dyrcona: that's useful, as opposed to needing to push branch at a time to a remote on a new gitlab instance. :-) |
| 09:09 |
jeff |
(which i've done for small things that started elsewhere and now live on both github and gitlab here) |
| 09:09 |
Dyrcona |
Yeap. I just imported a bunch of cwmars repos using those steps. |
| 09:09 |
jeff |
good deal. |
| 09:10 |
Dyrcona |
Twelve projects in a matter of minutes, including copying from one server to another. |
| 09:12 |
Dyrcona |
It even create a cwmars group automatically. |
| 09:12 |
Dyrcona |
created... bah! |
| 09:13 |
jeff |
didn't leave enough notes for myself. i can't recall if this explicit rollback() when indexing marc to elasticsearch was to work around an issue or just a natural part of the way i'm paging things. |
| 09:13 |
jeff |
i think the latter. |
| 09:24 |
|
mmorgan joined #evergreen |
| 09:27 |
|
mmorgan1 joined #evergreen |
| 09:32 |
|
yboston joined #evergreen |
| 09:33 |
|
jvwoolf joined #evergreen |
| 09:37 |
Dyrcona |
If we go with gitlab, I think we're going to look more like github, with individual repos instead of a working repo. |
| 09:37 |
Dyrcona |
Gitlab does not make it easy to manage permissions on branches like we do now. |
| 09:42 |
Dyrcona |
I think we need to have a conversation about what we need. |
| 09:42 |
Dyrcona |
I know the wiki page is an attempt to do that, but it seems to be only a few of us commenting there. |
| 09:54 |
jeff |
yeah, i don't think that wiki pages are a good place for conversation to take place. |
| 09:56 |
jeff |
though they can be a useful tool for referring to and updating as the conversation takes place... elsewhere. :-) |
| 09:56 |
jeff |
i need to go back and review the minutes / log from this week's dev meeting. |
| 09:57 |
jeff |
did we set any kind of self-imposed deadline for making a decision on alternatives? |
| 10:02 |
berick |
jeff: not yet |
| 10:03 |
berick |
at least not at the meeting |
| 10:24 |
berick |
individual repos will be fine for user/*/foo branches -- maybe better. and that's what we mostly use the working repo for. |
| 10:24 |
berick |
collab branches are a different story of course |
| 10:25 |
dbs |
Doesn't a collab branch just become a standard "here's my branch based on your branch" story? |
| 10:25 |
berick |
dbs: with a few notable exceptions, yes. a lot of the recent web staff dev used collab branches in the originally intended way, i thikn |
| 10:26 |
dbs |
(but I never really saw much of a use case for collab branches) |
| 10:26 |
berick |
yeah, they don't get much use |
| 10:26 |
berick |
for larger things like "web staff sprint X", we could just as easily spin up a new repository and invite contributor (I'm assuming). |
| 10:27 |
berick |
*contributors |
| 10:27 |
kmlussier |
I think we used a collab branch for that initial responsive design work. It was useful in that context too since so many people were contributing to it. |
| 10:31 |
berick |
another good example |
| 10:35 |
dbs |
It just seems like a model for long-lived feature branches, which I think the "new repository with multiple contributors" satisfies? |
| 10:36 |
berick |
yeah, i think the new-repo approach covers it. |
| 10:36 |
berick |
I will note for the sake of completeness, github does let you set branch-level restrictions. |
| 10:39 |
gmcharlt |
gitlab EE does too, looks like... but even if we were to consider paying for it, I don't think their pricing model would work all that well |
| 10:40 |
gmcharlt |
(and besides, I think we should stick with unencumbered F/LOSS for anything we host ourselves, not that that forecloses the possibility of considering requesting a funding a "tip") |
| 10:42 |
berick |
agreed re: self-hosted |
| 10:42 |
gmcharlt |
in any event, I think a model with more individual repos + one or more shared one without branch restrictions would work |
| 10:44 |
jeff |
i'm not sure there's need for new repo for "long running feature collab branches". those are just branches. |
| 10:45 |
jeff |
or optionally branches on individual user forks of the main repo, or yeah... on a group fork. |
| 10:47 |
Dyrcona |
gitlab CE allows for protected branches, but that isn't quite the same thing as gitlab EE's user permissions on branches. |
| 10:47 |
|
Christineb joined #evergreen |
| 10:48 |
Dyrcona |
I agree that we should prefer F/LOSS for whatever we do. |
| 10:48 |
jeff |
some of it depends on who is going to be collab'ing on the collab branch, too. |
| 10:49 |
Dyrcona |
I'm not sure collabs are gonna work out so well with a gitlab model. |
| 10:50 |
Dyrcona |
I'm not saying that should stop us from choosing it, as mentioned before, we don't really do much with collabs other than a few notable exceptions. |
| 10:51 |
Dyrcona |
Groups are rather permanent things in gitlab. |
| 10:51 |
|
mmorgan1 joined #evergreen |
| 10:52 |
dbs |
jeff: yeah pretty much my take |
| 10:52 |
jeff |
if we have an Evergreen repo/project under a group, and that group contains core committers, then they can collab on branches in that repo. it's the collab with people not in that group where you might want to form another repo -- if a workflow of people contributing in their own forks and people merging between them doesn't work for some reason. |
| 10:52 |
dbs |
I do like the idea of having LDAP or something centralized for auth across gitlab / wiki / blog / etc as a long-term goal |
| 10:53 |
dbs |
(start with central auth for gitlab and then slowly spread out over time?) |
| 10:54 |
jeff |
i like it in theory but i'm not convinced were at the scale where the complexity is saving us anything. |
| 10:55 |
Dyrcona |
You can grant others access to your own repos. |
| 10:55 |
jeff |
in gitlab, you can have protected branches and protected tags. set at the repo level (usually?), they are rules which can contain wildcards. |
| 10:55 |
dbs |
Rather than having "if you want a wiki account, go here; if you want a gitlab account, go there" |
| 10:55 |
Dyrcona |
There's a checkbox to permit others to request access. |
| 10:55 |
|
abowling joined #evergreen |
| 10:55 |
gmcharlt |
hmm |
| 10:55 |
Dyrcona |
jeff: Yes, but protected branches aren't the same thing as saying this user can do x. |
| 10:56 |
gmcharlt |
looks like gitlab could act as an oauth provider - https://docs.gitlab.com/ce/integration/oauth_provider.html |
| 10:56 |
jeff |
Dyrcona: correct. |
| 10:57 |
jeff |
dbs: that process can probably be improved by using a better method of requesting access before we jump into ldap/oauth/etc. i'm not arguing against, but i'm not convinced yet. :-) |
| 10:59 |
Dyrcona |
Well, I like the idea of oauth/ldap/sso. |
| 10:59 |
Dyrcona |
Not necessarily ldap, mind you. |
| 11:00 |
Dyrcona |
I think there are plugins to allow you to sign in with a github id or g+ and/or facebook, too. |
| 11:00 |
dbs |
yep omniauth |
| 11:00 |
* Dyrcona |
uses g+ and github for a few other sites. |
| 11:15 |
pinesol_green |
[evergreen|Dan Scott] LP#169787 High contrast text in patron summary alert buttons - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9b5cbea> |
| 11:20 |
* gmcharlt |
claims 1045 in the name of cats working from home everywhere! |
| 11:21 |
kmlussier |
gmcharlt: Your cat works? Mine just lies across my keyboard when I try to work from home. |
| 11:22 |
gmcharlt |
sure they do! they just define their job as interfering with mine! |
| 11:22 |
* mmorgan |
pictures her cats working hard at home holding down the furniture and absorbing solar radiation. |
| 11:25 |
kmlussier |
I suppose my cat's ongoing battle with the other cat who appears at the window (i.e. his reflection) might qualify as work. |
| 11:25 |
mmorgan |
:) |
| 11:26 |
berick |
@blame mirror cat |
| 11:26 |
pinesol_green |
berick: mirror cat broke Evergreen. |
| 11:27 |
mmorgan |
No doubt kmlussier's cat would lay such blame :) |
| 11:30 |
berick |
:) |
| 11:38 |
JBoyer |
"I am with $company located in $city. If you have an interest in discussing our products/services, I will be happy to assist. Have a great day!" - I mean, if you don't think I'm interested enough to read more than that why bother me at all? |
| 11:40 |
berick |
JBoyer lasts 5 minutes before contacting them just to see what they do |
| 11:41 |
pinesol_green |
Showing latest 5 of 7 commits to Evergreen... |
| 11:41 |
pinesol_green |
[evergreen|Chris Sharp] LP#1612752 - Adding release notes for Transit Cancel time and terminology change. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2e7dfb9> |
| 11:41 |
pinesol_green |
[evergreen|Chris Sharp] LP#1612752 - Do not clobber local perm description changes. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0584c40> |
| 11:41 |
pinesol_green |
[evergreen|Bill Erickson] LP#1612752 No canceled transits in webstaff transit list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=96c30eb> |
| 11:41 |
pinesol_green |
[evergreen|Galen Charlton] LP#1612752: stamp schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fe44ac2> |
| 11:41 |
pinesol_green |
[evergreen|Galen Charlton] LP#1612752: apply terminology change to web staff - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8b34a4f> |
| 11:41 |
JBoyer |
"So tell me, $sender, what would you say, you do here?" |
| 11:42 |
berick |
JBoyer++ |
| 11:43 |
Dyrcona |
Is there a way to change a patron's password in the database that works with 2.12? |
| 11:43 |
berick |
gmcharlt++ csharp++ # canceled transits |
| 11:43 |
Dyrcona |
The old just updating actor.usr.passwd didn't seem to work. |
| 11:44 |
berick |
Dyrcona: indeed, we need to drop that column to avoid confusion. see actor.set_passwd() in the DB. beware MD5 stuff has to happen outside of that function. |
| 11:44 |
Dyrcona |
berick++ # I was just getting there. :) |
| 11:44 |
Dyrcona |
I recalled seeing a new function after I asked. |
| 11:45 |
berick |
Dyrcona: also, if they don't already have a new password, migrate_password will do it all for you, including the md5 stuff |
| 11:45 |
Bmagic |
Has anyone setup an action trigger to send an email to the patron when an item is marked damaged? |
| 11:49 |
berick |
Dyrcona: i think this would do it: select actor.set_passwd(user_id, 'main', MD5(salt || MD5(plain_text_password)), salt); |
| 11:49 |
Bmagic |
I don't see a way to connect the item to the circulation in order to target an actor.usr |
| 11:51 |
berick |
Bmagic: see the 'checkout.damaged' hook |
| 11:51 |
Dyrcona |
berick: Still not working for me, but I'll keep trying. |
| 11:51 |
berick |
Bmagic: you'll have to create a new event_def -- but that one links to the circ |
| 11:52 |
Bmagic |
Dyrcona: It's a two step process. first you have to generate a salt select * from actor.create_salt('main') |
| 11:52 |
Bmagic |
berick++ I must have over looked that hook |
| 11:52 |
Dyrcona |
Bmagic: Yeah, I'm getting there. |
| 11:52 |
berick |
yes, actor.create_salt(), thanks Bmagic. |
| 11:52 |
berick |
i glossed over that :( |
| 11:53 |
Dyrcona |
What about actor.get_salt()? |
| 11:53 |
Bmagic |
berick: on the processing delay field, can I use target_copy.status_changed_time ? |
| 11:54 |
Dyrcona |
Ima write a lit db function to cheat this in the future. |
| 11:58 |
berick |
Bmagic: yeah, pretty sure, as long as target_copy is in the environment |
| 11:59 |
Bmagic |
I don't think I have ever used a foriegn key for processing delay field |
| 11:59 |
|
jvwoolf joined #evergreen |
| 11:59 |
berick |
Dyrcona: the api uses new_salt when changing the password. get_salt() is more about handling an existing password (e.g. during login) |
| 12:00 |
berick |
i mean you could re-use the salt, but that seems non-good. |
| 12:00 |
Dyrcona |
OK. In my case, I'm reusing the salt, but this is just to test something not related. :) |
| 12:01 |
Dyrcona |
I wanted to change the password for a user on my test database to try downloading their circ history. |
| 12:01 |
Dyrcona |
I think I will write myself a custom function doing it correctly for future situations like this. |
| 12:02 |
Dyrcona |
I just pulled the salt, etc., from the db tables this time. |
| 12:03 |
berick |
Dyrcona: fyi, Actor::modify_migrated_user_password() shows the typical steps for moding a passowrd. translating that to a DB func would be trivial. |
| 12:04 |
Dyrcona |
OK. |
| 12:04 |
Dyrcona |
I think my test db/vm are too slow. |
| 12:04 |
Dyrcona |
Oh. nice. internal server error. |
| 12:06 |
Dyrcona |
[Fri Jun 09 12:05:20.331897 2017] [perl:error] [pid 20167] [client 192.168.100.100:43488] Apache2::RequestIO::print: (32) Broken pipe at /usr/lib/x86_64-linux-gnu/perl5/5.22/Template.pm line 180, referer: https://10.250.150.80/eg/opac/myopac/circ_history |
| 12:07 |
pinesol_green |
[evergreen|Terran McCanna] LP#1681943 Improve Responsive Design in My Lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d786c57> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1681943: tweak background color of edit list description box - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c87fb2d> |
| 12:07 |
pinesol_green |
[evergreen|Ben Shum] LP#1681943: Use variables for CSS colors - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dfb56b6> |
| 12:07 |
pinesol_green |
[evergreen|Ben Shum] LP#1681943: Tweak for RTL handling for responsive my lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e6dc0c5> |
| 12:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1681943: show all list fields in mobile view - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2d67204> |
| 12:10 |
berick |
Bmagic: i take it back, I think the delay_field has to be a field on the core object. since it's an active hook, though, you don't need a delay_field. you can just say "send the email 10 minutes after it's marked damaged" or what have you. |
| 12:10 |
Dyrcona |
osrfsys.log is not logging anything useful.... |
| 12:11 |
Bmagic |
berick: just make it null? |
| 12:11 |
berick |
Bmagic: yep |
| 12:11 |
Bmagic |
groovy |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:26 |
|
Rsulejmani joined #evergreen |
| 13:26 |
Rsulejmani |
Hi |
| 13:27 |
Rsulejmani |
I know you can install Evergreen on Linux but can You install it on Windows |
| 13:28 |
kmlussier |
Rsulejmani: The server portion must be installed on Linux, preferably Debian or Ubuntu LTS. You can run the client on Windows, but not the server. |
| 13:29 |
Rsulejmani |
Ok |
| 14:17 |
|
b_bonner joined #evergreen |
| 14:34 |
|
b_bonner joined #evergreen |
| 14:35 |
|
mnsri_away joined #evergreen |
| 14:37 |
|
rashma_away joined #evergreen |
| 14:53 |
|
abowling1 joined #evergreen |
| 14:57 |
|
ningalls joined #evergreen |
| 15:21 |
Bmagic |
Ha! - I just found a bug (maybe) |
| 15:25 |
|
abowling joined #evergreen |
| 15:27 |
Bmagic |
The library setting "Jump to details on 1 hit (staff client)" and "Jump to details on 1 hit (public)" - can result in "BAD REQUEST 400" when you turn on grouped results AND the result is single metarecord |
| 15:27 |
Bmagic |
Did everyone already know that and I am just late to the party? |
| 15:28 |
pinesol_green |
[evergreen|Jason Etheridge] lp1533326 webstaff: Actions for Item Status Detail View - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad952a9> |
| 15:28 |
pinesol_green |
[evergreen|Jason Etheridge] webstaff: Item Status bugs with Transfer Items... - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e8b62d4> |
| 15:28 |
pinesol_green |
[evergreen|Bill Erickson] LP#1533326 Item status actions menu styling - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1654eb8> |
| 15:28 |
pinesol_green |
[evergreen|Galen Charlton] LP#1533326: follow-up to remove extra logging statement - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c1ecb35> |
| 15:33 |
Bmagic |
It looks like it's solved in 2.12.x |
| 15:41 |
|
kmlussier joined #evergreen |
| 15:41 |
* kmlussier |
shakes her fist at Comcast |
| 15:45 |
kmlussier |
Of course, now that I think about it, I probably could have continued testing offline circ while Comcast was down. |
| 15:45 |
berick |
Comcast is your mirror cat |
| 15:47 |
kmlussier |
It all comes back to the mirror cat, doesn't it? |
| 15:49 |
mmorgan |
Pay no attention to the cat in the mirror... |
| 15:49 |
* Dyrcona |
shakes his fist at pgadmin3 over the internet. |
| 15:49 |
Dyrcona |
mmorgan++ |
| 15:51 |
Dyrcona |
Maybe I should be shaking my fist at the crappy VPN we use for work. |
| 15:53 |
Dyrcona |
Still, a networked application should not become unusable/unrecoverable when it loses the network. |
| 15:57 |
miker |
ng+intput[type=radio]-- |
| 16:05 |
Dyrcona |
intput? Typo in the original? |
| 16:06 |
* Dyrcona |
makes that one a bit more than he'd like to admit. |
| 16:13 |
miker |
not copy-paste, typo's mine in here :) |
| 16:14 |
miker |
no, it's just that you can't say "no, make that other radio button selected via change to a scope var" |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:51 |
|
Jillianne joined #evergreen |
| 16:55 |
|
jvwoolf left #evergreen |
| 17:02 |
|
mmorgan left #evergreen |
| 17:38 |
gmcharlt |
https://evergreen-ils.org/evergreen-3-0-development-update-9/ |
| 18:14 |
|
rlefaive joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
