| Time |
Nick |
Message |
| 00:39 |
|
stevenyvr2 joined #evergreen |
| 00:39 |
|
stevenyvr2 left #evergreen |
| 01:21 |
paxed |
berick: in the WCAG improvements branch: "Items on HOld" |
| 01:28 |
paxed |
berick: not specific to WCAG, but there seems to be an untranslatable "Go to..." in Open-ILS/src/templates/opac/parts/myopac/base.tt2 |
| 05:10 |
|
bradl joined #evergreen |
| 07:40 |
|
ningalls joined #evergreen |
| 07:40 |
|
rjackson-isl joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 07:50 |
rjackson-isl |
psql -U evergreen |
| 07:51 |
rjackson-isl |
oops! |
| 07:54 |
jeff |
Password for user 'evergreen': |
| 07:55 |
rjackson-isl |
12345? |
| 08:22 |
|
mrpeters joined #evergreen |
| 08:26 |
|
akilsdonk joined #evergreen |
| 08:32 |
berick |
paxed: thanks. i'm trying to root out some of the untranslated stuff while i'm in there (and hopefully not create more). i'll take care of that one. |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:39 |
|
kbeswick joined #evergreen |
| 08:54 |
|
jwoodard joined #evergreen |
| 08:54 |
|
finnx joined #evergreen |
| 08:58 |
|
keynote2k joined #evergreen |
| 09:10 |
|
ericar joined #evergreen |
| 09:11 |
|
Dyrcona joined #evergreen |
| 09:22 |
|
RoganH joined #evergreen |
| 10:07 |
|
yboston joined #evergreen |
| 10:11 |
|
jtaylor joined #evergreen |
| 10:16 |
jtaylorats |
Is there a document which explain the purpose of the fields and tables and how they are linked? I've read through a couple different schema documents but they don't really explain what I need to know. Things like linking copy records to bibliographic records and such things. Sorry if I've missed something obvious. |
| 10:24 |
RoganH |
jtaylorats: there really isn't |
| 10:24 |
RoganH |
jtaylorats: in that case it's by way of callnumber so |
| 10:25 |
jtaylorats |
Okay...found that path but seemed like an odd path to me. |
| 10:25 |
RoganH |
if I was doing select from asset.copy ac I would join asset.call_number call on call.id = ac.call_number |
| 10:25 |
RoganH |
then call.record = biblio.record_entry.id or metabib.real_full_rec.record or a few other places |
| 10:26 |
RoganH |
depending on what you want to do. |
| 10:26 |
jtaylorats |
Trying to sort out a failed migration to see if it can be salvaged. |
| 10:26 |
RoganH |
jtaylorats: I think it's a bit awkward but it makes sense once you get used to the db structure, at least it's consistent |
| 10:26 |
RoganH |
jtaylorats: good luck! |
| 10:27 |
jtaylorats |
Thanks. |
| 10:28 |
jtaylorats |
Library was left stranded in the middle of it so get to see what I can figure out. |
| 10:29 |
RoganH |
jtaylorats: well, I'm not a db guru but glad to help if I can |
| 10:30 |
jtaylorats |
Appreciate it. Hopefully I won't be a pest but sure I'll have another question or two along the way. Thanks again. |
| 10:32 |
jeff |
"left stranded" doesn't sound fun at all. |
| 10:39 |
|
b_bonner_ joined #evergreen |
| 10:42 |
|
mtcarlson_away joined #evergreen |
| 10:43 |
jtaylorats |
Nope. I like a challenge though :-) |
| 10:49 |
kmlussier |
@later tell ericar http://evergreen-ils.org/communicate/committees/ was copied from http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_committees. Do you have any objections to my deleting the wiki page? Fewer places to update. |
| 10:49 |
pinesol_green |
kmlussier: The operation succeeded. |
| 10:52 |
|
hopkinsju joined #evergreen |
| 10:54 |
hopkinsju |
Is there some mechanism that stores information about permissions context location? We made a change to our org unit structure, decided it didn't work, and then reverted. Now the org units under org units we changed are having odd permission issues. |
| 10:55 |
hopkinsju |
For example, the circulation users at these libraries are not able to edit patron records because the home library field in the staff client does not contain any entries. |
| 10:55 |
hopkinsju |
In fact, that's pretty much the only example. |
| 10:55 |
csharp |
eww |
| 10:55 |
|
ericar joined #evergreen |
| 10:56 |
hopkinsju |
csharp: I'm liking the sound of this. |
| 10:56 |
csharp |
hopkinsju: permission.grp_perm_map has a depth column which corresponds with the depth of actor.org_unit_type |
| 10:57 |
csharp |
but that context is derived from the user's working location |
| 10:58 |
csharp |
permission.usr_work_ou_map |
| 10:58 |
csharp |
hopkinsju: you also need to run /openils/bin/autogen.sh after an org tree change |
| 10:59 |
csharp |
and probably add a '-u' flag to that (though that may no longer be necessary) |
| 11:00 |
hopkinsju |
Right on, we've autogen'd, but I'll do it again for good measure. I'm looking at those 2 tables now. |
| 11:01 |
csharp |
hopkinsju: note that the staff client caches all that stuff, so they may need to go to Admin -> For developers... -> Clear Cache and entirely exit the staff client and open it anew to see the changes |
| 11:01 |
csharp |
in fact, you might rule that possibility out first |
| 11:02 |
hopkinsju |
csharp: Thanks. I think that's a good idea. |
| 11:04 |
hopkinsju |
Not the cache. |
| 11:16 |
csharp |
hopkinsju: do they have the editing permission for patron users assigned and at the correct depth? |
| 11:17 |
hopkinsju |
AFAIK. They have update user at System |
| 11:19 |
pinesol_green |
[evergreen|Galen Charlton] LP#1269042: prevent acq seach from building dropdown of every copy ID in the DB - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=deb52e4> |
| 11:19 |
csharp |
hopkinsju: so do they have working locations assigned at the correct library? |
| 11:19 |
hopkinsju |
They do |
| 11:20 |
csharp |
hrm |
| 11:20 |
csharp |
I would tail the logs and see what happens when they try |
| 11:21 |
hopkinsju |
We had added a OU type. We had two library systems that came in and wanted to have the ability to search a shared catalog. So we added another OU type underneath system, and then another new type for the branches. |
| 11:22 |
hopkinsju |
It had an odd effect when viewing permissions in the staff client. Looking at the user permission editor the values in there seemed to all change their depth. |
| 11:23 |
csharp |
yowza |
| 11:24 |
jeff |
did you end up reverting those changes? |
| 11:24 |
hopkinsju |
The documentation on adding new types wasn't super helpful so we were doing some trailblazing. Our initial testing looked ok, but we missed the inability to save users. |
| 11:25 |
csharp |
hopkinsju: do the existing org unit types have 'can_have_vols' and 'can_have_users' set to true appropriately? |
| 11:25 |
jeff |
because if it's possible to end up with a org type setup of ONE -> TWO -> THREE but have a first-level child of the root be of type THREE, I'll bet that breaks things. |
| 11:25 |
hopkinsju |
jeff: We reverted them, but not in the technical sense. We removed the new types and changed the parent OU for the sub-branches. |
| 11:25 |
jeff |
it's possible that there are db constraints that prevent the creation of such a broken tree in the first place. |
| 11:26 |
hopkinsju |
jeff: We did this in the staff client. We created a "sub-system" type and a "sub-branch" |
| 11:27 |
hopkinsju |
It did have the effect that the depth of branch was the same as the depth of sub-system, although the paths down the tree were different. |
| 11:27 |
|
jecs joined #evergreen |
| 11:29 |
jecs |
Hi all! The release notes for 2.5 say, "RSS links to full catalog record." Can anyone tell me what that means? (Not RSS-I know what that is!) |
| 11:30 |
jeff |
jecs: there are a handful of RSS URLs in Evergreen. Until 2.5, they were still linking to an older-style JSPAC or even a "slimpac" style URL. |
| 11:31 |
jeff |
(at least, I think that's what that means) |
| 11:32 |
jecs |
jeff: tx, where do they show up? OPAC, staff client?... |
| 11:32 |
* bshum |
digs up old bugs https://bugs.launchpad.net/evergreen/+bug/1089479 |
| 11:32 |
pinesol_green |
Launchpad bug 1089479 in Evergreen "tpac: links from RSS feeds/unapi display continue to go to jspac" (affected: 2, heat: 14) [High,Fix released] |
| 11:33 |
bshum |
NOBLE's example links in the original bug description still work. |
| 11:34 |
bshum |
And I think they may have since upgraded to a version of Evergreen where TPAC was used primarily. |
| 11:35 |
jecs |
ok, but does it only show up in the user interface under "List" functionality? |
| 11:38 |
dbs |
huh. JSPAC offered up RSS for searches, and had OpenSearch support too. |
| 11:38 |
* dbs |
swears he had a "restore opensearch" branch for TPAC somewhere |
| 11:39 |
jecs |
ahhhh - tx, all! |
| 11:41 |
bshum |
dbs: http://irc.evergreen-ils.org/evergreen/2013-08-16#i_22600 |
| 11:41 |
bshum |
Yes, we did muse about it :) |
| 11:41 |
bshum |
But maybe it got lost |
| 11:42 |
dbs |
bshum: opening a bug right now to track it |
| 11:43 |
dbs |
thanks for the reminder! |
| 11:45 |
kmlussier |
Hmmm...the links in that bug report do still work, but they don't necessarily show the same behavior that we were illustrating there. |
| 11:45 |
kmlussier |
The unapi display is no longer going to JSPAC. And the RSS feed no longer goes to that unapi display. Which is a good thing! :) |
| 11:46 |
kmlussier |
@coin |
| 11:46 |
pinesol_green |
kmlussier: heads |
| 11:46 |
kmlussier |
Thank you, pinesol_green, that was the answer I was hoping for. |
| 11:49 |
jeff |
@COINS |
| 11:50 |
pinesol_green |
jeff: Try restarting apache. |
| 11:50 |
jeff |
alas. |
| 11:50 |
dbs |
bug 1269070 |
| 11:50 |
pinesol_green |
Launchpad bug 1269070 in Evergreen "TPAC: Restore OpenSearch and RSS feeds for searches" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1269070 |
| 11:50 |
jeff |
(earwax) |
| 12:29 |
|
rfrasur joined #evergreen |
| 12:44 |
|
zxiiro joined #evergreen |
| 12:47 |
|
Sato`kun joined #evergreen |
| 12:48 |
|
smyers_ joined #evergreen |
| 13:05 |
jeff |
logs++ |
| 13:06 |
jeff |
two searches on two different machines giving different results? well, one of the searches was limited to juvenile audience -- that'll do it! |
| 13:06 |
rfrasur |
jeff++ |
| 13:36 |
|
hopkinsju joined #evergreen |
| 13:47 |
tsbere |
jeff: I personally liked one a few weeks back where they were telling me something was horribly wrong via email due to different search results and when I finally got them on the phone I found out that one machine was in the staff client in production and the other in the training system public opac. >_> |
| 14:09 |
|
5EXAAF94C joined #evergreen |
| 14:09 |
|
timlaptop joined #evergreen |
| 14:17 |
jeff |
gmcharlt++ |
| 14:17 |
jeff |
ESI++ |
| 14:39 |
rfrasur |
Dyrcona, you are correct. |
| 14:40 |
Dyrcona |
rfrasur: Don't tell me that. I might get a swell head. |
| 14:40 |
rfrasur |
Gosh, it's swell already. |
| 14:47 |
|
stevenyvr2 joined #evergreen |
| 14:47 |
|
stevenyvr2 left #evergreen |
| 14:48 |
|
stevenyvr joined #evergreen |
| 14:54 |
dbwells |
grabbing 0851 |
| 14:54 |
|
hopkinsju joined #evergreen |
| 15:08 |
pinesol_green |
[evergreen|Dan Scott] Encode.pm change to the UTF8 flag - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=796cf6b> |
| 15:08 |
pinesol_green |
[evergreen|Dan Scott] Test Perl Unicode normalization process - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d475ebc> |
| 15:08 |
pinesol_green |
[evergreen|Dan Scott] Add pgTAP test for normalized MARC records - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1da9b00> |
| 15:08 |
pinesol_green |
[evergreen|Dan Wells] Upgrade file for Encode.pm 2.54+ changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=644f244> |
| 15:08 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0851 - changes for Encode.pm 2.54+ - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ecbe401> |
| 15:08 |
dbs |
dbwells++ |
| 15:09 |
rfrasur |
dbwells++ |
| 15:14 |
egbuilder |
build #446 of evergreen-master-fedora-18 is complete: Success [build successful] Build details are at http://testing.evergreen-ils.org/buildbot/builders/evergreen-master-fedora-18/builds/446 |
| 15:15 |
RoganH |
dbwells++ |
| 15:20 |
dbs |
buildbot++ |
| 15:20 |
|
sandbergja joined #evergreen |
| 15:23 |
burlingtonwa |
Whenever I create a Patron Request in Acq, it places 4 holds on the same bib for the same patron. Anyone else using eg 2.4.4 have this problem, and is there any fix? Thanks! |
| 15:28 |
tsbere |
I can honestly say I have never had that happen. |
| 15:28 |
tsbere |
Mainly because I can also honestly say I am unaware of any time I have actually used Acq, patron request or otherwise |
| 15:28 |
tsbere |
<_< |
| 15:29 |
burlingtonwa |
haha! fair enough, tsbere. |
| 15:31 |
burlingtonwa |
should I just try an email on the general list? |
| 15:31 |
rfrasur |
burlingtonwa, probably. |
| 15:31 |
burlingtonwa |
will do. thanks! |
| 15:31 |
* rfrasur |
hasn't had any practical experience with 2.4.anything |
| 15:38 |
|
smyers_ joined #evergreen |
| 15:44 |
jeff |
dbwells++ dbs++ for bug 1242999 |
| 15:44 |
pinesol_green |
Launchpad bug 1242999 in Evergreen 2.5 "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 10) [Undecided,Confirmed] https://launchpad.net/bugs/1242999 - Assigned to Dan Wells (dbw2) |
| 15:51 |
|
book` joined #evergreen |
| 16:16 |
|
snowball joined #evergreen |
| 16:24 |
|
afterl joined #evergreen |
| 16:26 |
|
kbeswick_ joined #evergreen |
| 16:46 |
mmorgan |
is there any way from server log entries to see whether a workstation is using "Strict Barcode" in checkin? |
| 16:46 |
mmorgan |
I'm thinking no... but hoping |
| 16:48 |
tsbere |
Not that I know of |
| 16:48 |
tsbere |
If strict barcode checks fail you don't even get a server side entry, in fact.... |
| 16:48 |
berick |
yeah, pretty sure that all happens on the client side. if it's on and it encounters a bad barcode, the checkin call will never make it to the server. |
| 16:48 |
berick |
yeah |
| 16:49 |
jeff |
no, there's no difference other than you know if you receive a barcode that isn't "strict" conforming, either they aren't using the option or they overrode the prompt. :-) |
| 16:51 |
mmorgan |
thought as much. It would be useful to know how often the prompt is overridden. |
| 16:52 |
jeff |
well, given a log of requests from a workstation that you "know" has it turned on, count the requests that contain a non-strict-conforming barcode value. :-) |
| 16:52 |
jeff |
What's the underlying reason for wanting to know? |
| 16:53 |
mmorgan |
jeff: yeah, if we could be sure it's turned on ... |
| 16:53 |
mmorgan |
trying to herd precats |
| 16:54 |
tsbere |
A lot of our precats are conforming to those rules. Because someone deleted them previously. >_> |
| 16:56 |
|
afterl left #evergreen |
| 16:56 |
mmorgan |
we have lots of precats with barcodes that are a few digits long |
| 16:57 |
tsbere |
We have a precat with a 193 character barcode. WTF? >_> |
| 17:00 |
mmorgan |
I can see that a precat with barcode "4" has been edited many times, presumably by attempted circ transactions. |
| 17:20 |
|
smyers_ joined #evergreen |
| 17:28 |
|
mmorgan left #evergreen |
| 17:29 |
Bmagic |
I have an interesting issue with editing patrons. We use the same permission group for every branch when issuing accounts to the staff client. Whenever we make an account inside of this paticular branch, the permissions prevent the account from seeing the "Home OU" dropdown list when editing patrons.We have been beating our heads against this trying to find out what is going on with this branch. |
| 17:29 |
Bmagic |
Any ideas are welcome |
| 17:33 |
|
mrpeters left #evergreen |
| 17:37 |
|
dcook joined #evergreen |
| 17:55 |
|
smyers__ joined #evergreen |
| 18:00 |
|
smyers_ joined #evergreen |
| 18:01 |
|
jecs left #evergreen |
| 18:18 |
|
smyers__ joined #evergreen |
| 18:23 |
|
jtaylorats joined #evergreen |
| 19:49 |
|
jeff joined #evergreen |
| 19:57 |
|
zxiiro joined #evergreen |
| 20:15 |
|
dcook joined #evergreen |
| 21:21 |
|
zxiiro joined #evergreen |
| 23:18 |
|
stevenyvr2 joined #evergreen |
| 23:19 |
|
stevenyvr2 left #evergreen |
| 23:30 |
|
stevenyvr joined #evergreen |
