| Time |
Nick |
Message |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:00 |
|
agoben joined #evergreen |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:36 |
csharp |
@later tell Bmagic yes - they probably didn't specify a match set or import profile correctly |
| 07:36 |
pinesol_green |
csharp: The operation succeeded. |
| 07:41 |
* csharp |
stows a copy of our dojo version at http://archive.georgialibraries.org/dojo/ |
| 07:42 |
csharp |
also, we retain a copy of xulrunner in case mozilla decides to pull it someday: http://archive.georgialibraries.org/xulrunner/ |
| 07:43 |
csharp |
...and, jsyk, http://archive.georgialibraries.org/ is the same server as http://list.evergreen-ils.org/ |
| 07:54 |
|
kmlussier joined #evergreen |
| 08:05 |
|
rlefaive joined #evergreen |
| 08:16 |
csharp |
@marc 001 |
| 08:16 |
pinesol_green |
csharp: The control number assigned by the organization creating, using, or distributing the record. The MARC code for the organization is contained in field 003 (Control Number Identifier). [] |
| 08:16 |
kmlussier |
@later tell Bmagic Usually, it means they didn't import non-matching records or didn't import records that had a match. They need to do both so that the acq record can be linked to a real bib. |
| 08:16 |
pinesol_green |
kmlussier: The operation succeeded. |
| 08:16 |
csharp |
kmlussier++ # clarifyin' |
| 08:27 |
|
collum joined #evergreen |
| 08:36 |
|
Dyrcona joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:51 |
|
krvmga joined #evergreen |
| 09:00 |
* kmlussier |
knows we can't use jquery, but thinks the toggle option here - https://www.filamentgroup.com/lab/tablesaw.html -would be an elegant solution for handling My Account tables on mobile devices. |
| 09:02 |
mmorgan |
Nice! |
| 09:04 |
|
jwoodard joined #evergreen |
| 09:14 |
|
maryj joined #evergreen |
| 09:42 |
jeff |
kmlussier: why can't we use jquery on mobile devices? |
| 09:44 |
kmlussier |
jeff: I have no idea. My understanding is that we're supposed to stick with the current frameworks that we're already using. |
| 09:45 |
jeff |
Ah. |
| 09:47 |
jeff |
I'm not arguing for jquery, but wanted to know if there was a hard conflict that I wasn't thinking of. |
| 09:47 |
jeff |
kmlussier++ thanks! |
| 09:48 |
kmlussier |
jeff: Yes, and I'm not arguing against jquery. Just trying to conform to the 'rules' as I understand them. :) |
| 09:48 |
kmlussier |
Also, I wish I hadn't looked at that example because now I really want it. |
| 09:49 |
csharp |
I think it's less about "the rules" than it is about overextending the project by adding more frameworks/dependencies/kittens :-) |
| 09:49 |
Dyrcona |
Yeah, there really aren't any rules. It's a preference that some of us have expressed. |
| 09:50 |
Dyrcona |
I for one would rather not have to learn yet another JavaScript framework. |
| 09:50 |
csharp |
not until we retire our deprecated dojo in any case |
| 09:52 |
JBoyer |
A better way to look at it is "we're not adding jquery, we're replacing dojo" and then it becomes a bit more work. Not that it's not necessary, just that there's a lot involved. And unless Angular can do everything we need for the OPAC in addition to the web client (I don't know offhand) there's at least one more framework to learn no matter what. |
| 09:52 |
JBoyer |
(I assume even using modern dojo is different enough at this point that it would be relearning.) |
| 09:52 |
Dyrcona |
Yeah, but I'd rather replace Dojo with Angular. |
| 09:52 |
csharp |
JBoyer: it would |
| 09:53 |
JBoyer |
And if it can do everything them I'm all for that too. Like I said, I didn't know. :) |
| 09:53 |
Dyrcona |
Eh, we'd just have to stop using the unpublished API. |
| 09:53 |
rhamby |
my vague memory of past discussions is in line with csharp's, not that we said "no jquery ever" but "lets make sure we really really need it" so as to not create yet another dependency |
| 09:53 |
* csharp |
is desperately trying to prop up dojo acq interfaces |
| 09:54 |
* JBoyer |
wonders if csharp would like to convert them to Angular instead. ;) |
| 09:54 |
berick |
btw, we require jquery as part of the browser client now. angular relies on it. of course, that's not the same as using it directly. |
| 09:55 |
* kmlussier |
would strongly advocate for converting the acq Dojo interfaces to Angular after the initial web client work is done. |
| 09:55 |
kmlussier |
I've always thought of the web client project as phase 1. |
| 09:55 |
jeff |
Dojo 2 beta is expected out this fall... ;-) |
| 09:55 |
* jeff |
ducks |
| 09:56 |
berick |
+1 to moving ACQ UI's to angular |
| 09:56 |
berick |
+1 to moving all non-angular staff UI's to angular |
| 09:56 |
kmlussier |
I took a quick look at Angular, but didn't see anything that handled that tables as well as that jquery plugin. I saw something similar, but not quite the same. |
| 09:57 |
Dyrcona |
Angular 2 RC5 was released last month. |
| 09:57 |
kmlussier |
berick: Agreed on moving all non-angular staff UI's. acq would just be my next top priority. |
| 09:57 |
* berick |
nods |
| 09:57 |
* Dyrcona |
ducks out for a conference call. |
| 10:00 |
|
yboston joined #evergreen |
| 10:13 |
kmlussier |
This could work http://gergeo.se/RWD-Table-Patterns/ |
| 10:14 |
kmlussier |
Oh, that has a jquery dependency too. Missed that. |
| 10:18 |
csharp |
kmlussier: if, as berick says, it's already installed for angular, I don't see any impediment for leveraging it (speaking for myself) |
| 10:18 |
csharp |
it might not be a big deal to get something like that up and running |
| 10:18 |
JBoyer |
kmlussier, depending on what berick meant about Angular already requiring JQuery, we might be able to make limited use of some plugins provided there's a good way to do that without rocking Angular's boat. |
| 10:19 |
* csharp |
sees an opportunity for a proof-of-concept, maybe at the hack-a-way |
| 10:20 |
kmlussier |
Yeah, I don't want to cause too much disruption. But I was planning to look at these screens during the hack-a-way, so maybe we can make something happen. |
| 10:23 |
|
maryj joined #evergreen |
| 10:41 |
|
rlefaive joined #evergreen |
| 10:44 |
|
bmills joined #evergreen |
| 10:47 |
|
gsams_ joined #evergreen |
| 11:06 |
|
jihpringle joined #evergreen |
| 11:13 |
|
ssieb joined #evergreen |
| 11:54 |
|
brahmina joined #evergreen |
| 11:56 |
csharp |
oclc-- |
| 12:01 |
bshum |
@flip |
| 12:01 |
pinesol_green |
bshum: Yeah, well, you know, that's just like uh, your opinion, man. |
| 12:01 |
bshum |
@coin |
| 12:01 |
pinesol_green |
bshum: heads |
| 12:02 |
kmlussier |
bshum: Deciding on lunch? |
| 12:02 |
bshum |
Among other things :) |
| 12:15 |
|
sandbergja joined #evergreen |
| 12:16 |
|
_adb joined #evergreen |
| 12:21 |
|
bos20k joined #evergreen |
| 12:21 |
* dbs |
wonders how the heck a simple open-ils.cat.asset.copy.fleshed.batch.update can result in a cstore timeout |
| 12:22 |
jeff |
dbs: busy system? can you reproduce, or are you only looking at logs at this point? |
| 12:22 |
Dyrcona |
How big is the batch? :) |
| 12:22 |
jeff |
I mean, "busy system" probably shouldn't result in a timeout like that except for very bad values of "busy", but... |
| 12:23 |
jeff |
...or very large values of batch, perhaps. :-) |
| 12:25 |
dbs |
jeff: just looking at the logs right now |
| 12:26 |
dbs |
It's a batch of one items. |
| 12:26 |
* dbs |
will go peek at the open-ils.cat.stderr to see if there's any corresponding errors |
| 12:26 |
dbs |
We do have a ton of disturbing "No active transaction" errors associated with cstore commits and rollbacks |
| 12:48 |
|
agoben joined #evergreen |
| 12:50 |
dbs |
more fun mysteries: log into a workstation registered with org 131 as a user with home_ou 103, check in an item with owning_lib 131 & circ_lib 131, and see it go in transit to 131 (somehow it thinks the checkin lib is 103, despite the workstation) |
| 12:52 |
csharp |
dbs: is there floating involved? (stab in the dark) |
| 12:54 |
dbs |
csharp: we've never configured that, so unless it's an exciting new default it shouldn't be :) |
| 12:54 |
mmorgan |
dbs: is the transit source 103? |
| 12:54 |
tsbere |
dbs: Mistakenly set on the copy? >_> |
| 12:54 |
csharp |
dbs: the copy would have a floating_group value |
| 12:55 |
dbs |
mmorgan: action.transit_copy.source is indeed 103 |
| 12:56 |
dbs |
csharp: asset.copy.floating is NULL |
| 12:56 |
mmorgan |
and it's a current transit, not a hanging one? |
| 12:57 |
dbs |
mmorgan: I've never seen a hanging transit before, but maybe that's what all of the recent hullabaloo was over the past couple of weeks? |
| 12:57 |
mmorgan |
If there'a a local hold - capture local holds as transits? (more stabbing in the dark) |
| 12:58 |
|
maryj joined #evergreen |
| 12:59 |
dbs |
mmorgan: no holds have ever been placed on the title or copy |
| 13:02 |
dbs |
Fun, any random item from 131 that I check in using a workstation registered with 131 is getting put in transit to 131 |
| 13:02 |
jeff |
self-transits suggest "capture local holds as transits" |
| 13:02 |
* dbs |
can't imagine how, but wonders anyway if auth_proxy can somehow be interfering with checkin_lib |
| 13:03 |
dbs |
oh, hmm |
| 13:03 |
jeff |
sure, if the workstation ou isn't getting properly set in the session object as stored in memcache. |
| 13:03 |
jeff |
but i 1) would expect lots of things to break and 2) thought you already ran into something like that and fixed it |
| 13:04 |
jeff |
but I think you also said that the checkin lib was being set to 103 (which corresponded to the staff user's home_ou) |
| 13:04 |
jeff |
and your source was 103, so that wouldn't imply capture local holds as transits. |
| 13:04 |
dbs |
I did say the checkin lib was being set the the staff user's home_ou, not the workstation ou |
| 13:05 |
dbs |
one of the only code differences we have compared to rel_2_10 is http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=25f3c67032c1b9be806fd05d1bb20ddc16e98348 |
| 13:05 |
dbs |
(which prompted the "oh, hmm" above) |
| 13:08 |
dbwells |
dbs: not sure how, but since it is also a workstation ID thing, it might be related to your previous bug #1620803. I'm going to poke at that one right now and see if anything jumps out at me. |
| 13:08 |
pinesol_green |
Launchpad bug 1620803 in Evergreen "User opt-in when staff member has logged in via proxied authentication fails due to missing workstation ID" [Undecided,New] https://launchpad.net/bugs/1620803 |
| 13:10 |
dbs |
dwells++ # I had totally forgotten about that |
| 13:13 |
jeff |
that was the one i was thinking of in my 2) above. dbwells++ |
| 13:19 |
dbwells |
I think I see the issue, trying to verify... |
| 13:23 |
pastebot |
"dbwells" at 64.57.241.14 pasted "quick fix for missing workstation using AuthProxy.pm" (12 lines) at http://paste.evergreen-ils.org/25 |
| 13:24 |
dbs |
hah, that looks like a clear fix :) |
| 13:26 |
dbs |
is there any need for an "if exists args-{$workstation_id}" block? i.e. anytime when a workstation id will not be set in that flow? |
| 13:27 |
dbwells |
OPAC logins won't have a workstation. Is that what you mean? |
| 13:27 |
dbs |
dbwells: yeah |
| 13:28 |
dbwells |
I think passing through the undefined value will be harmless, since it will "Otherwise, use the home org as the workstation org on the user", as you are seeing now. |
| 13:29 |
dbs |
okay. I'm willing to give it a shot :) |
| 13:31 |
* dbs |
heads over to the dev server |
| 13:35 |
dbwells |
dbs: OPAC login seems fine over here, I've pushed it into production to see if it holds water. |
| 13:35 |
* dbwells |
waits by the phone |
| 13:36 |
Dyrcona |
heh. |
| 13:37 |
* dbs |
confirms that checkin on a master-ish dev system does not route items to the user's home_ou |
| 13:37 |
dbs |
(with dbwells' patch that is) |
| 13:40 |
dbwells |
I will get it branchified, it was just an oversight not caught in my OPAC-centric and limited_ou environment. |
| 13:40 |
dbs |
dbwells++ # I will get it sign-off-if-fied |
| 13:40 |
dbs |
due to our weird world of auth_proxy + many OUs + opt-in (sounds like Sitka actually) |
| 13:44 |
dbs |
works in production too, yay. |
| 13:47 |
Dyrcona |
dbs++ dbwells++ |
| 13:51 |
dbwells |
dbs: branch up here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1620803_passthru_workstation_in_authproxy |
| 13:54 |
dbs |
and pushed to master |
| 13:56 |
pinesol_green |
[evergreen|Dan Wells] LP#1620803 Add missing workstation passthru to AuthProxy - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2db3350> |
| 13:56 |
|
bmills joined #evergreen |
| 13:57 |
Dyrcona |
That should got to 2.10 also, yes? |
| 13:57 |
dbwells |
yes |
| 13:57 |
dbwells |
good call |
| 13:58 |
Dyrcona |
Just making sure it wasn't missed. :) |
| 13:58 |
* dbs |
has targeted it for 2.10 in launchpad |
| 14:13 |
|
krvmga joined #evergreen |
| 14:20 |
|
ssieb joined #evergreen |
| 14:22 |
|
maryj joined #evergreen |
| 14:33 |
Dyrcona |
Does the hackaway usually end at noon on the last day? |
| 14:33 |
agoben |
I believe that's the plan, yes |
| 14:34 |
Dyrcona |
Thanks. I'm looking at travel arrangements. |
| 14:34 |
agoben |
:) |
| 14:35 |
* kmlussier |
will be missing the last day, unfortunately. |
| 14:35 |
* berick |
is reconsidering his plan to drive to the hackaway |
| 14:35 |
kmlussier |
But, hey. A few months ago, I wasn't planning to attend, so I guess progress has been made. |
| 14:35 |
kmlussier |
berick: How far is the drive? |
| 14:36 |
JBoyer |
I'd say less than 9 hours. ;) |
| 14:36 |
berick |
kmlussier: 9.5 hours (not counting stops) -- that's pushing my limits |
| 14:36 |
JBoyer |
Oops, close. |
| 14:36 |
berick |
as the g-maps flies |
| 14:37 |
jeff |
i do still enjoy that google maps takes urls as inputs for driving directions |
| 14:37 |
JBoyer |
I'll save all the bad influence stuff about grabbing lunch at a local microbrewery and suggest that safety carry the day. I GUESS. |
| 14:38 |
bshum |
Safety is important :) |
| 14:41 |
jeff |
"typically 5h 50m to 7h" |
| 14:52 |
Dyrcona |
agoben | Jboyer: Has there been much interest in getting the Harrison House? |
| 15:00 |
JBoyer |
Dyrcona, I don't have that survey handy. I know there has been some interest. |
| 15:00 |
Dyrcona |
Well, I just checked the box, but haven't submitted, yet. |
| 15:01 |
Dyrcona |
Seems strange to be asked about entertainment options for a business trip. :) |
| 15:01 |
JBoyer |
You're not required to stay there if you put it on your survey. ;) (we certainly wouldn't make 1 person pay for the whole thing if they were the only one interested...) |
| 15:01 |
Dyrcona |
Right. |
| 15:02 |
Dyrcona |
I heard rumors that it would come to about $75 per person if we had 6 people interested. |
| 15:02 |
JBoyer |
The thinking was that we could do something fun 1 night, even if it's just really good places to eat. (of which there are many.) |
| 15:03 |
Dyrcona |
Yes. I won't spoil it for others by saying what option I selected. |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:04 |
csharp |
jeff: you planning to be there? |
| 15:04 |
Dyrcona |
So, I've booked my flight and filled out the survey. Should I go ahead and make arrangements on the accommodations, or should I/we wait to find out about interest in Harrison House? |
| 15:06 |
JBoyer |
Dyrcona, you'll want to wait if you're interested in the house. I'll find out. |
| 15:06 |
csharp |
oh yeah, I need to update the survey with flight info |
| 15:06 |
dbwells |
Dyrcona: I have some interest in the house option, but also went ahead and booked a room, since it appeared to be fully-cancelable until 2-3 days out (can't recall exactly). Just a thought. |
| 15:07 |
Dyrcona |
JBoyer: Thanks. No rush as far as I am concerned as long as there is accommodation. |
| 15:08 |
Dyrcona |
dbwells: Thanks for mentioning about the cancellation policy. I think I'll wait. I know at least one other person is interested in the house, too. |
| 15:10 |
agoben |
I'm definitely securing the Harrison House, will email everyone who's indicated interest to confirm. |
| 15:12 |
dbwells |
Looking at the spreadsheet, I see there is already five folks with interest in the house, so I'll bow out (I didn't put that initially on the form). |
| 15:19 |
|
serflog joined #evergreen |
| 15:19 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 15:23 |
|
jeff_ joined #evergreen |
| 15:23 |
|
sarabee joined #evergreen |
| 15:23 |
|
berick joined #evergreen |
| 15:23 |
|
jamesrf joined #evergreen |
| 15:23 |
|
RBecker joined #evergreen |
| 15:23 |
|
mnsri joined #evergreen |
| 15:23 |
|
bcormack joined #evergreen |
| 15:23 |
|
rashma joined #evergreen |
| 15:23 |
|
b_bonner joined #evergreen |
| 15:23 |
|
Shae joined #evergreen |
| 15:23 |
|
remingtron joined #evergreen |
| 15:23 |
|
wjr joined #evergreen |
| 15:23 |
|
agoben joined #evergreen |
| 15:23 |
|
rjackson_isl joined #evergreen |
| 15:23 |
|
ssieb joined #evergreen |
| 15:23 |
|
JBoyer joined #evergreen |
| 15:23 |
|
gsams joined #evergreen |
| 15:23 |
|
csharp joined #evergreen |
| 15:23 |
|
genpaku joined #evergreen |
| 15:23 |
|
ejk joined #evergreen |
| 15:23 |
|
sard joined #evergreen |
| 15:23 |
|
yboston joined #evergreen |
| 15:23 |
|
tsbere joined #evergreen |
| 15:23 |
|
graced joined #evergreen |
| 15:23 |
|
bmills joined #evergreen |
| 15:23 |
|
bos20k joined #evergreen |
| 15:23 |
|
phasefx_ joined #evergreen |
| 15:23 |
|
artunit joined #evergreen |
| 15:23 |
|
dbwells joined #evergreen |
| 15:23 |
|
kmlussier joined #evergreen |
| 15:23 |
|
Guest45886 joined #evergreen |
| 15:23 |
|
jeff__ joined #evergreen |
| 15:23 |
|
miker joined #evergreen |
| 15:23 |
|
akilsdonk joined #evergreen |
| 15:23 |
|
eby joined #evergreen |
| 15:23 |
|
jonadab joined #evergreen |
| 15:23 |
|
pastebot joined #evergreen |
| 15:23 |
|
bshum joined #evergreen |
| 15:23 |
|
mceraso joined #evergreen |
| 15:23 |
|
ericar joined #evergreen |
| 15:23 |
|
dbs joined #evergreen |
| 15:23 |
|
Bmagic joined #evergreen |
| 15:23 |
|
jihpringle joined #evergreen |
| 15:23 |
|
gmcharlt joined #evergreen |
| 15:23 |
|
rlefaive joined #evergreen |
| 15:23 |
|
rhamby joined #evergreen |
| 15:23 |
|
pinesol_green joined #evergreen |
| 15:23 |
|
phasefx joined #evergreen |
| 15:23 |
|
Dyrcona joined #evergreen |
| 15:23 |
|
Stompro joined #evergreen |
| 15:23 |
|
mmorgan1 joined #evergreen |
| 15:23 |
|
Dyrcona joined #evergreen |
| 15:24 |
|
book` joined #evergreen |
| 15:24 |
agoben |
dbwells: Nobody's held to it until I get a confirmation in if you think you might prefer the house! |
| 15:28 |
dbwells |
agoben: Well, I also realized I wasn't thinking straight. Since I am already sharing a room with remingtron, it would actually be more expensive for us to do the house instead, I think. Sounds like fun, though. |
| 15:29 |
|
rlefaive joined #evergreen |
| 15:29 |
agoben |
dbwells: Absolutely understandable. We'll probably spend some time there as a group anyway since it has some good sized common areas that seem to be very conducive to chatting :) |
| 15:42 |
Bmagic |
agoben: I'm interested - not sure what I put on the google form |
| 15:51 |
agoben |
Bmagic: I have you down for the House, yes. |
| 15:58 |
|
wsmoak joined #evergreen |
| 16:00 |
Bmagic |
dbwells: Im sorry, I'm not seeing that script. Do I need to checkout a branch? (Im on master) |
| 16:02 |
jeff |
Bmagic: what are you looking for? |
| 16:03 |
jeff |
(it's not obvious from recent scrollback here) |
| 16:03 |
|
Guest59358 joined #evergreen |
| 16:03 |
Bmagic |
Guest59358: it was the 2.11 pg upgrade script |
| 16:07 |
* bshum |
assumes that any 2.11 version upgrade script would not be in master (yet) |
| 16:07 |
bshum |
Since 2.11.0 isn't a real thing yet |
| 16:08 |
bshum |
So it's probably only in the tarball or maybe if there's any tag version branch that's been pushed |
| 16:08 |
dbwells |
yes, it is only in tarballs right now, though I should push the build branches, too |
| 16:13 |
|
maryj joined #evergreen |
| 16:31 |
|
StomproJ joined #evergreen |
| 16:34 |
miker |
Bmagic / jeff_ / others: have a moment to care about the recent sipserver change re location code as workstation name? |
| 16:35 |
Bmagic |
miker: sure |
| 16:35 |
miker |
well, lemme dig up the bug... |
| 16:36 |
miker |
https://bugs.launchpad.net/sipserver/+bug/1579144 |
| 16:36 |
pinesol_green |
Launchpad bug 1579144 in SIPServer "Send Location field to ILS driver at Login" [Wishlist,New] |
| 16:37 |
Bmagic |
The issue is - all of the production sip clients need to have a configuration change to include the workstation name in the CP field |
| 16:37 |
miker |
Bmagic: ah, but just a sec... |
| 16:38 |
miker |
Bmagic: if you look at my branch in comment 4 (just now pushed an update) you'll see that I'd like to allow you to override that on the server side |
| 16:39 |
Bmagic |
and SIP errors out when the CP field is specified for institution (like what we do) and doesn't match a workstation name. I was hoping the code could be patched to accept a CP field that doesnt match a workstation |
| 16:39 |
miker |
and, with that last commit, you can decide per <institution> whether the client or the server takes precedence ... so, you can override with the "correct" value on the server side |
| 16:39 |
* Guest59358 |
reads |
| 16:39 |
Guest59358 |
grr. |
| 16:40 |
miker |
right, I'm saying I'm giving you the ability to overturn that |
| 16:40 |
Bmagic |
so the server wont give up as soon as it queries the database for the workstation name and comes up with bupkis? |
| 16:40 |
miker |
in the config file you can say "here's the workstation for this account" /and/ "use the server's workstation value, no the clients" |
| 16:40 |
miker |
it won't have bupkis, it'll have a real workstation value |
| 16:41 |
miker |
you won't have to reconfigure the clients |
| 16:41 |
miker |
just add workstations and adjust the sip server config |
| 16:41 |
Bmagic |
I see, the presence of the workstation in SIPconfig.xml will replace the CP field |
| 16:41 |
miker |
the difference that my second commit makes is that it allows you to say "ignore the client's CP field, use this value from the config file" |
| 16:42 |
miker |
well, it will if you do /not/ set client_location_code="true" for your institution(s) |
| 16:42 |
miker |
which gives you the ability to migrate clients over time |
| 16:43 |
Bmagic |
that should work, I will have to setup a test |
| 16:43 |
miker |
by moving their account entries from one institution to another, with differing settings |
| 16:44 |
miker |
please do! I'd like this to get into sipserver before 2.11 goes GA if possible, so sipserver master can be configured (at least) to not break any existing releases |
| 16:45 |
jeff |
i may propose an alternate branch if i can get my thoughts together. |
| 16:45 |
jeff |
i'd like the upgrade to be less painful and not require a bunch of workstations be created to preserve what was working before the upgrade. |
| 16:46 |
jeff |
but some of my not-together thoughts might be wrong. |
| 16:47 |
Bmagic |
yeah, I have the same feeling about that |
| 16:47 |
Bmagic |
post upgrade, all of the accounts will need attention |
| 16:48 |
Bmagic |
it would be great that the absence of a workstation (from CP or from xml) wont break |
| 16:49 |
Bmagic |
or rather, even the presence of a CP field that doesnt connect to a workstation in the database, wont break it |
| 16:50 |
jeff |
miker++ thanks for giving this attention |
| 16:50 |
Bmagic |
miker++ |
| 16:50 |
miker |
well, we could make "client_location_code" be a hard switch on whether to use it |
| 16:50 |
miker |
I can get behind that |
| 16:51 |
miker |
meanwhile, always allow (but don't require) the config file t specify a workstation |
| 16:51 |
Bmagic |
Can the code simply ignore non-matching workstations and move on with life producing a warning in the logs? |
| 16:51 |
miker |
only question then is which to choose when both are present |
| 16:51 |
jeff |
Bmagic: i think it would at minimum cause an initial login failure before re-trying without ws. |
| 16:51 |
miker |
Bmagic: on the evergreen side, no |
| 16:52 |
miker |
and it complicates things a good bit, IMO |
| 16:52 |
Bmagic |
thats too bad |
| 16:53 |
Bmagic |
then the hard switch would be an improvement |
| 16:54 |
miker |
well, consider it: a workstation is part of an authorization credential set. should a 2-factor auth system ignore one of the auth factors? |
| 16:54 |
miker |
because, the WS is essentially a contract between the client and server that the client is acting on behalf of a specific physical location, one that can only be registered by someone with elevated privs |
| 16:54 |
jeff |
i haven't seen many two factor auth systems where the two factor is optional, as is the case here. |
| 16:55 |
Dyrcona |
jeff: I don't this really qualifies as two-factor authentication. |
| 16:55 |
miker |
it doesn't |
| 16:55 |
jeff |
Dyrcona: that was kinda' my point. :-) |
| 16:56 |
miker |
but it's an analog, because it grants permissions to the client in the context of the WS |
| 16:58 |
|
mmorgan joined #evergreen |
| 16:59 |
miker |
design reasoning aside, though, I think we can get what Bmagic wants (ignore client WS), /and/ allow client-supplied WS where it's correctly configured, and not require a ton of extra work |
| 17:00 |
miker |
my main question is, in the case where there would be a choice between two values (client-supplied and config file), should precedence be configurable, and if not, which should win? but that can be a followup commit, I think |
| 17:01 |
Bmagic |
server wins - libraries are trying funny business and gain access to something they shouldnt |
| 17:02 |
Bmagic |
Im joking btw |
| 17:03 |
miker |
Bmagic: that's a perfectly valid stance, IMNSHO ;) |
| 17:03 |
Dyrcona |
Yes. I would tend to agree with server wins. |
| 17:04 |
miker |
anyway, I pushed one more commit that changes the institution policy setting "client_location_code" so that, unless that is set to "true", you get the old behavior (plus the ability to set the value in the config file) |
| 17:04 |
Bmagic |
if a username/password is presented on the xml and from the client, who wins? |
| 17:04 |
miker |
Bmagic: so, if you feel like testing, please try the tip of http://git.evergreen-ils.org/?p=working/SIPServer.git;a=shortlog;h=refs/heads/user/miker/lp1579144_login_location |
| 17:07 |
miker |
Bmagic: for an <account> you mean? the xml is considered authoritative. if they don't match (or the login fails at the ILS) then login fails... so, I guess the ILS is most authoritative, but between XML and client, XML wins. is that what you mean? |
| 17:07 |
Bmagic |
yeah, another joke |
| 17:07 |
Bmagic |
the xml has the username/password/workstation supplied and the sip client has the same. who wins on each one..... |
| 17:09 |
* Dyrcona |
calls it a day. |
| 17:10 |
Bmagic |
miker: <supports> section deprecated? |
| 17:11 |
Bmagic |
also <option name='msg64_summary_datatype' value='barcode' /> ? |
| 17:11 |
miker |
no, it's in use for message types, mag-media |
| 17:12 |
Bmagic |
my config is implementation="OpenILS::SIP" will that work? |
| 17:14 |
|
mmorgan left #evergreen |
| 17:14 |
miker |
policy is outside the implemtation config |
| 17:14 |
miker |
implementation |
| 17:15 |
miker |
we could certainly look deeper into the config data structure, but at the point where we're using CP (in this context) we haven't even loaded the ILS driver yet |
| 17:15 |
miker |
so, we can't use the $ILS->supports() helper method yet |
| 17:19 |
Bmagic |
ok great |
| 17:19 |
miker |
IOW, this is part of "how do we load the driver for this institution" |
| 17:24 |
miker |
Bmagic: I'm wedded to the specifics in the branch, it just seems like the simplest code change to get what I think you want (no client workstation, as before). it adds the option of a server supplied value, but that can be ignored if you never set one in the config file. if another branch appears that doesn't regress functionality and folks like it more, I'll commit that instead ... but I'd like to move the ball down the field one way or another |
| 17:24 |
miker |
before 2.11 |
| 17:24 |
miker |
gah... I'm /NOT/ wedded ;) |
| 17:26 |
* miker |
commutes |
| 17:26 |
Bmagic |
miker: I'm glad jeff and I could officiate the wedding ceromony |
| 17:26 |
miker |
:) |
| 17:26 |
Bmagic |
ceremony* |
| 17:27 |
* miker |
finally catches on of the jokes ;) |
| 17:28 |
berick |
git commit --annul |
| 17:28 |
|
rlefaive joined #evergreen |
| 17:28 |
miker |
git blame --annui ?? |
| 17:29 |
* miker |
really runs away |
| 17:30 |
Bmagic |
lol |
| 17:53 |
Bmagic |
miker: I just tested the SIP server code - something is amiss (probably me) |
| 17:53 |
Bmagic |
LOGIN ERROR: 'Undefined subroutine &Sip::MsgType::to_bool called at Sip/MsgType.pm line 859. |
| 18:37 |
|
_adb left #evergreen |
| 19:17 |
miker |
Bmagic: no, it's me. I'll look at that as soon as I can and let you know. probably in the morning |
| 20:03 |
|
dcook joined #evergreen |
| 21:20 |
|
serflog joined #evergreen |
| 21:20 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 21:21 |
|
csharp joined #evergreen |
| 22:00 |
|
ssieb joined #evergreen |
