| Time |
Nick |
Message |
| 01:09 |
|
jboyer_isl joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:39 |
|
jboyer-isl joined #evergreen |
| 08:03 |
|
rlefaive joined #evergreen |
| 08:09 |
|
ericar joined #evergreen |
| 08:10 |
|
mrpeters joined #evergreen |
| 08:12 |
|
rjackson_isl joined #evergreen |
| 08:42 |
|
Dyrcona joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 08:55 |
csharp |
I did a search yesterday morning and got a result set that excluded e-resources that had "transcendant" [sic] set to "false". After setting "transcendant" to "true", I did the same search and got the same result set that excluded those records. This morning, the search now includes those records. Am I correct in assuming that this is search caching at play? |
| 08:56 |
csharp |
s/e-resources that/e-resources with a bib_source that/ |
| 09:01 |
jeff |
seems reasonable that it was search caching. |
| 09:02 |
jeff |
though at first i thought you were going to describe a weird behavior when you have located URIs on a bib with a transcendent source. |
| 09:03 |
jeff |
(I don't think there is any such weird behavior) |
| 09:05 |
csharp |
yeah, this is just a "our results aren't visible when we were expecting them to be visible" issue that apparently comes from a misunderstanding about what "transcendant" does |
| 09:07 |
csharp |
unfortunately, several-years-old cataloging procedures for e-resources are based on the misunderstanding, so there's a lot of emotion around the issue :-/ |
| 09:12 |
jeff |
ah. |
| 09:25 |
tsbere |
csharp: I tend to add things like "-boaufaouhad" to searches when I made changes and want to see them. |
| 09:26 |
csharp |
tsbere: ah - good idea |
| 09:28 |
bshum |
Hmm, so a staff member says that every once in awhile, they type in the barcode of a patron to the place hold in the catalog via the staff client, and the submit button doesn't like light up. |
| 09:28 |
bshum |
Subsequent restarting the client, things are fine. |
| 09:28 |
bshum |
Sounds like a timeout issue maybe? |
| 09:29 |
bshum |
Like their client was either a) no longer connected or b) expired creds? |
| 09:30 |
tsbere |
bshum: I could see b, but not a. Due to the fact that the client doesn't maintain a constant connection. Unless by "no longer connected" you mean "to the internet"... |
| 09:30 |
bshum |
Right, network being internet. |
| 09:31 |
mmorgan |
bshum: We had similar questions after a release (not sure which one off the top of my head) changed the behavior of the hold submit form. The cursor has to leave the barcode box in order for the hold prefernces to fill in and the submit button to light up. |
| 09:31 |
bshum |
mmorgan: yeah, they say that hitting tab or clicking out of the box still has no effect. |
| 09:31 |
mmorgan |
Interesting. |
| 09:32 |
bshum |
So that's why I'm leaning towards some sort of expired session or otherwise disconnected state. |
| 09:32 |
bshum |
This library does use windows roaming profiles |
| 09:33 |
bshum |
And shares Evergreen profiles for workstations |
| 09:33 |
bshum |
So maybe logging in one place, screws up another place |
| 09:33 |
csharp |
bshum: if restarting the client fixes the issue, you might want to consider high RAM usage too? Does this library also complain about random freezes? |
| 09:34 |
bshum |
csharp: I can check on RAM. We haven't talked memory issues in ages though at Biblio. |
| 09:34 |
csharp |
bshum: bully for you! it seems to only come up in summer in PINES |
| 09:34 |
bshum |
And this particular library restarts clients during shift changes during the memory leak era |
| 09:35 |
csharp |
got it |
| 09:35 |
bshum |
But we've moved past that stage eons ago it seems :D |
| 09:35 |
csharp |
it's the libraries who either 1) refuse to do that for some reason or 2) don't do it consistently who complain |
| 09:36 |
bshum |
I'll ask anyways. Never hurts to leave no stone unturned. |
| 09:36 |
csharp |
"the staff client *shouldn't* have this problem, therefore we shouldn't have to do anything to work around it" |
| 09:37 |
tsbere |
bshum: I know that at least once I found that someone had here found a way to get a "logout" button in the opac and clicked on it....in the client....invalidating their session. :( |
| 09:38 |
tsbere |
bshum: Beyond that, you may want to check if your memcache is unusually full (and thus potentially removing login sessions to make space) |
| 09:38 |
bshum |
tsbere: if it was a full memcache I would think more issues would be reported |
| 09:39 |
|
yboston joined #evergreen |
| 09:40 |
tsbere |
bshum: Also, if they were in a specific opac tab for a long time the *client* may have thought the token expired despite the *server* being kept up by the tpac hits to the token |
| 09:40 |
bshum |
tsbere: That sounds... not good. |
| 09:41 |
* tsbere |
would think loading records would make that a non-issue, but if all that was done was searches without loading specific records... |
| 09:44 |
tsbere |
Hmmm. |
| 09:44 |
tsbere |
bshum: I assume you are running a version that does not have the "you left the opac open in another tab, so it eventually refreshed to log you out" issue for the staff client |
| 09:44 |
jeff |
there is of course also bug 1036318 -- which might still be present in local templates. |
| 09:44 |
pinesol_green |
Launchpad bug 1036318 in Evergreen 2.4 "OPAC timeout within the client" [Medium,Fix released] https://launchpad.net/bugs/1036318 |
| 09:45 |
jeff |
which is what tsbere just referred to -- heh |
| 09:46 |
jeff |
bshum: we had reports of that kind of thing at a desk where Change Operator was often used. |
| 09:47 |
* jeff |
used git-log to find that bug, since he wasn't finding it in launchpad search |
| 09:47 |
jeff |
and... bugfix commit is >2y old. time flies. |
| 09:58 |
bshum |
jeff: Well, we don't have any local templates |
| 09:59 |
bshum |
Since we modify the main files directly in our own git branches prior to deployment. But I can check to make sure that no customizations affected it. |
| 09:59 |
bshum |
Seems unlikely to be a bug for us though |
| 10:00 |
bshum |
jeff: Change operator though... that's highly possible |
| 10:00 |
bshum |
Cause the staff member who reported it, said they were using an acq login and also circ/cat logins to try things out |
| 10:01 |
bshum |
So they may have been using the change operator to perform the switches between user types |
| 10:02 |
jeff |
I'd also be interested to know the path taken to get to placing the hold. |
| 10:02 |
jeff |
especially if it was something other than a catalog search followed by placing a hold. |
| 10:03 |
jeff |
flight recorders. |
| 10:17 |
Dyrcona |
They make those: event loggers. |
| 10:19 |
jeff |
screen recording software exists for software testing and usability studies. i've often wanted to install at package and either enable it on machines that are having difficult-to-reproduce issues or have them recording semi-constantly with a X minute cyclical buffer. |
| 10:33 |
Dyrcona |
Event loggers are more fun: mouse_down btn 1 coords: 865, 124 and you get figure out what they clicked on. |
| 10:36 |
|
Shae joined #evergreen |
| 10:39 |
|
mmorgan1 joined #evergreen |
| 10:46 |
|
mrpeters1 joined #evergreen |
| 10:59 |
|
vlewis joined #evergreen |
| 10:59 |
Dyrcona |
Whee! Fun with closed days. |
| 10:59 |
Dyrcona |
We have Christmas of 2000 and beyond in our closed days table. Must have been migrated. |
| 11:01 |
* Dyrcona |
wonders if we should not just delete everything before 2014, except the one whose end date is "infinity." |
| 11:01 |
Dyrcona |
"Too infinity and beyond!" |
| 11:01 |
Dyrcona |
Grr. Can't lleps this morning.... |
| 11:05 |
|
mmorgan1 left #evergreen |
| 11:11 |
|
mmorgan joined #evergreen |
| 11:16 |
|
mrpeters joined #evergreen |
| 11:22 |
* Dyrcona |
fires up the dev client to see what happens when you check something out at a library that is closed to infinity.... |
| 11:30 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "This happens." (6 lines) at http://paste.evergreen-ils.org/10 |
| 11:30 |
Dyrcona |
As I expected. I think tsbere should have bet lunch on the outcome. ;) |
| 11:35 |
|
bmills joined #evergreen |
| 11:55 |
|
sandbergja joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:41 |
miker |
Dyrcona: did it time out, or just blow up quickly? asking for a friend... |
| 12:45 |
tsbere |
miker: I believe it blew up in the perl layer due to "infinity" not being a valid date/time format in the perl layer. |
| 12:46 |
tsbere |
how long that takes likely depends on how long it took to get to the infinity marked closed date. |
| 12:50 |
|
Christineb joined #evergreen |
| 12:58 |
Dyrcona |
miker: It blew up very quickly. |
| 12:58 |
Dyrcona |
I expected that behavior and don't necessarily think it is wrong. |
| 13:06 |
|
maryj joined #evergreen |
| 13:09 |
miker |
cool, thanks. |
| 13:16 |
|
rlefaive joined #evergreen |
| 14:11 |
dbs |
Any ideas on what permission is required to allow circ to blocked patrons? |
| 14:15 |
dbs |
Blocked by a penalty, that is. Now that we're using in-db rules |
| 14:18 |
|
sarabee joined #evergreen |
| 14:27 |
mmorgan |
dbs: Depends on the penalty. Here are a few: PATRON_EXCEEDS_FINES.override, PATRON_EXCEEDS_CHECKOUT_COUNT.override, PATRON_EXCEEDS_OVERDUE_COUNT.override |
| 14:27 |
mmorgan |
Then for staff placed penalies: STAFF_CHR.override, STAFF_CH.override, etc. |
| 14:29 |
dbs |
mmorgan: thanks! It turns out that the actual problem was that the staff member in question hadn't been assigned to the proper permissions group |
| 14:29 |
mmorgan |
That helps, too :) |
| 14:29 |
dbs |
So I was racking my brains looking at all the .override permissions, seeing they were in our "Super Circulators" permission group, and wondering what else it could be |
| 14:45 |
|
jihpringle joined #evergreen |
| 14:47 |
dbs |
mmorgan++ # belated, sorry! |
| 14:57 |
Bmagic |
anyone seen blank titles in SIP responses for patron hold lists? It seems to happen for holds that are "in-transit" |
| 15:00 |
tsbere |
Bmagic: I don't recall anyone claiming such a thing, but I don't think in-transit should be having that much of an effect... |
| 15:02 |
Bmagic |
tsbere: hmm, I wouldn't think so either. Something is going on, I have some samples that show clearly, our SIP server responds with blank titles |
| 15:02 |
tsbere |
Bmagic: Out of curiosity, does the staff client have any issues with the holds? |
| 15:02 |
|
jlitrell joined #evergreen |
| 15:02 |
Bmagic |
no, they show in the staff client fine |
| 15:03 |
tsbere |
Hmmm. Any odd characters in the titles? |
| 15:04 |
mmorgan |
Bmagic: are they vanilla hold_type T holds? Or are they V, C, or P holds? |
| 15:05 |
Bmagic |
regular T holds - no special characters |
| 15:05 |
tsbere |
mmorgan: Don't forget M! ;) |
| 15:05 |
Bmagic |
they just happen to be in transit |
| 15:05 |
tsbere |
Bmagic: Do the transits refer back to the hold you think they do? |
| 15:06 |
Bmagic |
I'm double checking |
| 15:07 |
Bmagic |
it looks like in this case, the hold is P |
| 15:07 |
tsbere |
Bmagic: Does the part still exist? |
| 15:07 |
|
lualaba joined #evergreen |
| 15:07 |
Bmagic |
yes |
| 15:08 |
Bmagic |
it might be that bug where you move an item with parts, and it leaves the part on the old bib, and doesnt create one on the new bib |
| 15:08 |
* tsbere |
takes a quick look at some code |
| 15:08 |
tsbere |
Bmagic: Does the hold have a current_copy at the moment? |
| 15:08 |
lualaba |
Hello only admin able to login in staffclient 2.8.1 for all other roles there are permission VIEW_BILL_TYPE, i change several parameters (add, remove permissionc, change depth, but nothing) please suggest me what is reason? |
| 15:09 |
tsbere |
lualaba: Did you assign work OUs to any new users? |
| 15:09 |
lualaba |
yes assign |
| 15:10 |
Bmagic |
tsbere: yes |
| 15:11 |
tsbere |
Bmagic: Having a current_copy should bypass what I am seeing here. :/ Not that I haven't found issues, mind you. |
| 15:11 |
lualaba |
select * from usr_work_ou_map; (there is a 53 assaigned of records) |
| 15:11 |
tsbere |
Bmagic: Then again, I might not be looking at the right function |
| 15:12 |
tsbere |
Bmagic: Ok, having done a quick once-over on the rest of the possible functions that may be involved I am going to go with "The SIP code doesn't know anything about Part holds" |
| 15:14 |
lualaba |
select * from grp_perm_map where perm = 175; also i see that grp(4) catalogers assign to permission 175(VIEW_BILL_TYPE) depth 2 (i try also 0,1) |
| 15:14 |
tsbere |
Bmagic: Can't find any reference to Issuance (serials) holds either. |
| 15:14 |
Bmagic |
tsbere: would that cause a blank title? |
| 15:14 |
tsbere |
Bmagic: Looks like it likely would, yes. |
| 15:19 |
Bmagic |
tsbere: yeah, I think I agree - another example I found - it's Part level holds that "happen" to be in transit |
| 15:21 |
Dyrcona |
The Joy of Waiting. |
| 15:21 |
lualaba |
but from web staff client i able to login with same user/pass |
| 15:22 |
mmorgan |
Bmagic: so is there no problem with Part level holds that aren't in transit? |
| 15:22 |
Bmagic |
no, I think there are, I just havent found an example |
| 15:24 |
mmorgan |
Bmagic: ok, makes more sense that it would be all P holds, not just the in transit ones. |
| 15:30 |
Bmagic |
tsbere: __hold_to_title is missing the "P" ? |
| 15:30 |
tsbere |
Bmagic: and "I" if you want to make things even more complete |
| 15:31 |
tsbere |
Bmagic: As are several other functions in there, for that matter. |
| 15:31 |
Bmagic |
ok - thanks for the help - I'll make a LP ticket |
| 15:35 |
lualaba |
FIXME: If you encounter this alert, please inform your IT/ILS helpdesk staff or your friendly Evergreen developers. Sat Dec 12 2015 00:34:28 GMT+0400 (Georgian Standard Time) The action involved likely failed due to insufficient permissions. However, this part of the software needs to be updated to better understand permission messages from the server, so please let us know about it. PERM_FAILURE Permission Denied |
| 15:35 |
lualaba |
I try everything but nothing was helped |
| 15:37 |
|
lualaba_ joined #evergreen |
| 15:48 |
jboyer-isl |
I don't know if I'm making things better or worse, but I'm trying ubuntu's wily kernels on my new machines to see if that knocks out their network issues. The first test is "does it survive sudo shutdown -r now ?" |
| 15:53 |
Bmagic |
jboyer-isl++ |
| 15:55 |
Bmagic |
lualaba_: how about "STAFF_LOGIN" ? |
| 15:57 |
jboyer-isl |
By Jove; so far so functional. |
| 15:57 |
jboyer-isl |
I wonder what other gremlins I've loosed on this machine, though. |
| 15:59 |
lualaba_ |
i just create new Group and add only one permission VIEW_BILLING_TYPE, same problem |
| 16:00 |
lualaba_ |
i am able to login only with admin |
| 16:03 |
|
rlefaive joined #evergreen |
| 16:05 |
|
lualaba joined #evergreen |
| 16:05 |
Dyrcona |
lualaba: You should use the standard staff groups for new accounts. |
| 16:05 |
lualaba |
i used catalogers (same problems0 |
| 16:06 |
lualaba |
FIXME: If you encounter this alert, please inform your IT/ILS helpdesk staff or your friendly Evergreen developers. Sat Dec 12 2015 01:06:33 GMT+0400 (Georgian Standard Time) The action involved likely failed due to insufficient permissions. However, this part of the software needs to be updated to better understand permission messages from the server, so please let us know about it. PERM_FAILURE Permission Denied |
| 16:07 |
lualaba |
Catalogers,circulators,my own group has same issues |
| 16:07 |
Dyrcona |
lualaba: What are you doing when that comes up? Are you trying to add bills or add billing types? |
| 16:07 |
lualaba |
i just need to open staff client (i don't use any kind of bills_=) |
| 16:08 |
Dyrcona |
lualaba: Is this a fresh installation of Evergreen or is it an upgrade to an existing one? |
| 16:08 |
jboyer-isl |
No joy re: ubuntu + wily. Looks like it's time to pick something off the "certified supported" list of distros. :( |
| 16:09 |
lualaba |
"ilsperm":"VIEW_BILLING_TYPE", "ilsevent":"5000", "pid":20517, "desc":"Permission Denied", "textcode":"PERM_FAILURE", "servertime":"Sat Dec 12 01:06:25 2015", "stacktrace":"/usr/local/share/perl/5.18.2/OpenILS/Utils/CStoreEditor.pm:605 /usr/local/share/perl/5.18.2/OpenILS/Application/Circ.pm:89 /usr/local/share/perl/5.18.2/OpenSRF/Application.pm:594", "ilspermloc":"1" |
| 16:09 |
lualaba |
fresh 2.8.1 strange that i have two machines and same issue |
| 16:10 |
Dyrcona |
lualaba: It could be that the account has the permission, but at the wrong depth. Have you made changes to the organizational units? |
| 16:10 |
lualaba |
however same users work on web client eg/staff/home/ |
| 16:10 |
lualaba |
yes i make changes, but nothing helps |
| 16:11 |
Dyrcona |
lualaba: The XUL staff client tries to download things when it logs in and the web staff client doesn't have ot. |
| 16:11 |
Dyrcona |
s/ot/to/ |
| 16:11 |
lualaba |
you thing rebuild DB and try again? |
| 16:12 |
Dyrcona |
lualaba: You could try that. A stock installation should just work. |
| 16:12 |
lualaba |
have any chance to disable permission or delete? |
| 16:12 |
lualaba |
2.9 release is stable? |
| 16:12 |
Dyrcona |
lualaba: I was going to suggest altering the depth that the view_billing_type permission is granted to existing groups as a test. |
| 16:12 |
jeff |
if the existing admin user works and newly created users do not work, it may be that the new users do not have a working location set. |
| 16:12 |
Dyrcona |
jeff++ could be that. |
| 16:13 |
Dyrcona |
I thought of the perm depth because the client appears to checking loc 1. |
| 16:14 |
lualaba |
select * from permission.grp_perm_map where perm = 175; 448 4 175 0 |
| 16:14 |
lualaba |
i set location for all users |
| 16:15 |
lualaba |
also i restart osrf_control, check with srfsh, everything is ok |
| 16:15 |
lualaba |
can i upgrade 2.8.1 to 2.9? |
| 16:16 |
lualaba |
may be version problem? |
| 16:17 |
Dyrcona |
lualaba: What do you mean by "set location for all users?" |
| 16:17 |
|
lualaba_ joined #evergreen |
| 16:18 |
lualaba_ |
I will try rebuild DB and try with fresh DATA |
| 16:18 |
Dyrcona |
lualaba_: To upgrade from 2.8.1 to 2.9.1, you first upgrade to 2.8.4, then to 2.9.0, and finally to 2.91. |
| 16:19 |
lualaba_ |
any documentation? |
| 16:20 |
Dyrcona |
The README and probably docs.evergreen-ils.org somewhere. |
| 16:21 |
lualaba_ |
Thank you |
| 16:26 |
|
maryj_ joined #evergreen |
| 16:39 |
|
bmills joined #evergreen |
| 16:40 |
Bmagic |
lualaba_: did you run autogen.sh ? |
| 16:40 |
Bmagic |
oh, they are gone |
| 16:40 |
Bmagic |
tsbere: https://bugs.launchpad.net/evergreen/+bug/1525394 |
| 16:40 |
pinesol_green |
Launchpad bug 1525394 in Evergreen "SIP patron part level holds respond blank" [Undecided,New] |
| 16:42 |
Dyrcona |
So many moving parts, it is easy to miss one. |
| 16:51 |
tsbere |
Bmagic: I have commented |
| 16:53 |
Bmagic |
tsbere: thanks - right on |
| 17:07 |
|
mmorgan left #evergreen |
| 17:11 |
|
lualaba joined #evergreen |
| 17:12 |
lualaba |
Hello Again. I rebuild DB. create Cons-Sys-brench and one cataloger user (profile id 4) but same error: "VIEW_BILLING_TYPE". depth is 1 system |
| 17:13 |
lualaba |
Work_ou is already set |
| 17:15 |
|
lualaba_ joined #evergreen |
| 18:51 |
|
bmills joined #evergreen |
| 20:23 |
|
bmills joined #evergreen |
