| Time |
Nick |
Message |
| 06:24 |
|
kmlussier joined #evergreen |
| 06:38 |
* kmlussier |
yawns |
| 06:38 |
kmlussier |
@coffee |
| 06:38 |
* pinesol_green |
brews and pours a cup of Kenya Kagongo Peaberry, and sends it sliding down the bar to kmlussier |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:15 |
|
Callender joined #evergreen |
| 07:17 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
agoben joined #evergreen |
| 07:42 |
|
krvmga joined #evergreen |
| 07:57 |
|
Dyrcona joined #evergreen |
| 08:00 |
Dyrcona |
csharp: Got your later. Looking at it, that makes sense because the time is being stripped by that replace. |
| 08:06 |
|
krvmga joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:51 |
|
bos20k joined #evergreen |
| 08:55 |
|
graced joined #evergreen |
| 09:28 |
|
maryj joined #evergreen |
| 09:41 |
pinesol_green |
[evergreen|Dan Wells] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8284edc> |
| 10:31 |
|
kmlussier joined #evergreen |
| 11:09 |
kmlussier |
gmcharlt: I was looking at the community demo server page. It probably would be a good idea to put a 2.11 demo on there. It looks like we added 2.10 during RC. Since I don't have the web client running on my servers, I was wondering if ESI would be willing to host the 2.11 demo. |
| 11:21 |
miker |
kmlussier: we are, and can. and will ... we can work on that next week |
| 11:21 |
kmlussier |
miker: Great, thanks! |
| 11:22 |
kmlussier |
I'll upgrade mine to 2.10 when that happens. |
| 11:45 |
|
jihpringle joined #evergreen |
| 12:01 |
|
bmills joined #evergreen |
| 12:11 |
|
brahmina joined #evergreen |
| 12:22 |
|
yboston joined #evergreen |
| 12:31 |
StomproJosh |
Hmm, we just had a patron make a single $2 CC payment at the web based self check, which payed off every fine in her account, 17 in total. |
| 12:33 |
tsbere |
StomproJosh: So they had an average of 12 cents or so per fine? |
| 12:34 |
StomproJosh |
tsbere, the payments show up as a $2 payment for each bill. |
| 12:36 |
tsbere |
StomproJosh: And you know the credit card payment wasn't for, say, $34 and split across 17 $2 fines? |
| 12:37 |
jeff |
even if it just happened and the transactions haven't settled yet, you should be able to look into what the authorization amount was via whatever management/reporting you have for your chosen provider. |
| 12:37 |
StomproJosh |
I've got a scan of the receipt, it is just a single $2 payment. I'll check payflow to see what they see. |
| 12:40 |
StomproJosh |
Ooh, and the one she selected to pay, has 2 payments applied to it, so 2$ owed, and $4 payed. |
| 12:40 |
|
bmills joined #evergreen |
| 14:06 |
|
ssieb joined #evergreen |
| 14:29 |
ssieb |
I've read through the documentation, but I can't find any instructions on how to get an item status from "in process" or "reshelving" to "available". |
| 14:29 |
ssieb |
If you checkin a book it goes to state "reshelving", but what is the next step to indicate that it is back on the shelf? |
| 14:31 |
jeff |
to go from "in process" to something else, you usually check the item in. |
| 14:32 |
jeff |
the move from Reshelving to Available happens via a server-side process which is usually scheduled to happen automatically. |
| 14:35 |
ssieb |
Then what is the point of the reshelving status? |
| 14:35 |
dbs |
To indicate to people that it might not be on the shelf yet |
| 14:35 |
dbs |
i.e. "Go ask for it at the circ desk" |
| 14:36 |
ssieb |
But it's automatically changed. What is the delay time? |
| 14:36 |
dbs |
It's up to you; the default in reshelving_complete.srfsh is 24hours |
| 14:36 |
jeff |
the example crontab at Open-ILS/examples/crontab.example contains an example line to run the reshelving_complete.srfsh script at 2:00 AM each day |
| 14:37 |
ssieb |
ok. Did I miss mention of these things in the docs? |
| 14:37 |
dbs |
So you could change the "24h" to "1h" and have the cron job run every hour |
| 14:37 |
dbs |
ssieb: probably not |
| 14:42 |
Dyrcona |
ssieb: Some of this is explained in a book called Evergreen in Action. It's a bit dated but is available for free online. |
| 14:44 |
ssieb |
I'll look it up |
| 14:45 |
bshum |
The book doesn't really explain cron jobs, I just checked cause I thought it was in Evergreen in Action too. |
| 14:45 |
bshum |
But the basic concept of circulation and setup from that document are handy to review |
| 14:46 |
StomproJosh |
Re single payment paying multiple, it looks like it is actually 2 seperate calls to open-ils.circ.money.payment, 2 seconds apart. So I suspect that the web based self check is queuing up payments, if you click pay fines, then click view fines, and click pay fines again, and then submit the CC form. |
| 14:48 |
bshum |
The example crontab that jeff suggests probably has the most complete picture of various jobs that could need running |
| 14:50 |
ssieb |
I just found there's a setting for how long until an item goes from reshelving to available. :-) |
| 14:51 |
ssieb |
Unfortunately, it doesn't say what the default is... |
| 14:53 |
bshum |
Yes, I believe that setting can stand in place for whatever is defined in the script that dbs/jeff pointed you to. So that if it was configured, it would use that setting. But you'd still need to run said reshelving script on a regular enough basis to make use of the proper interval. |
| 14:53 |
bshum |
Unset, it's still default to 24hours wait time |
| 14:54 |
ssieb |
oh, ok |
| 14:55 |
StomproJosh |
Yep, just tested it out, the web self check will queue up a payment every time the pay fines button is pressed, and submit them all serially after the submit payment button is pressed. |
| 15:05 |
mmorgan |
StomproJosh: We have never allowed payment in selfcheck. We hid the link to pay early on. |
| 15:06 |
StomproJosh |
mmorgan, why? |
| 15:06 |
Dyrcona |
Because it is broken? :) |
| 15:06 |
bshum |
mmorgan: That link only shows up if you have CC enabled in settings right? (I didn't even know we had CC ability in selfcheck, so I assume it's cause ours wasn't configured) |
| 15:07 |
mmorgan |
We thought of selfcheck as more of an express checkout situation. |
| 15:08 |
Stompro |
This is the first issue we have had with it... and it isn't so huge of an issue, we just might have to issue refunds once in a while. |
| 15:08 |
mmorgan |
bshum: yes, that's true. We actually started using selfcheck before we had cc payments, so that could be part of it, too. |
| 15:10 |
Stompro |
The customer did get a receipt for both payments, she just hid the big long receipt for some reason, and only showed staff the receipt for the single $2 payment, that bit of info would have helped out. |
| 15:12 |
Stompro |
We view our self checks as more of a self help station, the more functionality the better. |
| 15:23 |
ssieb |
I'm having another weird situation. I created a patron and assigned it a staff role. However, that user can't login to the staff client. |
| 15:24 |
ssieb |
I checked that the password is correct. I thought I created this user the same way I did before the reset the database, but this time it doesn't work. |
| 15:24 |
mmorgan |
ssieb: Did you assign a working location? |
| 15:25 |
ssieb |
Is that necessary? I did notice that option somewhere, but I didn't remember setting that last time. :-) |
| 15:29 |
Stompro |
Hmm, I wonder if the payment problem could be related to me changing the "Pay Fines" link into a button? bug 1494748 |
| 15:29 |
pinesol_green |
Launchpad bug 1494748 in Evergreen "Self Check: Pay fines link should be a button" [Wishlist,Triaged] https://launchpad.net/bugs/1494748 |
| 15:30 |
mmorgan |
ssieb: Hmm. I guess not :) |
| 15:30 |
mmorgan |
Is the workstation registered? Does the user have permission to register a workstation? |
| 15:31 |
ssieb |
The workstation was registered before. Then I reset the database. I logged in as admin and registered the workstation. But it still doesn't work for the user. |
| 15:32 |
ssieb |
The user does have the STAFF_LOGIN permission |
| 15:34 |
ssieb |
and it doesn't work on another workstation either |
| 15:40 |
ssieb |
I created another user and it has the same problem. Did I break something by recreating the database? |
| 15:45 |
ssieb |
It doesn't work in srfsh either, so what am I missing? |
| 15:50 |
bshum |
ssieb: Probably asking the obvious, but when you went to recreate the DB, did you stop open-ils services, etc. and then before you started, maybe consider restarting memcache, and running autogen.sh again and restarting apache too? |
| 15:52 |
bshum |
I only say autogen and restart apache, cause any time I dump my DB and start over, I'm usually doing something different with the organiation units, and it'll cache the old org data around till I re-run that step. |
| 15:52 |
bshum |
*organization |
| 15:52 |
ssieb |
I did restart the openils services and had to run autogen, but I'll try the others as well. |
| 15:53 |
bshum |
As far as permissions go, I think "UPDATE_WORKSTATION" is the one that allows users to change or modify what they have on their end locally |
| 15:53 |
ssieb |
I used the egadmin account to register the workstation. |
| 15:54 |
bshum |
Right, that user would likely be a superuser with all permissions |
| 15:54 |
bshum |
Oh, you're saying newly created users can't log in ... hmm. |
| 15:54 |
ssieb |
nope, still fails :-( |
| 15:55 |
ssieb |
But there aren't any useful error messages anywhere that I can find to say why. |
| 15:57 |
ssieb |
Oh great... "/* Use __FILE__, harmless_line_number for creating |
| 15:57 |
ssieb |
* OILS_EVENT_AUTH_FAILED events (instead of OSRF_LOG_MARK) to avoid |
| 15:57 |
ssieb |
* giving away information about why an authentication attempt failed." |
| 15:59 |
tsbere |
ssieb: new users can't log in? Did you give them work ous? |
| 15:59 |
tsbere |
someone else may have mentioned that already |
| 15:59 |
miker |
ssieb: I know that's not helpful for you, but https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Authentication_and_Error_Messages |
| 15:59 |
tsbere |
But I run into it frequently myself when playing around |
| 16:11 |
ssieb |
tsbere: yes, I gave one of them a work OU and it didn't make any difference. This was working yesterday before I dropped and recreated the database. |
| 16:12 |
tsbere |
ssieb: And you are logging in with their username (not the barcode, though the default would have them be the same)? I just recalled someone having that issue recently. |
| 16:23 |
|
Dyrcona joined #evergreen |
| 16:32 |
ssieb |
tsbere: yes, in the staff client, logging in with their username |
| 16:32 |
ssieb |
and I verified in the patron interface that the password is correct and works |
| 16:33 |
Stompro |
Is there a correct way to void a payment? I've been updating money.payment, but I think I'm messing up things. |
| 16:37 |
Dyrcona |
Stompro: Throught the staff client should work. |
| 16:37 |
Dyrcona |
hmm. Maybe you can't void a payment in the staff client.... |
| 16:38 |
* Dyrcona |
has had a long day... |
| 16:38 |
Dyrcona |
I don't think there is a correct way to do it. The field is there, but IIRC almost nothing actually uses it. |
| 16:39 |
miker |
I think you can void individual billing line items from the billing detail screen, no? you could in the past. but with the new avoid-negative-balance stuff, I'm no longer sure |
| 16:39 |
Stompro |
I don't see where you can void payments in the staff client. Should I just be deleting money.payment entries instead? |
| 16:40 |
mmorgan |
You can't void a payment, just a billing. |
| 16:40 |
miker |
oh, duh, of course ... I kept ignoring the "payment" part |
| 16:40 |
mmorgan |
Stompro: I've never been brave enough to delete a money.payment entry. |
| 16:41 |
mmorgan |
I usually adjust by adding a billing (with a negative amount if necessary) to account for the overpayment. |
| 16:43 |
mmorgan |
Or maybe that would be a positive amount.... It HAS been a long day. |
| 16:47 |
Stompro |
Hmm, the info in the bills tab looks right, but the info from open-ils.actor.user.opac.vital_stats.authoritative is wrong now. Payments has a voided field, I want to use it... it is there.. sigh. |
| 16:49 |
Dyrcona |
Stompro: It's not wired up everywhere. I think it was one of those things that "would be a good idea" but didn't get finished. |
| 17:02 |
Stompro |
Hmm, so when I void a payment, it doesn't "un-finish" the transaction that might have been finished by the payment? And money.open_usr_summary excludes those transactions. So if I go through and set the xact_finish to null whenever I see a balanced_owed not equal to zero, I can maybe make it work? |
| 17:03 |
Stompro |
And maybe the trigger that updates money.materialized_billable_xact_summary when a payment is voided should also open the transaction back up if it is closed? |
| 17:08 |
|
mmorgan left #evergreen |
| 17:17 |
|
bmills joined #evergreen |
| 17:33 |
Dyrcona |
Stompro: That column is not meant to be used. It's like an appendix. |
| 19:14 |
ssieb |
I reinstalled the whole thing and I'm still getting login failure for any user other than egadmin... :-( |
| 19:56 |
bmills |
ssieb: i'm assuming the other users you've created were done in the staff client? you're able to log the patron in through the OPAC (http…eg/opac/login) but not through the staff client? I'd double check that STAFF_LOGIN permission. any luck trying to log them in through the web client if you have that set up? http…. eg/staff/ ? — you might also be having an issue with getting a workstation set like mmorgan and some others me |
| 20:08 |
bmills |
ssieb: not sure what version you're using, but you could also check the actor.passwd table to see if anything is missing/borked |
| 22:23 |
dbs |
ssieb: Yep, check actor.passwd to ensure there's a corresponding entry for your new user (who knows, maybe the pgcrypto extension is missing for some reason?) |
| 22:25 |
dbs |
And is the workstation you registered with egadmin registered with the same library (e.g. BR1) that you assigned the work_ou permissions to for your new user? |
| 22:27 |
dbs |
Also, I don't know if you're assigning the STAFF_LOGIN permission on its own to the user, but I've always assigned users to a permission group like Catalogers or Circulators, which gives them a whole bundle of permissions |
| 22:29 |
dbs |
Check permission.usr_work_ou_map to ensure the user's ID is there and linked to the expected library, and permission.usr_grp_map if you opt to assign them to a group, just to ensure the entries are in the database. |
| 23:13 |
ssieb |
dbs: I deleted everything under /openils and the /usr/local/share/perl5 directories and reinstalled, recreating the database and it still doesn't work. But that's really weird because it was working yesterday before I recreated the database. |
| 23:14 |
ssieb |
Where else could there be any persistent data that would affect this? |
| 23:16 |
ssieb |
and yes, I assigned the user to be circulation admin |
| 23:21 |
dbs |
memcached persists data for a while, but I imagine you would have restarted it between the time you deleted everything and tried again |
| 23:21 |
ssieb |
I deleted the .openils directory on the workstation, registered the workstation in the right OU and still it doesn't work. |
| 23:21 |
ssieb |
yes, I've restarted it, rebooted the computer, etc. |
| 23:22 |
ssieb |
If I check the password in the patron management, it says it works. It's just the login that doesn't. |
| 23:22 |
dbs |
That's pretty crazy. |
| 23:22 |
ssieb |
Yes! |
| 23:22 |
dbs |
Does it timeout when it's logging in? |
| 23:22 |
ssieb |
It was working yesterday, but I imported some data badly and had to restart... |
| 23:22 |
ssieb |
no, the response is immediate |
| 23:22 |
dbs |
huh. |
| 23:22 |
ssieb |
I see the FAILED LOGIN in the logs |
| 23:23 |
ssieb |
but I can't find out what the reason is |
| 23:24 |
ssieb |
I guess I'll have to put some debugging lines in the code to see if I can get some more info :-/ |
| 23:24 |
dbs |
You could crank up the loglevel to activity, and unredact the login stuff |
| 23:24 |
ssieb |
oh, how?? |
| 23:24 |
dbs |
redacted stuff is set in /openils/conf/opensrf_core.xml at the bottom |
| 23:24 |
dbs |
logging levels are set there too, in a number of places |
| 23:25 |
dbs |
Crank up to level 4 debug if you have enough disk space, restart the opensrf stuff, then restart apache, and see what happens |
| 23:26 |
ssieb |
You mean the router log levels? |
| 23:27 |
dbs |
I would go with all four, why not :) |
| 23:28 |
dbs |
also in eg_vhost.conf you can crank up the logging for apache |
| 23:28 |
ssieb |
yep, that's what I did |
| 23:28 |
dbs |
and you could turn on log_statement in postgresql too |
| 23:28 |
dbs |
should be plenty of data! |
| 23:29 |
dbs |
Can't remember -- did you try logging in through the regular old catalogue interface at http://hostname/eg/opac/home ? |
| 23:30 |
ssieb |
Login failed. The username or password provided was not valid. Passwords are case-sensitive. Check your Caps-Lock key and try again or contact your local library. |
| 23:32 |
dbs |
Okay, so at least we know now that it has nothing to do with workstation / work_ou permissions |
| 23:32 |
dbs |
to the logs! |
| 23:32 |
ssieb |
it doesn't work form srfsh either |
| 23:32 |
ssieb |
the logs are all cranked up now, time to try it out |
| 23:32 |
dbs |
I'd be highly interested in the postgresql log, just because there's pgcrypto magic going on with bcrypt and the like |
| 23:33 |
dbs |
if the pgcrypto extension isn't there for some reason, postgresql should be complaining loud and clear |
| 23:35 |
ssieb |
SELECT * FROM actor.verify_passwd( '2', 'main', 'fd0ed487b1f92fd4afcdfdd16187d' ) AS "actor.verify_passwd" |
| 23:35 |
ssieb |
(I removed a few characters from the hash, not that it matters :-) |
| 23:35 |
ssieb |
Query returned at least one row |
| 23:35 |
ssieb |
that's from osrfsys.log |
| 23:37 |
ssieb |
Ah! SELECT * FROM permission.usr_has_perm( '2', 'OPAC_LOGIN', '1' ) AS "permission.usr_has_perm" returns false |
| 23:37 |
ssieb |
same with STAFF_LOGIN! O_O |
| 23:38 |
dbs |
so when you said you set the person to be Circulation Administrator, do you mean in the "Secondary permission groups" part of the patron editor? Or did you set that to be their primary profile? |
| 23:38 |
ssieb |
primary. And checking the permissions, those are all set |
| 23:39 |
* dbs |
hasn't checked the permissions but OPAC_LOGIN should certainly be associated with any of the "real user" default groups |
| 23:39 |
ssieb |
in the permission list, there are two checkboxes, one for applied and one for grantable. What does "grantable" mean? |
| 23:40 |
dbs |
I think the normal approach is that primary group = patron or staff member; then secondary groups are used to reflect the roles they play |
| 23:40 |
ssieb |
The user has the applied checkbox checked for all those permissions, but not the grantable one. |
| 23:40 |
dbs |
grantable means "can they grant the same permission to others" |
| 23:40 |
ssieb |
ok |
| 23:40 |
ssieb |
I'm pretty sure I did it the same way yesterday, but I'll try changing that. |
| 23:41 |
ssieb |
haha, I think the logging is slowing it down drastically... |
| 23:41 |
dbs |
oh it would :) |
| 23:42 |
ssieb |
oh, never mind, it timed me out :-/ |
| 23:42 |
dbs |
damn |
| 23:43 |
ssieb |
hmm, the edit page isn't loading... |
| 23:44 |
ssieb |
ok, reloaded the client. "Staff" is not selectable, you have to pick one of the roles |
| 23:44 |
ssieb |
same as "Patrons" is a role under Users |
| 23:45 |
dbs |
okay, you want one of the options under "Patrons" for the primary |
| 23:45 |
dbs |
and then one or more of the options under "Staff" for the secondaries |
| 23:45 |
ssieb |
Patrons is the only option under Users |
| 23:45 |
dbs |
(sorry, we've had "Staff member |
| 23:46 |
dbs |
" under Patrons for so long to reflect the staff who have borrowing privs across the university that I forgot it's a customization) |
| 23:46 |
dbs |
Perfect. |
| 23:46 |
dbs |
(sorry, tired) |
| 23:48 |
dbs |
reading through the definition for permission.usr_has_perm with \df+ at psql, it returns true if either permission.usr_has_home_perm or permission.usr_has_work_perm return true |
| 23:48 |
dbs |
and permission.usr_has_work_perm always returns FALSE if the user is not marked as 'active' (SELECT usrname, active FROM actor.usr) |
| 23:50 |
ssieb |
they're definitely active |
| 23:53 |
ssieb |
trying to figure out what these postgresql functions are doing |
| 23:55 |
dbs |
they give you denormalized access to the union of the permissions a user might have, either assigned individually or via their profile or secondary permission groups |
| 23:56 |
ssieb |
sure, so I'm trying to figure out which part of it is going wrong... |
| 23:56 |
ssieb |
because that's where the problem is |
| 23:56 |
dbs |
as well as the depth at which those permissions are assigned (depth being the concept of across the entire consortium, or limited to one of the systems in the consortium, or limited to a branch of one of the systems) |
| 23:56 |
dbs |
well yeah. |
| 23:58 |
ssieb |
unless you have a better idea, because everything in the interface says it should be working, but the query says no |
| 23:58 |
dbs |
I usually start by working my way down, so go with making the call to "SELECT * FROM permission.usr_has_work_perm('2', 'OPAC_LOGIN', '1') first |
| 23:58 |
ssieb |
I could always just give the user super user access and ignore the problem for now... |
| 23:58 |
ssieb |
that is false |
| 23:59 |
dbs |
Hmm, that target OU of '1' means access across the entire Consortium, is that where you granted the perms and work_ou? |
