Time |
Nick |
Message |
03:44 |
|
abneiman joined #evergreen |
05:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
07:12 |
|
rjackson_isl joined #evergreen |
07:48 |
|
bos20k joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
08:55 |
|
yboston joined #evergreen |
09:00 |
|
Dyrcona joined #evergreen |
09:07 |
|
sandbergja joined #evergreen |
09:10 |
|
Dyrcona joined #evergreen |
09:55 |
|
stephengwills joined #evergreen |
09:56 |
|
sandbergja joined #evergreen |
10:02 |
|
mmorgan1 joined #evergreen |
10:16 |
|
Christineb joined #evergreen |
10:37 |
|
khuckins joined #evergreen |
10:38 |
Bmagic |
Anyone else seen an issue with overriding checkouts on webby? I've got a library claiming that the staff could override a checkout on xul when the patron had a circ penalty but not on webby |
10:40 |
Dyrcona |
Sounds like a permission issue at first blush. |
10:40 |
Bmagic |
I'm headed into diag mode on a test machine |
10:40 |
Dyrcona |
Could depend on the penalty, too. |
10:41 |
Bmagic |
the screen shot shows three: "PATRON_EXCEEDS_LONGOVERDUE_COUNT" "COPY_STATUS_LONG_OVERDUE" "COPY_NOT_AVAILABLE" |
10:42 |
Dyrcona |
Well, you'd have to be able to override all 3. |
10:42 |
Dyrcona |
XUL would only report the first one that failed, IIRC. |
10:42 |
Bmagic |
the screen shot is from xul with all three listed |
10:42 |
Dyrcona |
Is it? Guess I'm mistaken, then. |
10:43 |
Bmagic |
webby's screen shot is showing only one: "COPY_NOT_AVAILABLE" and no option to override |
10:43 |
Dyrcona |
Right, so they don't have that permission. They should check it in, first, then check it out. |
10:43 |
Bmagic |
the issue is it allows the override in xul though |
10:44 |
Dyrcona |
It shouldn't. The permission checks are done on the back end. |
10:44 |
Dyrcona |
At least, they all *should* be, and if they're not, that's a bug. |
10:45 |
Dyrcona |
They way it typically works, is the client says do this checkout. The back end says sorry, these events occurred. |
10:45 |
Dyrcona |
Client says override these events.... |
10:45 |
Dyrcona |
And, I'll bet that COPY_NOT_AVAILABLE isn't listed as overridable in the web staff client. |
10:46 |
Dyrcona |
Eh, no. It is in the list. |
10:46 |
Dyrcona |
At least in 3.2.4. |
10:47 |
Dyrcona |
The other two are not listed. |
10:47 |
Dyrcona |
So, there's your bug. |
10:48 |
Bmagic |
oh? |
10:48 |
Dyrcona |
longoverdue-- # Too much confusion as to what it's for. |
10:48 |
Dyrcona |
Yeah, the clients have lists of overridable events. If some other event occurs, it won't offer to override. |
10:49 |
Bmagic |
XUL had it listed in the client side (XUL Client JS somewhere) ? |
10:49 |
Dyrcona |
Yes. |
10:49 |
Bmagic |
I see |
10:50 |
Dyrcona |
Interestingly enough, those two events aren't in XUL, either. |
10:51 |
Bmagic |
https://bugs.launchpad.net/evergreen?field.searchtext=COPY_NOT_AVAILABLE&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.omit_dupes=on |
10:51 |
Bmagic |
launchpad_search-- |
10:52 |
Dyrcona |
Bmagic: XUL has an extra entry that the web staff client lacks: null /* custom event */, |
10:52 |
Bmagic |
alright - making a new bug |
10:53 |
Dyrcona |
See: Open-ILS/xul/server/circ/checkout.js around line 654 |
10:54 |
Bmagic |
thank you! I was just greping for that |
10:54 |
Dyrcona |
Sorry, missed a path element.... Shoulda copied and pasted. |
10:54 |
Dyrcona |
Have you round it in the web client code? I can give you the file and line number there, too. |
10:54 |
Bmagic |
notchet |
10:55 |
Dyrcona |
I suspect that the null entry is allowing the override in XUL. |
10:55 |
Dyrcona |
OK Here's the correct path to the XUL file: ./Open-ILS/xul/staff_client/server/circ/checkout.js |
10:56 |
Bmagic |
I found that for shizzle |
10:56 |
Dyrcona |
The web client code is ./Open-ILS/web/js/ui/default/staff/circ/services/circ.js about line 52 in 3.2.4. Line number may vary in other branches. |
10:57 |
Bmagic |
I find it odd that we have to list those out like that |
10:58 |
Dyrcona |
It's the way the backend code works. You have to tell it what events you want to override. |
10:58 |
Dyrcona |
There's a .override version of the circulation methods and you can specify all events, but we don't want to use that in the normal client. |
10:58 |
Bmagic |
The step where the UI displays the required override events should give the client all of the information it needs to send back the request again but this time with the exact list of overrides from the previous attempt |
10:59 |
Dyrcona |
It would override everything that the staff can override without prompting them. There are likely more cases where you don't want to override everything all at once than when you do. |
11:00 |
Dyrcona |
The circulation code is complicated and much of it written long before I got here. It's easy to say it should do "X" today. |
11:00 |
Bmagic |
XUL says: 7004 /* COPY_NOT_AVAILABLE */ and it looks like Webby does too: service.checkout_overridable_events = .... 'COPY_NOT_AVAILABLE' .... |
11:01 |
Dyrcona |
Yeah, did you read what I said about that null event in XUL? It's not there in the web client. |
11:02 |
Dyrcona |
There may be something else going on apart from the list of overridable events. |
11:03 |
Bmagic |
I did read that but still trying to connect the dots. You're saying that the backend service "open-ils.circ.checkout.full" takes arguments, one of which if null - causes some magic for overrides? |
11:06 |
Dyrcona |
From what I can see, it looks like XUL adds the events returned by the backed to the list of overridable events. I can't see where the web staff client doe sthat. |
11:11 |
Dyrcona |
typos-- |
11:12 |
Bmagic |
I'm looking at it too :) |
11:15 |
Dyrcona |
Looks like service.overrid_dialog at line 754 might do it. |
11:16 |
Dyrcona |
service.override_dialog.... |
11:16 |
Bmagic |
I logged in with global admin, still can't override the checkout. But in my test scenario, the alert box is complaining about "PATRON_EXCEEDS_LONGOVERDUE_COUNT" |
11:16 |
Dyrcona |
Do you have an override permission for that event? |
11:17 |
Dyrcona |
I mean, is it even in the permission table? |
11:17 |
Bmagic |
global admin has EVERYTHING at consortium |
11:17 |
Dyrcona |
Right, but not if the perm doesn't exist. :) |
11:17 |
Bmagic |
let me take a look at the table real quick |
11:17 |
Bmagic |
select * from permission.perm_list where code~'PATRON_EXCEEDS_LONGOVERDUE_COUNT' |
11:18 |
Bmagic |
One row: "PATRON_EXCEEDS_LONGOVERDUE_COUNT.override" |
11:18 |
Dyrcona |
Though, perm checks were supposed to look for EVERYTHING, and then check for individual perms, but maybe some were missed. |
11:18 |
Dyrcona |
Well, there you go. |
11:19 |
Dyrcona |
It could just be throwing an event at you at random, too. It may be some other event that's actually failing. |
11:19 |
Dyrcona |
You'll have to check the logs on the server for that, probably. |
11:20 |
Bmagic |
ok, I added that permission to my test user |
11:20 |
Bmagic |
(even though it has EVERYTHING) |
11:21 |
Bmagic |
still can't override the error - you think it's because the permission (minus .override) doesn't exist in the perm table? |
11:22 |
Dyrcona |
You said it does exist in the perm table. |
11:22 |
Bmagic |
it doesn't but the .override does |
11:22 |
Dyrcona |
I think it could be some other event, and you're just seeing the first one in the list of all of them. |
11:23 |
Bmagic |
ok, checking logs |
11:23 |
Dyrcona |
To answer your question: No. the .override is the only permission that should exist. |
11:24 |
Bmagic |
circulator: pushing event PATRON_EXCEEDS_LONGOVERDUE_COUNT |
11:24 |
Dyrcona |
Yeah, that's the event, and the permission should be the event textcode + 'override' |
11:25 |
Dyrcona |
.override. I should just give up on the day... I can't type. |
11:26 |
Bmagic |
sall good, don't beat youslf up, I can ttype eher |
11:27 |
Dyrcona |
Normally, I can. I think I'm dehydrated, 'cause I'm suffering an ocular migraine or something. One eye doesn't want to focus. |
11:27 |
Dyrcona |
Well, it's almost lunch time. That should help. |
11:28 |
Bmagic |
so it seems that if the web client explicitly listed PATRON_EXCEEDS_LONGOVERDUE_COUNT in the javascript - it would override it and it would be fine? |
11:28 |
Dyrcona |
Yeah, probably. |
11:29 |
Dyrcona |
Try it on a test system and see what happens. |
11:29 |
Bmagic |
Yep, just did |
11:29 |
Bmagic |
now I get a different alert dialog box offering me to "Force Action?" |
11:30 |
Bmagic |
So it seems that took care of it, HOWEVER, the XUL client got through this without having to list that permission explicitly |
11:31 |
Dyrcona |
XUL added the events that came back from the checkout attempt to the overridable events list around line 745 of checkout.js. |
11:31 |
Bmagic |
and the null value for the fourth argument did that magic |
11:31 |
Dyrcona |
I don't see where the web client does this. |
11:32 |
Bmagic |
aha, I see |
11:32 |
Dyrcona |
I don't understand: You added null or set the list to null and it worked? |
11:33 |
Bmagic |
so it does "react" and generates a new list based on the server. So what's the point of making a list in the first place I wonder? |
11:34 |
Bmagic |
Dyrcona: I explicitly added " PATRON_EXCEEDS_LONGOVERDUE_COUNT" to the array in circ.js |
11:34 |
Dyrcona |
I've never questioned it much. It has pretty much always worked that way. |
11:34 |
Bmagic |
line 54 |
11:34 |
Dyrcona |
OK. |
11:35 |
Dyrcona |
I was wondering about your comment about null, but I see it was likely related to what I said earlier. |
11:35 |
Dyrcona |
Maybe the web client will make more sense when the transition to Angular 7 is complete.--One can certainly hope. :) |
11:36 |
Bmagic |
The behavior is different from xul, so that's a bug. The solution isn't clear though |
11:36 |
Dyrcona |
I think the handle_override function should probably add he events from the response to the existing list, or maybe the checkout promise should. I"m not really sure where it should go, tbh. |
11:37 |
Bmagic |
thanks, no need to continue hammering on this right now |
11:37 |
Bmagic |
I feel like we have a conclusion of sorts |
11:45 |
Bmagic |
Dyrcona: bug 1827901 |
11:45 |
pinesol |
Launchpad bug 1827901 in Evergreen "Webby: Cannot override PATRON_EXCEEDS_LONGOVERDUE_COUNT" [Undecided,New] https://launchpad.net/bugs/1827901 |
11:46 |
* Dyrcona |
doesn't like it when people call the web client "webby." My understanding is that was one particular server's name, but whatevs.... I guess I have to deal with it. |
11:50 |
Bmagic |
It's a name that seems to have stuck. I don't like it either |
11:50 |
Bmagic |
I've used "Web based staff client" but that makes the name of the bug much longer with no gain in understanding of what we are talking about |
11:51 |
Dyrcona |
Well, soon, it will be just the staff client. |
11:54 |
Bmagic |
I agree - in this case, for this bug, it was an illistration of the difference between the two clients so I felt I needed to mention which* client. Otherwise I wouldn't have specified |
12:03 |
|
mmorgan joined #evergreen |
12:08 |
|
aabbee joined #evergreen |
12:15 |
|
jihpringle joined #evergreen |
12:18 |
|
sandbergja joined #evergreen |
12:20 |
|
Stareagle joined #evergreen |
12:24 |
Stareagle |
Is it best to use the webchat client for IRC or should I use a dedicate client. Or does it not really matter. |
12:25 |
bshum |
Stareagle: It doesn't really matter to IRC or the world. The main reason to use a dedicated client might be if you wanted to review what was said in your own logs on your client |
12:26 |
bshum |
Or like in my case being able to stay logged on 24/7 from somewhere |
12:26 |
bshum |
Otherwise, using a web client for IRC isn't bad |
12:26 |
bshum |
You can still register your nickname and identify to the services even from a web client |
12:26 |
bshum |
So it's mostly personal preference |
12:27 |
bshum |
Maybe some prettier colors if you personalize your client |
12:27 |
bshum |
Depending on the client |
12:27 |
Stareagle |
Ok wasnt sure if there were any special features with a client. I seem to got on OK with the webclient anyway. |
12:44 |
bshum |
Stareagle: I could see a client having better notification integration than a web browser |
12:45 |
bshum |
Like if someone messaged you, it might be harder to notice the blinking tab among all my other browser tabs |
12:45 |
bshum |
vs. getting a popup on my system console from Win/Mac/whatever where the client is installed |
12:46 |
bshum |
But yeah |
12:46 |
bshum |
It's not really all that different :) |
12:48 |
Stareagle |
bshum: I know what you mean about the flashing tab, I only have four open and missed it... :-) Is there a client you could recommend for mac/windows? |
12:49 |
Dyrcona |
A lot of people here use Quassel because you can run a server that keeps you connected all the time and you see the logs, etc., regardless of the device where you run the client. |
12:50 |
Dyrcona |
I use Pidgin, and I used to use Psi, because both do multiple chat protocols, though I pretty much only do IRC these days. |
12:51 |
bshum |
Yeah I used to use Pidgin too on Windows (or Adium for Mac) because I used it for more chat types than just IRC (I had a bunch of XMPP chats) |
12:51 |
bshum |
But yeah I've been using Quassel too cause of the centralized server core option |
12:52 |
bshum |
It's possible to install Quasselcore locally and then use the Quassel client to connect to your local core without a server |
12:53 |
Dyrcona |
Well, yeah. Maybe I should have mentioned that. I just consider the server to be the #1 reason to use Quassel. |
12:53 |
bshum |
It is pretty nice to have in my book |
12:54 |
bshum |
For mac, I think I used to use stuff like Colloquy (but I don't know how well supported that is anymore) |
12:55 |
bshum |
Quassel is at least mostly the same across Windows or Mac |
12:55 |
bshum |
Since it's a QT client |
12:57 |
Dyrcona |
I used Colloquy on the Mac for a while, even had a XSL to convert the logs for some purpose. |
12:58 |
Dyrcona |
Pidgin is GTK. Psi is Qt. |
13:07 |
Stareagle |
bshum: Dyrcona: Thanks I'll try your suggestions. Confused a bit about the server option though. I thought I was connecting to the server #evergreen? The answer is probably going to be simple... |
13:07 |
Stareagle |
It is Monday though :-) |
13:08 |
bshum |
Stareagle: So quassel has a centralized "server" core part, where you setup your IRC connections, chats, etc. |
13:09 |
bshum |
And you connect to that server using one of many Quassel clients (which can be installed/run on different OS) |
13:09 |
bshum |
That server core is what has the connections made out to the IRC servers (which are different servers too) |
13:10 |
bshum |
This diagram from their docs page might help illustrate: https://bugs.quassel-irc.org/projects/quassel-irc/wiki |
13:10 |
bshum |
But basically, the "server" core for Quassel is how you're connected to the IRC |
13:10 |
bshum |
And then you connect to that server core using the Quassel clients |
13:11 |
bshum |
But it can all be on the same box or separated apart |
13:11 |
bshum |
In my case for instance, I run a Linux server in the cloud that has my Quassel server core on it. And then I connect to that server core using the quassel client on my Macbook or my phone or my other computers |
13:11 |
bshum |
That way I get the same content on any of my devices |
13:12 |
bshum |
*content/experience |
13:12 |
bshum |
If I were to run separate Quassel server/clients on each machine |
13:12 |
bshum |
I might see differences in my logs for each box |
13:12 |
bshum |
Cause whichever was connected would only get info for that time |
13:13 |
bshum |
The distributed design of server/client allows more flexibility in how I experience IRC :) |
13:14 |
bshum |
I've known people who have used Quassel all-in-one though, and it worked fine for their use case of checking IRC from their single laptop, whatnot |
13:15 |
Stareagle |
Ah so the quassel core is like an intermediary? |
13:15 |
bshum |
Right |
13:16 |
Stareagle |
OK now to see if my cloud hosters will let me install the server. |
13:49 |
|
mmorgan1 joined #evergreen |
13:51 |
|
bos20k joined #evergreen |
14:09 |
|
sandbergja_ joined #evergreen |
14:20 |
|
khuckins joined #evergreen |
15:19 |
|
RBecker joined #evergreen |
15:31 |
|
bos20k_ joined #evergreen |
15:33 |
|
Christineb_ joined #evergreen |
15:34 |
|
troy___ joined #evergreen |
15:39 |
|
RBecker_ joined #evergreen |
15:42 |
csharp |
if someone with /topic powers can add the planned web server migration (see my email just now) to the topic, that would be great |
15:42 |
* csharp |
sips coffee cup |
15:43 |
csharp |
hmm - does pinesol grant +v powers in the channel? |
15:43 |
csharp |
that will definitely be affected if so |
15:44 |
csharp |
no - I guess that's ChanServ, not pinesol |
15:44 |
csharp |
@monologue |
15:44 |
pinesol |
csharp: Your current monologue is at least 6 lines long. |
15:54 |
Dyrcona |
That is chanserv, and I'd be surprised if you don't have topic powers, csharp. |
15:56 |
bshum |
He doesn't actually |
15:56 |
csharp |
that's fine |
15:56 |
bshum |
Looks like it's only dbs, jeff, berick, phasefx, and me |
15:57 |
bshum |
Maybe me hmm |
15:57 |
bshum |
I'll have to look at it more closely later if someone else doesn't get there first |
16:12 |
|
mmorgan joined #evergreen |
16:45 |
gmcharlt |
berick: FYI re something we discussed at the conference: https://bugs.launchpad.net/evergreen/+bug/1827943 |
16:45 |
pinesol |
Launchpad bug 1827943 in Evergreen "angular: a string of edit modals would benefit from additional controls" [Wishlist,New] |
17:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
17:09 |
|
jweston_ joined #evergreen |
17:11 |
|
mmorgan left #evergreen |
17:17 |
|
jweston_ joined #evergreen |
17:17 |
jamesrf |
hi! i am really sorry I think I broke/crashed demo.evergreencatalog.com |
17:23 |
Bmagic |
jamesrf: it's working for me |
17:25 |
Bmagic |
but I cannot login, so it might be busted on the server side. Console says it's connecting at port 7682 |
17:25 |
Bmagic |
server response 101 |
17:26 |
Bmagic |
jamesrf: if you still need a machine to play with: https://bugsquash.missourievergreen.org/eg/staff |
17:26 |
Bmagic |
admin/demo123 |
21:11 |
|
sandbergja joined #evergreen |
22:24 |
|
awitter joined #evergreen |
22:48 |
|
sandbergja joined #evergreen |
23:58 |
|
sandbergja joined #evergreen |