| Time |
Nick |
Message |
| 07:05 |
|
Christineb joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:51 |
|
Rogan joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:05 |
|
mmorgan1 joined #evergreen |
| 11:13 |
Dyrcona |
Figured out the multiple logins: different Chrome windows. Login to Evergreen in one window, then open a new Window and get to the login screen in your usual way. You are prompted to login again. If you do, two sessions with different authtokens. |
| 11:14 |
Dyrcona |
I'm going to leave them open and only use one to see what happens when the idle one logs out. I suspect it will invalidate all sessions in the browser. |
| 11:23 |
Dyrcona |
Didn't have to wait. If I logout of 1, the other is logged out, too. |
| 11:23 |
Dyrcona |
I verified in the logs that they have different authtokens. Bet if I check, one of those authtokens is still "active." |
| 11:23 |
|
beardicus joined #evergreen |
| 11:33 |
Dyrcona |
Yep, only 1 of the sessions was deleted in the back end. The other is still active. I may delete it from srfsh as a precaution. I wonder if this warrants a security bug? |
| 11:59 |
|
jihpringle joined #evergreen |
| 12:19 |
csharp_ |
I wonder if it's because of the way they bookmark it? |
| 12:20 |
csharp_ |
yeah, if I go to $DOMAIN/eg/staff/login it does appear to have removed my previous login |
| 12:21 |
csharp_ |
confirmed |
| 12:21 |
Dyrcona |
Yeah, the bookmark is to the login page. |
| 12:21 |
csharp_ |
so if they bookmark it with /eg/staff it should just use their existing session |
| 12:22 |
Dyrcona |
I'll try that myself. My bookmark is to the login page. |
| 12:23 |
Dyrcona |
csharp_++ That works! I'll let them know. |
| 12:23 |
csharp_ |
whooo! |
| 12:26 |
* Dyrcona |
updates my own bookmarks. |
| 12:27 |
Dyrcona |
That made more grammatical sense when it was "/me updates my own bookmarks." :) |
| 12:27 |
csharp_ |
@decide me update my bookmarks or I update my bookmarks |
| 12:27 |
pinesol |
csharp_: That's a tough one... |
| 12:30 |
Dyrcona |
huh. I only had the login page for my production bookmark. The others were going to /staff/. |
| 12:32 |
|
sandbergja joined #evergreen |
| 12:33 |
sandbergja |
heya, I will not be able to be at collaborative code review today or (likely) the rest of the month due to a family emergency. |
| 12:33 |
jeff |
sandbergja: sorry to hear that -- best wishes that everything goes as well as it can go! |
| 12:33 |
csharp_ |
+1 |
| 12:34 |
Dyrcona |
Sorry to hear that. |
| 12:34 |
sandbergja |
thank you jeff and csharp_ and Dyrcona! |
| 12:35 |
mmorgan |
sandbergja: Very sorry to hear that :-( |
| 12:36 |
jeff |
gut check: I'd like to revisit the idea/proposal that a hold "uncancel" should create a new hold request, not file off the dates on the canceled hold and re-use it. Does anyone here see an immediate problem with that? We can still populate the new request with some data from the old, and (configurably) re-use things like request_time, etc. |
| 12:38 |
mmorgan |
jeff: What's the advantage of a new request vs. recycling the old? |
| 12:39 |
jeff |
it better preserves history/stats. not perfectly, but better. |
| 12:43 |
mmorgan |
So you would count an un-cancelled request as a new request? |
| 12:49 |
jeff |
mmorgan: yes, though with some indication that it was a re-request/uncancel, either a bool or a column containing the hold that was being uncanceled. |
| 12:53 |
Dyrcona |
Well, it makes sense for some points of view. The previous hold was canceled, so it is logically a new hold. |
| 12:56 |
* mmorgan |
sees that HOLD_UNCANCELED is a hold_request_reset_reason, and we have ~650 resets with that reason since August. |
| 12:57 |
jeff |
i think the usual use case for uncanceling a hold is that the patron is working with a staff member, to re-request an item in a way that's more convenient than starting from scratch and that (configurably) gives the patron the same "place in line" when preserving the original request_time from the canceled hold. |
| 12:57 |
jeff |
but I'm curious if there are other workflows/reasons, or what folk's gut reaction to the idea was. |
| 12:58 |
jeff |
I'm sure I've mentioned it before. I should go look at the previous conversation also. I don't think I ever took it as far as proposing it in LaunchPad. |
| 12:59 |
mmorgan |
I don't think it's ever come up for us as an issue. Before reset reasons, there was no way to know how many holds were being uncancelled. I was a bit surprised to see that 650 number. |
| 16:48 |
pinesol |
News from commits: LP#2137020: fix quoting issue that can break certain in-query PCRUD permission checks <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b90878e2cc06f0493489c7883a8a8dead0911b4c> |
| 16:50 |
|
jihpringle joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol |
News from commits: LP#2133888 Angular Circ Boolean Hold Details Always Display False <http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=174b13781b4e3a6f7cef5b22a06963592f8dff77> |
| 18:37 |
|
jihpringle joined #evergreen |
