| Time |
Nick |
Message |
| 00:00 |
|
geoffsams joined #evergreen |
| 01:58 |
|
dbwells_ joined #evergreen |
| 02:05 |
|
remingtron_ joined #evergreen |
| 05:55 |
|
Mark__T joined #evergreen |
| 07:25 |
|
mrpeters joined #evergreen |
| 07:43 |
|
jboyer-isl joined #evergreen |
| 07:48 |
|
rlefaive joined #evergreen |
| 08:08 |
|
ericar joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
Dyrcona joined #evergreen |
| 08:49 |
jeff |
thought exercise for the day: anonymizing live data for testing purposes. |
| 08:53 |
|
Shae joined #evergreen |
| 08:54 |
Dyrcona |
jeff: Fill names and addresses with pseudo-random noise. |
| 08:54 |
Dyrcona |
Ditto if you have ID fields and phone numbers. |
| 08:54 |
Dyrcona |
Email addresses, too.... |
| 08:54 |
Dyrcona |
Hmm.. Sounds like it could be a big project. |
| 08:58 |
tsbere |
jeff: I had some code for that at one point when I had to do something like that for MassLNC testing |
| 08:58 |
tsbere |
I can check the masslnc server to see if I left a copy sitting there? |
| 08:59 |
|
ericar_ joined #evergreen |
| 09:03 |
jeff |
tsbere: sure, i'd be interested. |
| 09:04 |
jeff |
i'm also trying to keep in mind some of the issues around such things, especially https://en.wikipedia.org/wiki/AOL_search_data_leak |
| 09:05 |
jeff |
also the netflix contest :-) |
| 09:07 |
* tsbere |
found his notes....that apparently included wholesale truncation of several tables, but hasn't found the code yet |
| 09:08 |
tsbere |
jeff: Apparently instead of sanitizing the outputs I just truncated the entire action_trigger.event_output table |
| 09:09 |
* tsbere |
is not sure he has a copy of the code he used left though |
| 09:09 |
jeff |
no problem. thanks for taking the time to look. |
| 09:11 |
tsbere |
most of the other tables I noted truncating/dropping were migration holdovers, it looks like |
| 09:14 |
|
dMiller_ joined #evergreen |
| 09:15 |
|
yboston joined #evergreen |
| 09:52 |
kmlussier |
tsbere: Funny. I was just thinking of that script the other day and wondering if it's something I could still use. |
| 09:55 |
jeff |
while the script may be lost in time, can i ask what the use case was? |
| 09:58 |
|
maryj joined #evergreen |
| 10:01 |
Dyrcona |
jeff: It was used to anonymize patron data during the performance evaluation done by OmniTI. |
| 10:02 |
Dyrcona |
We used actual data from C/W MARS. |
| 10:03 |
jeff |
Got it. That was one of the possibilities that came to mind, but I figured best to ask. |
| 10:05 |
kmlussier |
My use case now is similar. There are times I want to use production data for testing, but, since we work with multiple partners, I prefer to do it with anonymized data. |
| 10:08 |
|
rjackson_isl joined #evergreen |
| 10:19 |
|
dbwells joined #evergreen |
| 10:25 |
|
ericar_ joined #evergreen |
| 10:27 |
remingtron |
kmlussier, Dyrcona: Release notes question: In 2.9 should the upgrade notes be moved from Administration to the main level "Upgrade Notes" section? Or should that main level go away, and keep the new location (within Admin) going forward? |
| 10:42 |
Dyrcona |
remingtron: I don't know. |
| 10:44 |
kmlussier |
remingtron: Yeah, it should. For some reason, I thought the script new how to handle that, but I could be wrong. |
| 10:44 |
kmlussier |
I often am |
| 10:44 |
remingtron |
kmlussier: so, follow precedent and move them to the upper level? |
| 10:45 |
kmlussier |
+1 |
| 10:45 |
remingtron |
thanks, I'll take care of it then |
| 10:45 |
kmlussier |
remingtron++ |
| 10:45 |
kmlussier |
s/new/knew |
| 11:03 |
|
vlewis joined #evergreen |
| 11:05 |
remingtron |
anyone have an opinion about copying the "Removal of JSPAC" and "Removal of legacy selfcheck" sections into Upgrade Notes? |
| 11:05 |
remingtron |
both sections have comments about optional steps during an upgrade |
| 11:07 |
kmlussier |
remingtron: Seems reasonable to me. Thanks! |
| 11:08 |
remingtron |
kmlussier: thanks for the feedback |
| 11:42 |
csharp |
jeff: I was just pondering test data anonymization myself - I don't have anything to offer other than "me too", though ;-) |
| 11:50 |
dbs |
remingtron: "If you were still using the JSPAC... Why? WHY?!?!" |
| 11:51 |
csharp |
pinesol_green: WHY?? |
| 11:51 |
pinesol_green |
csharp: have you tried local mean solar time for the named city as the reference point? |
| 11:51 |
pinesol_green |
Factoid 'WHY??' not found |
| 11:51 |
csharp |
heh |
| 11:52 |
csharp |
pinesol_green: tell bshum about troubleshooting |
| 11:52 |
pinesol_green |
csharp: The operation succeeded. |
| 11:52 |
pinesol_green |
Factoid 'troubleshooting' not found |
| 11:52 |
csharp |
heh |
| 11:52 |
csharp |
~troubleshoot |
| 11:52 |
pinesol_green |
If you're having trouble getting Evergreen to work, please follow this guide for isolating the problem: http://evergreen-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors |
| 11:52 |
csharp |
there we go |
| 11:52 |
csharp |
new bot behavior |
| 11:53 |
|
Christineb joined #evergreen |
| 11:53 |
csharp |
~troubleshooting is <alias> troubleshoot |
| 11:53 |
pinesol_green |
I'll remember that, csharp |
| 11:56 |
mmorgan |
So, if a circ transaction has a checkin_time, and money.materialized_billable_xact_summary.balance_owed = 0 for the associated row, the transaction should be closed, right? |
| 12:03 |
|
bmills joined #evergreen |
| 12:04 |
csharp |
mmorgan: yep |
| 12:05 |
csharp |
well, what determines if it *is* closed is xact_finish |
| 12:05 |
csharp |
if that's null, it's still "open" |
| 12:10 |
jeff |
that might bear clarification. |
| 12:11 |
kmlussier |
dbs: There is still a JSPAC out there in the wild. I found it a few months ago. |
| 12:11 |
jeff |
all circulations are billable transactions. circulations are "open" if their checkin_time is null. transactions are "open" if their xact_finish is null. |
| 12:12 |
csharp |
jeff: ah - good distinction |
| 12:12 |
jeff |
exemplified in views such as action.open_circulation and money.open_billable_xact_summary |
| 12:12 |
csharp |
in most cases that comes to me, the problem is "the circulation is still appearing on the list when it shouldn't" |
| 12:13 |
jeff |
yeah, which is slightly different... |
| 12:13 |
jeff |
because some "open" (no checkin_time) circulations do (and should) stop appearing in various interfaces based on things like stop_fines or xact_finish. |
| 12:24 |
|
gdunbar joined #evergreen |
| 12:24 |
|
akilsdonk_ joined #evergreen |
| 12:24 |
|
cfarley joined #evergreen |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:36 |
* mmorgan |
got pulled away, reads up |
| 12:40 |
mmorgan |
jeff: good info on the distinction. I was looking at xact_finish in action.circulation, so "open transactions" rather than "open circulations" |
| 12:43 |
mmorgan |
We have ~150,000 circs with a checkin_time and money.materialized_billable_xact_summary.balance_owed = 0 |
| 12:44 |
mmorgan |
I am thinking these need to be updated with a xact_finish. Another consideration is that they won't be aged if they're not closed. |
| 12:47 |
kmlussier |
That's a lot of circs that aren't closing properly. |
| 12:48 |
mmorgan |
kmlusier: Yes, indeed! |
| 12:49 |
mmorgan |
I wonder if other systems have similar numbers. Here's the query I used: |
| 12:50 |
mmorgan |
select count(acirc.*) from action.circulation acirc |
| 12:50 |
mmorgan |
join money.materialized_billable_xact_summary summary on acirc.id = summary.id |
| 12:50 |
mmorgan |
where acirc.xact_finish is null |
| 12:50 |
mmorgan |
and acirc.checkin_time is null |
| 12:50 |
mmorgan |
and summary.balance_owed = 0 |
| 12:50 |
mmorgan |
Oops, that's the wrong one :-( |
| 12:52 |
mmorgan |
Actually the "right" one gives more like 60,000: |
| 12:53 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "open transactions" (5 lines) at http://paste.evergreen-ils.org/11 |
| 13:12 |
bmills |
bshum: about your advice on the overdue notices from yesterday, the addition of [% circ.target_copy.circ_modifier %] to the emailed overdue action/trigger notices worked as intended |
| 13:12 |
bshum |
bmills: Cool deal :) |
| 13:13 |
bmills |
bshum++ |
| 13:15 |
|
Bmagic joined #evergreen |
| 13:17 |
Bmagic |
Has anyone created a report that looks at the indexed subject? I'm attempting to have it create a list of items who's bibs contain (ignore case) "western" in the indexed subject field. It's returning non western stuff |
| 13:20 |
jeff |
can you pastebin details? |
| 13:20 |
* csharp |
suspects IS NULL OR in the WHERE clause |
| 13:21 |
csharp |
if that's the case, you need to enable nullability selection and make sure the paths you take are "None" |
| 13:36 |
dbs |
kmlussier: wow |
| 13:40 |
csharp |
*cough* http://governor.gapines.org *cough* *cough* |
| 13:41 |
csharp |
been meaning to upgrade that for some time :-/ |
| 13:42 |
bshum |
csharp: Classic :) |
| 13:42 |
csharp |
yep! :-) |
| 13:42 |
kmlussier |
Oh, wow! |
| 13:43 |
kmlussier |
So that's 2 known instances in the wild. |
| 13:43 |
csharp |
"upgrade governor" has been on my whiteboard so long it probably won't come off anymore ;-) |
| 14:12 |
jeff |
"upgrade governor" is amusing to me. |
| 14:16 |
jeff |
looking at hardware. no pricing/distributor information apparent on site. fill out sales contact form. state interest in product model numbers X/Y/Z. |
| 14:16 |
jeff |
a few hours later, receive an email: |
| 14:16 |
jeff |
> Unfortunately we cannot sell direct to end users; However you can contact an integrator and they will be more than happy to get you set up with the [Vendor] equipment you are looking for. If you need our assistance locating one of them please let me know. I will be glad to help you out. |
| 14:18 |
jeff |
I think I'm stuck in a TCP joke. |
| 14:25 |
jboyer-isl |
jeff: Ah, welcome to the wide world of RFID hardware. (I assume. I saw you mention it in the c4l channel) |
| 14:25 |
jeff |
da. |
| 14:26 |
jeff |
i just want digikey to carry the part numbers i'm interested in. i'll even pay single unit pricing. :-) |
| 14:27 |
jboyer-isl |
That's code for "we're terrified of this near magical buzzword unicorn becoming commoditized, please see an associate to purchase at 1000% markup!" |
| 14:27 |
jboyer-isl |
what manufacturer are you looking at? |
| 14:28 |
jeff |
Feig. |
| 14:30 |
jboyer-isl |
Hah! Their SDK is a hoot also. Free in the EU, $800 in the US, if you can find someone to sell it to you. |
| 14:30 |
jboyer-isl |
(Last I looked, anyway.) |
| 14:40 |
csharp |
jeff: ha! I will not comment on whether or not our current governor needs upgrading ;-) |
| 14:42 |
jeff |
@eightball Cylon Governor or Terminator Governor |
| 14:42 |
pinesol_green |
jeff: About as likely as pigs flying. |
| 14:42 |
jeff |
er. |
| 14:42 |
jeff |
@decide Cylon Governor or Terminator Governor |
| 14:42 |
pinesol_green |
jeff: Beyond here be dragons. |
| 14:43 |
csharp |
bshum may need to load @eightball |
| 14:43 |
bshum |
@load games |
| 14:43 |
pinesol_green |
bshum: Error: Games is already loaded. |
| 14:43 |
bshum |
Hmm |
| 14:43 |
bshum |
@list |
| 14:43 |
pinesol_green |
bshum: Admin, Alias, Assorted2, AutoMode, BadWords, Blame, Bugtracker, Channel, ChannelLogger, Config, Dessert, Dunno, Encyclopedia, Games, Git, Herald, Insult, Karma, Later, LoveHate, MARC, Math, MeetBot, Misc, NickAuth, Owner, Praise, Quote, RSS, Seen, Time, User, Utilities, and Weather |
| 14:43 |
bshum |
@list Games |
| 14:43 |
pinesol_green |
bshum: coin, dice, eightball, monologue, and roulette |
| 14:43 |
jeff |
eightball is present, decide was not. |
| 14:43 |
csharp |
I don't think we had @decide before |
| 14:43 |
bshum |
Oh okay. |
| 14:43 |
jeff |
and we may never have had it. |
| 14:44 |
jeff |
default dunno for pinesol_green could be to ask zoia ;-) |
| 14:45 |
bshum |
jeff: csharp: @decide is one of the Assorted plugins from the code4lib. I could port it to our local version which I dubbed Assorted2 |
| 14:45 |
bshum |
If you really want it. |
| 14:46 |
jeff |
thanks, but no need. :-) |
| 14:47 |
Dyrcona |
@dunnoe |
| 14:47 |
pinesol_green |
Dyrcona: You probably want hard-boiled eggs. |
| 14:47 |
Dyrcona |
heh |
| 14:47 |
Dyrcona |
@eightball Will it blend? |
| 14:47 |
pinesol_green |
Dyrcona: What are you asking me for? |
| 14:48 |
bshum |
@decide jeff or bshum |
| 14:48 |
pinesol_green |
bshum: go with bshum |
| 14:48 |
bshum |
:D |
| 14:49 |
bshum |
Most of the zoia plugin content doesn't have associated docstrings and our new python dislikes that. |
| 14:49 |
* bshum |
has to keep remembering to fix that. |
| 14:49 |
bshum |
Maybe I'll submit another patch back to the c4l later. |
| 14:58 |
Bmagic |
jeff: csharp: AND (("70739dc8d7946c9ed789eb60d6175fb1"."value") IS NULL OR "70739dc8d7946c9ed789eb60d6175fb1"."value" ILIKE $_42913$%western%$_42913$) |
| 15:03 |
bshum |
Well this is a first for me... |
| 15:03 |
bshum |
One of our libraries wants to be able to process and add users to the Collections tracker themselves. |
| 15:04 |
bshum |
I don't see any way to (a) add a collections fee, or (b) add a user to the collections tracker via the staff client. |
| 15:04 |
bshum |
So I don't think that's... well, possible? |
| 15:05 |
tsbere |
bshum: Tell them they need a collections tool that they can install and that can integrate with Evergreen.....and you don't actually know of any? :P |
| 15:05 |
Bmagic |
csharp: jeff: It seems to allow all of the filters to be NULL OR and I cannot add two filters for the same column (one with the user selected criteria and one with non null) so Im stuck |
| 15:05 |
bshum |
tsbere++ # yeah, I'll get right on tha t;) |
| 15:09 |
csharp |
Bmagic: can you pastebin the full query? |
| 15:10 |
csharp |
@dunno search premium |
| 15:10 |
pinesol_green |
csharp: 1 found: #24: "Sorry, that command is only available to..." |
| 15:10 |
csharp |
@dunno 24 |
| 15:10 |
pinesol_green |
csharp: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 15:10 |
csharp |
@dunno get 24 |
| 15:10 |
pinesol_green |
csharp: Dunno #24: "Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP!" (added by csharp at 10:32 AM, December 06, 2013) |
| 15:11 |
tsbere |
Bmagic: Have you tried using the enable nullability checkbox? |
| 15:11 |
tsbere |
or whatever it is in that first section |
| 15:11 |
csharp |
tsbere: that's it |
| 15:11 |
Bmagic |
csharp: http://pastebin.com/a1sByzM5 |
| 15:12 |
Bmagic |
tsbere: I don't know of the checkbox of which you speak, in the template editor? |
| 15:12 |
tsbere |
Bmagic: Yes, in the template editor, though I find I get the best results if I check it first, before doing anything else. |
| 15:13 |
Bmagic |
tsbere: I see it |
| 15:13 |
Bmagic |
In this case, I dont think we want nulls |
| 15:13 |
csharp |
Bmagic: it's nullability *selection* so it lets you choose which columns can be null |
| 15:14 |
tsbere |
Bmagic: Once checked you should be able to get not null versions of the linked tables....though as I said, I find it works best if I check it from the start |
| 15:14 |
csharp |
specifically it lets you choose the join type |
| 15:14 |
csharp |
so choosing the "None" path equates to INNER JOIN |
| 15:15 |
csharp |
which would override all the LEFT OUTER JOINs in your query |
| 15:16 |
Bmagic |
csharp: tsbere: I see what that nullability checkbox is doing. However, I am confused to which of the 3 copies of Bib Record I would use "None", "Parent" or "Default" |
| 15:16 |
tsbere |
Bmagic: "None" when you want to force the not null bit. |
| 15:17 |
Bmagic |
I see, I'll check that out |
| 15:18 |
csharp |
Bmagic: None = INNER JOIN (no nulls), Parent means LEFT OUTER JOIN (the left or "parent" table can have nulls), Child = RIGHT JOIN (the right or child table can have nulls), and Default = do whatever you would have done by default |
| 15:18 |
* dbs |
pretty much always wants None |
| 15:18 |
|
dMiller_ joined #evergreen |
| 15:23 |
* csharp |
agreed to do an all-day EG reports training on the hackfest day of the 2016 conference, and will cover nullability in that session for those interested in digging in |
| 15:23 |
* tsbere |
stares at a query that has been running for almost an hour now without returning results |
| 15:24 |
csharp |
of course, most people here in the channel would probably rather do the hackfest |
| 15:26 |
Bmagic |
tsbere++ csharp++ jeff++ #it seems to be working, I have some more troubleshooting but that is a neat feature in the report template creator |
| 15:27 |
bshum |
Reports.... vs. hackfest. Gee, I dunno csharp... :) |
| 15:28 |
* csharp |
remembers the dark days before nullability selection when certain reports were just not possible without direct SQL |
| 15:28 |
csharp |
bshum++ |
| 15:28 |
csharp |
Bmagic: glad you got it working |
| 15:36 |
* jeff |
remembers the dark days before jasper |
| 15:36 |
* bshum |
prefers the dark. |
| 15:36 |
bshum |
"The sun, it burns....." |
| 15:37 |
jeff |
java's oracle now, not sun. |
| 15:37 |
* jeff |
ducks |
| 15:46 |
csharp |
jeff++ |
| 15:58 |
|
jlitrell joined #evergreen |
| 16:05 |
kmlussier |
remingtron / yboston: I can't remember. Are we using adoc now or were we still waiting on something before we started using it? |
| 16:06 |
Dyrcona |
The release notes scripts do not handle adoc. |
| 16:06 |
yboston |
I can't remember either |
| 16:06 |
yboston |
Dyrcona: Stompro put in a patch, but I think it needs a signoff |
| 16:06 |
kmlussier |
Dyrcona: Yeah, in this case I'm not doing a release notes entry |
| 16:08 |
kmlussier |
28e9f061 |
| 16:08 |
yboston |
kmlussier: I thought that remingtron might still need to do some testing |
| 16:08 |
kmlussier |
That never works for me. |
| 16:08 |
Stompro |
kmlussier, if you are adding something new, I would go with adoc format. We were waiting on figuring out if it is possible to move all the .txt to .adoc without totally screwing up the git history, or making it hard to use. |
| 16:08 |
kmlussier |
Stompro: OK, will do |
| 16:09 |
Dyrcona |
Stompro: A git mv in a single commit should not be too bad. |
| 16:09 |
csharp |
1ff6ca8f923fcb2666152e07a57b106419e9cfaf |
| 16:09 |
pinesol_green |
[evergreen|Remington Steed] Release Notes: Move/copy relevant sections to Upgrade Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1ff6ca8> |
| 16:09 |
Dyrcona |
kmlussier: The bot doesn't look at the working repo. |
| 16:09 |
csharp |
ah |
| 16:10 |
kmlussier |
Ah, that's why it never works for me. |
| 16:10 |
csharp |
@praise working |
| 16:10 |
* pinesol_green |
Shall I compare working to a summer's day? working is more lovely and more temperate. |
| 16:10 |
kmlussier |
I think I'll take the summer day over working |
| 16:11 |
Stompro |
Dyrcona, maybe that isn't the issue then, I might not understand the problem. (moving to .adoc) |
| 16:12 |
Dyrcona |
The changes look OK to me. I'll give 'em a go in a day or three. |
| 16:12 |
Dyrcona |
Stompro: .adoc is just an extension. As long as the tools are setup to handle it, then there should be no problem. |
| 16:13 |
remingtron |
kmlussier et al: my main concern converting everything to .adoc is messing up git history |
| 16:13 |
Dyrcona |
remingtron: How so? |
| 16:13 |
dbs |
remingtron: git history will follow renames |
| 16:14 |
dbs |
--follow Continue listing the history of a file beyond renames (works only for a single file). |
| 16:14 |
Stompro |
It does make the Github blaim feature harder to use, since all it will show is the move commit. |
| 16:14 |
dbs |
github, blah |
| 16:15 |
Dyrcona |
;) |
| 16:15 |
remingtron |
dbs, Dyrcona: I know, it's supposed to work, but I came across an issue that seemed like a monkey wrench |
| 16:15 |
* Dyrcona |
has no problem using both txt and adoc. |
| 16:16 |
* Dyrcona |
also doesn't spend much time in the documentation. |
| 16:16 |
remingtron |
dbs: yeah, I think useful git history viewing would forever require an extra param, like --follow |
| 16:16 |
Stompro |
I know I know, but it is easy to use. I haven't figured out how to show the history of a particular line of code from the command line. |
| 16:18 |
Dyrcona |
Stompro: git blame ? ;) |
| 16:18 |
dbs |
http://git-scm.com/docs/git-blame "The origin of lines is automatically followed across whole-file renames (currently there is no option to turn the rename-following off)" |
| 16:18 |
Stompro |
Thanks.. can't use that excuse anymore then. |
| 16:19 |
Dyrcona |
@praise git |
| 16:19 |
* pinesol_green |
git is the hardest working person in #evergreen. |
| 16:20 |
Dyrcona |
You can say that again. |
| 16:20 |
dbwells |
ain't that the truth |
| 16:20 |
dbs |
+1 |
| 16:21 |
ldw |
Has any one noticed when configuring the KPac, that uncommenting the global_filter option causes the home page to fail to render its cell's part of the time? |
| 16:22 |
bshum |
ldw: What is your global filter set to? We use it and I haven't heard any issues there. |
| 16:23 |
ldw |
I set it to locations(id, id) |
| 16:24 |
ldw |
I did not use it on my dev server, and did not have any troubles, but when I moved my files to our traning server and added the global_filter, the home page failes to render its cells about 33% of the time. Recommening it and reloading apache seems to work. I am using individual kpac.xml files per OU. |
| 16:25 |
bshum |
ldw: Well, we have our global_filter set to use a filter group, which that group uses locations I think. |
| 16:25 |
bshum |
And I haven't heard of any rendering issues like that. |
| 16:25 |
bshum |
But we're also not using it per OU, it's one kpac.xml for the entire consortium. |
| 16:25 |
bshum |
Anything in the logs, either server or client side? |
| 16:26 |
bshum |
Maybe something is interrupting it before it can finish rendering |
| 16:26 |
ldw |
I am not seeing any errors on the server side. Let me check client side. |
| 16:26 |
bshum |
Or a timeout of some sort |
| 16:27 |
ldw |
hmmm, I have uncommented the global_filter and reloaded apache, and not I cannot reproduce. Problem sovled :/! |
| 16:28 |
ldw |
s/not/now/ |
| 16:28 |
bshum |
Maybe it was a weird cache problem |
| 16:28 |
bshum |
And the apache reload hadn't kicked in right |
| 16:28 |
ldw |
bshum: that was my initial thinking. I will go with that. |
| 16:32 |
|
jboyer-isl joined #evergreen |
| 16:36 |
|
bmills joined #evergreen |
| 16:52 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Documentation for negative balance work - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8d3544e> |
| 17:00 |
|
ericar joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 17:06 |
Bmagic |
Is there a feature to make a dropdown menu item "default" for grocery billing dropdown box ? |
| 17:26 |
ldw |
bshum: The error came back, and I think it is due to my use of separate kpac.xml files. If I remove the OILSWebContextLoader variable from one OU, then the other loads fine and the OU with the lack of OILSWebContextLoader has no images. As soon as I add OILSWebContextLoader to both OUs then I get intermittent problems. |
| 17:26 |
ldw |
I think the PerSetVar KPacConfigFile is getting confused somehow. |
| 17:27 |
ldw |
When using separate kpac.xml files there is only one layout owner, if that owner is incorrect then none of the images get loaded. That is my guess anyway. |
| 17:46 |
ldw |
Found the problem (or my intermitent bug is playing hide really well right now) EGKPackLoader.pm caches the kpac.xml file in the ctx variable. By forcing the page to load the kpac.xml file each time the problem goes away. I will report to launchpad with a fix. |
| 19:23 |
|
gsams joined #evergreen |
| 20:42 |
|
bmills joined #evergreen |
| 21:54 |
|
jlitrell joined #evergreen |
| 23:15 |
|
mmorgan1 joined #evergreen |
| 23:56 |
|
dcook joined #evergreen |
