| Time |
Nick |
Message |
| 02:12 |
|
ats_vin joined #evergreen |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
b_bonner joined #evergreen |
| 06:41 |
|
mtcarlson_away joined #evergreen |
| 07:28 |
|
timf joined #evergreen |
| 08:07 |
|
Shae joined #evergreen |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:25 |
|
mrpeters joined #evergreen |
| 08:29 |
|
StephenGWills joined #evergreen |
| 08:29 |
|
n4999 joined #evergreen |
| 08:30 |
|
StephenGWills left #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:50 |
|
Dyrcona joined #evergreen |
| 08:50 |
|
jwoodard joined #evergreen |
| 08:52 |
|
collum joined #evergreen |
| 08:53 |
|
ericar joined #evergreen |
| 09:31 |
|
yboston joined #evergreen |
| 09:35 |
mrpeters |
tinkering with register.js to stick some default address values in place. it's working, for street1, but following that register_table.tt2 doesn't load. Is this improper syntax? |
| 09:35 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "register.js default street1" (3 lines) at http://paste.evergreen-ils.org/30 |
| 09:38 |
mrpeters |
(actually doesn't matter which field i set first, post code does the same thing -- then street1 and beyond don't load) |
| 09:43 |
jeff |
not enough context to tell. pushing a working branch is best. full register.js would be okay, too. |
| 09:43 |
jeff |
and failing that, at least the entire function that you changed. :-) |
| 09:44 |
pastebot |
"mrpeters" at 64.57.241.14 pasted "register.js tweaks for prepopulated address text boxes" (43 lines) at http://paste.evergreen-ils.org/31 |
| 09:44 |
mrpeters |
jeff: whoops, pasted that section before i saw your message |
| 09:44 |
mrpeters |
its a stock register.js except for what i pasted above, but i can paste the full if need be |
| 09:45 |
|
kmlussier joined #evergreen |
| 09:46 |
jeff |
no problem. that seems like enough. any new errors/warnings in the js console in the client when you run with this in place? |
| 09:48 |
mrpeters |
Timestamp: 5/15/2014 9:47:01 AM |
| 09:48 |
mrpeters |
Error: TypeError: collectExemptCBox is undefined |
| 09:48 |
mrpeters |
Source File: oils://remote/js/ui/default/actor/user/register.js |
| 09:48 |
mrpeters |
Line: 1233 |
| 09:48 |
mrpeters |
thats not related though |
| 09:49 |
mrpeters |
some errors about claims returned count |
| 09:49 |
mrpeters |
Timestamp: 5/15/2014 9:47:50 AM |
| 09:49 |
mrpeters |
Error: ReferenceError: register is not defined |
| 09:49 |
mrpeters |
Source File: javascript:%20register.js |
| 09:49 |
mrpeters |
Line: 1 |
| 09:50 |
mrpeters |
doesn't seem like anything related in there |
| 09:51 |
|
kbeswick joined #evergreen |
| 09:52 |
tsbere |
mrpeters: You could always try putting alert statements in there to see what is or is not triggering |
| 09:52 |
tsbere |
mrpeters: Specifically, if you alert on the current fmfield you can see as it goes through to possibly determine which change is causing issues |
| 09:53 |
mrpeters |
yeah, ill mess with it some more for sure, i just wanted to see if i was doing anything obviously wrong |
| 09:53 |
mrpeters |
it works perfectly, for the first default value you try to set :) |
| 09:54 |
tsbere |
mrpeters: Basically, I recommend putting alert(row.getAttribute('fmfield')); just after the var widget = line |
| 09:55 |
mrpeters |
hmm that throws an alert on address type, which previously was populating fine (now doesnt) |
| 09:56 |
mrpeters |
after you click ok, it does, then the same for post code, then it just stops |
| 09:59 |
|
mllewellyn joined #evergreen |
| 10:03 |
|
RoganH joined #evergreen |
| 10:16 |
tsbere |
mrpeters: Having looked at the code, thought about what it is doing, considered your statement as to where it is stopping, I still have no clue....though I have another debug idea. >_> |
| 10:19 |
tsbere |
mrpeters: Wrap the entire block of code, either the if block or the contents of it, in a try { <<orig code>> } catch(err) { alert('Defaults failed!!! ' + err.message); } |
| 10:19 |
tsbere |
mrpeters: That should pre-empt any other error-eating code |
| 10:29 |
Bmagic |
Did we ever come to a conclusion on getting evergreen to apply a custom group penalty when clicking the refresh button? |
| 10:29 |
mrpeters |
tsbere: thanks, ill give that a shot |
| 10:30 |
tsbere |
Bmagic: What do you mean custom group penalty? |
| 10:31 |
Bmagic |
tsbere: Apparenty we have defined a custom penalty called PATRON_EXCEEDS_FINES_FOR_HOLDS (it was before my time) but I am realizing that the system is not applying the standing penalty when the patron meets the criteria |
| 10:31 |
jeff |
Bmagic: if i recall correctly from the earlier conversation, code at either or both of the perl and sql layers would need to be written. it would be either a local customization or a new feature. |
| 10:32 |
kmlussier |
Bmagic: I think the conclusion from bshum was that it would take additional development. |
| 10:33 |
Bmagic |
Just to be clear: Nobody can define a standing penalty and have it auto apply? |
| 10:34 |
Bmagic |
Also to be clear: The standing penalty that I mentioned is in fact custom (I didnt create it but someone else might have) |
| 10:34 |
tsbere |
Bmagic: How is the system supposed to know what to do about that penalty? Someone has to add code so that the system knows what is supposed to be done with it. |
| 10:34 |
Bmagic |
That was a question (is PATRON_EXCEEDS_FINES_FOR_HOLDS custom?) |
| 10:35 |
kmlussier |
Bmagic: We did have somebody who once tried creating an action/trigger using the ApplyPatronPenalty, but she was never able to get it to work. http://markmail.org/message/2mkrfpx3of7ddy3i |
| 10:36 |
Bmagic |
tsbere: logically it would make since that the system has all of the pieces to know what to do with it. There is the definition and the block list says HOLD. And defined in "Penalty Threshold" is an associated org unit with a dollar amount..... I guess the system doesnt know that it's a dollar amount? |
| 10:37 |
kmlussier |
Bmagic: No, it doesn't know it's a dollar amount. For some penalties, it's actually a count that is entered there. |
| 10:37 |
Bmagic |
kmlussier: aha! It's all coming together now |
| 10:38 |
Bmagic |
So really, the system needs one more connection, tell it what value that threshold is supposed to be compared to |
| 10:38 |
kmlussier |
Bmagic: To answer your previous question, I don't see PATRON_EXCEEDS_FINES_FOR_HOLDS in any of our systems, so I would say it is indeed custom. |
| 10:38 |
Bmagic |
kmlussier++ |
| 10:38 |
kmlussier |
Sorry, when you were asking about this the other day, I misunderstood and thought you created it. |
| 10:40 |
Bmagic |
I didnt create it. And it looks pretty legit with the way it's named. Accept for 2 things: The staff client show's it database ID in black instead of red. All of the other definitions are red in the UI. It's database ID is also a larger number (102) |
| 10:41 |
Bmagic |
tsbere++ |
| 10:41 |
Bmagic |
jeff++ |
| 10:41 |
Bmagic |
I can put this one to bed |
| 10:53 |
pinesol_green |
[evergreen|Ben Shum] Documentation for adding OpenSearch to Firefox - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ba0e6c0> |
| 10:56 |
jboyer-isl |
Is anyone in here familiar with metabib.metarecord? I'm trying to find out why a record isn't appearing in searches and the mods field of that table is null for 2464334 records, and not null for 48723. That seems a little crazy. |
| 10:57 |
remingtron |
bshum: I pushed in your OpenSearch docs. Thanks! |
| 10:59 |
jboyer-isl |
And there are apparently 125862 more biblio.record_entries than even exist in metabib.metarecord. D: |
| 11:02 |
jeff |
jboyer-isl: that second is not abnormal at all. |
| 11:02 |
jeff |
jboyer-isl: compare counts of these two queries: |
| 11:03 |
jeff |
select count(*) from metabib.metarecord_source_map; |
| 11:03 |
jeff |
select count(*) from biblio.record_entry where not deleted; |
| 11:04 |
jeff |
jboyer-isl: in theory, those two should match. they do in our system. |
| 11:05 |
jboyer-isl |
jeff: given those queries mmsm has 223397 more entries than bre. |
| 11:05 |
jeff |
jboyer-isl: metabib.metarecord_source_map ties one or more biblio.record_entry rows to a metabib.metarecord row. |
| 11:06 |
jboyer-isl |
Provided their fingerprints match? I guess the structure of .metarecord didn't look like it aggregated things. |
| 11:06 |
jboyer-isl |
At least not at first glance. |
| 11:37 |
|
ericar joined #evergreen |
| 11:48 |
dbwells |
jboyer-isl: On what version are you seeing these metarecord issues? |
| 11:52 |
jboyer-isl |
dbwells: 2.5.2 |
| 11:53 |
dbwells |
jboyer-isl: metarecords didn't get much love in 2.5 since they weren't used by TPAC yet. That's changed in 2.6, and some bugs were fixed along the way. See 0872 for instance. |
| 11:54 |
dbwells |
I'm not sure if some of that would be worth backporting or not. |
| 11:55 |
jboyer-isl |
I'll check it out, thanks |
| 11:56 |
jboyer-isl |
dbwells++ |
| 11:56 |
dbwells |
All things considered, metarecords are fairly simple to rebuild from scratch if/when needed. |
| 11:59 |
jboyer-isl |
Are they not tied to re/ingests? I've only just begun looking into them this morning so I'm starting from 0 on them. |
| 12:00 |
dbwells |
Yes, but like many parts of a full reingest, they can be generated separately as well. |
| 12:03 |
Dyrcona |
quick_metarecord_map.sql still works and is fairly quick as far as that goes. |
| 12:03 |
dbwells |
Yes, was about to say something about that: Open-ILS/src/extras/import/quick_metarecord_map.sql |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:04 |
Dyrcona |
By "quick" I mean minutes, not hours. |
| 12:04 |
dbwells |
I wasn't sure if it was up to date or not, Dyrcona++ |
| 12:05 |
Dyrcona |
It seems to be thought the first insert gives me 0 0. |
| 12:06 |
dbwells |
I would expect that unless you had missing metarecords. |
| 12:07 |
Dyrcona |
Yeah, I didn't worry about it. |
| 12:07 |
Dyrcona |
"thought" should have "though" -- silly fingers. |
| 12:08 |
dbwells |
So a true "start-over" would mean emptying those tables, then running the quick map. I think. |
| 12:08 |
dbwells |
I nominate jboyer-isl to try it and let us know. |
| 12:09 |
dbwells |
;) |
| 12:09 |
jeff |
which is probably a good argument for any future "manual tuning" of metarecords to exist as overrides outside that table... maybe. |
| 12:17 |
|
john3213 joined #evergreen |
| 12:22 |
|
john3213 left #evergreen |
| 12:28 |
jboyer-isl |
As luck would have it we just got a test database server large enough to handle a full dump/restore of our production data. Maybe I'll try that out sometime. As for now though, I think I will give quick_metarecord_map.sql a looking-over. |
| 12:29 |
jboyer-isl |
Thanks! |
| 12:32 |
kmlussier |
remingtron: A question on the 2.6 features that need documentation. For the removal of open-ils.ingest service, does the removal of a service require documentation? |
| 12:33 |
kmlussier |
Or is there some documentation already that needs to be removed? |
| 12:34 |
remingtron |
kmlussier: I guess the task of that feature assignment would be to answer the second question. |
| 12:34 |
kmlussier |
remingtron: OK, then, I can sign up for that one. :) |
| 12:35 |
remingtron |
kmlussier: and maybe to consider what that service used to do and provide a note about how that is done now |
| 12:36 |
kmlussier |
remingtron: OK, then, I can do the investigation to get those questions answered. Thanks! |
| 12:36 |
remingtron |
kmlussier: thank you! |
| 12:37 |
dbs |
kmlussier: short answer: ingest is now done in the database itself, as soon as you insert a new bib or authority record |
| 12:37 |
dbs |
kmlussier: and the removal of a service should be documented in as much as one should disable or remove the service definition from opensrf.xml / opensrf_core.xml |
| 12:38 |
dbs |
(saves resources, possibly saves breakage) |
| 12:39 |
jeffdavis |
Has anyone run into an issue where a MARC record can't be saved because there are too many 856 tags? |
| 12:43 |
* phasefx |
saw one where there was a <controlfield tag=""/> that broke stuff |
| 12:44 |
eeevil |
jeffdavis: is it timing out? |
| 12:45 |
jeffdavis |
eeevil: That is my suspicion, but I haven't confirmed yet. |
| 12:46 |
kmlussier |
dbs: Thanks for the additional guidance. |
| 12:48 |
eeevil |
jeffdavis: ah ... might need an index in the uri area (search for existing uris, etc), but I didn't look just now |
| 12:48 |
kmlussier |
So that info was documented upgrade notes area of the release notes, which seems to be a good place for it. And it needs to be added to the official docs too? Since our docs are now carried over from release to release, I'm just worried it will continue to be there in the days of Evegreen 4.5 when people don't even remember what the open-ils.ingest service was. |
| 12:53 |
jeffdavis |
eeevil: adding indexes is a good idea, I'll play with that a bit |
| 13:00 |
|
hbrennan joined #evergreen |
| 13:03 |
dbs |
kmlussier: take a look at how postgresql does release notes: www.postgresql.org/docs/9.2/static/release.html -- could be a useful model |
| 13:26 |
|
montgoc1 joined #evergreen |
| 13:34 |
csharp |
dbs++ # agreed |
| 13:36 |
|
gsams joined #evergreen |
| 13:37 |
kmlussier |
dbs: I like the way it lists all of the past release notes on one page. I also like the notes for point releases. For a brief period, wasn't Evergreen doing notes for point releases? |
| 13:38 |
kmlussier |
I often get question on which bugs were fixed in a point release, so I think it could be useful. |
| 13:40 |
kmlussier |
@dessert |
| 13:41 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
| 13:41 |
kmlussier |
Ooh! Lucky me! Just what I need for the EOB meeting. |
| 13:44 |
|
bbqben joined #evergreen |
| 13:44 |
|
Shae joined #evergreen |
| 13:47 |
|
RoganH joined #evergreen |
| 13:49 |
|
abneiman joined #evergreen |
| 13:51 |
eeevil |
kmlussier: I did do point release notes back in the long-long ago. we tend to list bug fixes in the announcement, which is a start, I guess |
| 13:52 |
* kmlussier |
apparently doesn't read the announcements very closely. ;) |
| 13:53 |
kmlussier |
It probably would be fairly easy for the DIG release coordinator to take those announcements and turn them into point release notes. |
| 13:54 |
eeevil |
kmlussier: well ... "list" might be strong. I mentioned the areas where they occurred in the 2.4 releases. |
| 13:54 |
|
RoganH_ joined #evergreen |
| 13:56 |
hbrennan |
Since dwells started giving out awards, I've been paying closer attention to all the notes. Since receiving an award for reporting one bug, I'm hooked. It makes it more fun. |
| 13:56 |
bbqben |
Hi all - JFYI - EOB mtg starting here in 5 minutes |
| 14:02 |
|
sborger joined #evergreen |
| 14:03 |
|
ElizabethM joined #evergreen |
| 14:03 |
bbqben |
ok, let's get this rolling / see if I can avoid botching things this time. Morning/afternoon to you all |
| 14:03 |
bbqben |
#startmeeting Evergreen Oversight Board Meeting, 15.05.14 |
| 14:03 |
pinesol_green |
Meeting started Thu May 15 14:03:27 2014 US/Eastern. The chair is bbqben. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:03 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:03 |
pinesol_green |
The meeting name has been set to 'evergreen_oversight_board_meeting__15_05_14' |
| 14:03 |
bbqben |
#topic introductions |
| 14:03 |
bbqben |
EOB members, please introduce yourself with #info |
| 14:04 |
kmlussier |
#info Kathy Lussier, MassLNC |
| 14:04 |
bbqben |
#info bbqben = Ben Hyman, BC Libraries Co-op / Sitka |
| 14:04 |
sborger |
#info sborger=Shauna Borger, EI |
| 14:04 |
montgoc1 |
#info montgoc1 = Chauncey Montgomery, Consortium of Ohio Libraries |
| 14:04 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Kent County Public Library |
| 14:04 |
RoganH_ |
#info RoganH = Rogan Hamby, SCLENDS |
| 14:04 |
graced |
#info graced is Grace Dunbar, Equinox |
| 14:04 |
yboston |
#info yboston - Yamil Suarez, Berklee College of Music |
| 14:05 |
bbqben |
#topic Minutes/Actions from last meeting |
| 14:05 |
bbqben |
#info http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-17-14.02.html |
| 14:06 |
bbqben |
so, several pieces here; will break them down by topic |
| 14:06 |
bbqben |
#topic Terms of Reference - Establishment of Emergency Project Fund |
| 14:06 |
bbqben |
#info http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-May/000785.html |
| 14:07 |
bbqben |
one piece omitted in this draft - that the mascot might properly be the illuminated moose from our meeting room in Cambridge |
| 14:08 |
bbqben |
all good task groups need a mascot? |
| 14:08 |
bbqben |
any discussion on that or the actual draft? |
| 14:08 |
kmlussier |
bbqben: +1 |
| 14:09 |
kmlussier |
bbqben: I just thought of something that I hadn't thought of on my first read. Should we be identifying the scope of what the Emergency Fund might be used for? |
| 14:10 |
graced |
kmlussier: good point, that might be useful in focusing the process |
| 14:10 |
bbqben |
kmlussier: yes, perhaps as a recommendation at the end? In other words - we may discover that the scope is pre-determined along the way |
| 14:12 |
kmlussier |
Sure. I don't have much opinion on where in the process it falls. But if we don't define what might constitute an emergency, the funds may just sit there doing nothing or they might be used for frivolous things like purchasing a big illuminated moose for the conference. |
| 14:12 |
bbqben |
ok, so with that amendment (to revise the scope of recommendations to include commentary on the fund's purpose), lets see if I can whip up a vote for us unless anyone has further comment |
| 14:13 |
bbqben |
kmlussier: illuminated moose is not frivolous! |
| 14:13 |
kmlussier |
bbqben: I agree that it can be useful to encourage brainstorming. |
| 14:13 |
* gmcharlt |
has an idea for a debate panel at the next conference |
| 14:14 |
RoganH_ |
http://cdn.trendhunterstatic.com/thumbs/illuminated-faux-taxidermy-moose.jpeg |
| 14:14 |
graced |
and by debate panel, gmcharlt means "bar" |
| 14:14 |
|
Dyrcona joined #evergreen |
| 14:14 |
kmlussier |
bbqben: I'm prepared to vote in favor. |
| 14:14 |
bbqben |
#startvote Adopt the Terms of Reference for the investigation into the establishment of an Emergency Fund for the Evergreen Project, as amended Yes, No, Abstain |
| 14:14 |
pinesol_green |
Unable to parse vote topic and options. |
| 14:14 |
bbqben |
blech. syntax help pls |
| 14:15 |
graced |
bbqben: are you missing a "?" again? |
| 14:15 |
gmcharlt |
yep |
| 14:15 |
bbqben |
punctuation is so 1990's |
| 14:15 |
bbqben |
#startvote Adopt the Terms of Reference for the investigation into the establishment of an Emergency Fund for the Evergreen Project, as amended? Yes, No, Abstain |
| 14:15 |
pinesol_green |
Begin voting on: Adopt the Terms of Reference for the investigation into the establishment of an Emergency Fund for the Evergreen Project, as amended? Valid vote options are Yes, No, Abstain. |
| 14:15 |
pinesol_green |
Vote using '#vote OPTION'. Only your last vote counts. |
| 14:16 |
kmlussier |
Yes |
| 14:16 |
kmlussier |
#vote Yes |
| 14:16 |
sborger |
#vote Yes |
| 14:16 |
montgoc1 |
#vote Yes |
| 14:16 |
graced |
#vote Yes |
| 14:16 |
RoganH_ |
#vote Yes |
| 14:16 |
yboston |
#vote yes |
| 14:16 |
abneiman |
#vote yes |
| 14:16 |
bbqben |
#vote yes |
| 14:17 |
bbqben |
#endvote |
| 14:17 |
pinesol_green |
Voted on "Adopt the Terms of Reference for the investigation into the establishment of an Emergency Fund for the Evergreen Project, as amended?" Results are |
| 14:17 |
pinesol_green |
Yes (8): kmlussier, yboston, bbqben, graced, montgoc1, RoganH_, sborger, abneiman |
| 14:17 |
* kmlussier |
makes a note to add voting to the Evergreen wiki page with Meetbot commands |
| 14:17 |
bbqben |
#topic Conference Photography Proposal (Kathy) |
| 14:17 |
bbqben |
#info thread at http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-May/000748.html |
| 14:18 |
bbqben |
kmlussier: care to open? |
| 14:18 |
kmlussier |
I don't think there has been much disagreement on the text of the policy. Most of the questions have revolved around implementation and whether a speaker should be covered under the policy. |
| 14:20 |
RoganH_ |
My question at this point is what enforcement will the policy have? |
| 14:20 |
kmlussier |
Well, I guess the first question is whether willfully violating this policy would be considered a violation of the code of conduct. In some cases, it might be, but maybe not all. |
| 14:21 |
bbqben |
suggesting some discretion on the part of the organizing committee perhaps |
| 14:22 |
RoganH_ |
I don't have a strong objection to allowing speakers to opt in but I think violation is inevitable whether accidental or willingly and I think we have to know how we're going to handle it and outline it in the policy. |
| 14:22 |
kmlussier |
Do we need to add something that says, when there is a violation, a request will be made to take the photograph down. If the photograph isn't taken down, then more repercussions (banning from the conference) might be considered? |
| 14:22 |
kmlussier |
RoganH_: I think that type of scenario could happen with both speakers and attendees. |
| 14:23 |
graced |
Well, if the offense is caught on-site, then the person should be deleting the photograph from the device, too. |
| 14:23 |
RoganH_ |
kmlussier: I agree. |
| 14:23 |
bbqben |
agreement ++ ;) |
| 14:23 |
kmlussier |
graced: I agree. |
| 14:24 |
RoganH_ |
There needs to be an outline of escalation. Asking to delete, explaining policy and moving up to removal and/or ban from future events. |
| 14:24 |
graced |
I think that's a fair outline. |
| 14:24 |
montgoc1 |
That sounds good. |
| 14:24 |
RoganH_ |
That also helps protect us legally by outlining consequences. |
| 14:25 |
kmlussier |
OK, I can add that. |
| 14:25 |
graced |
And we should probably consider putting a slide up between presentations outlining the policy as a reminder. |
| 14:25 |
kmlussier |
I also haven't run this by the SFC other than including them in the original e-mail. I probably should get some feedback from them before it's approved. |
| 14:25 |
kmlussier |
graced: That's a good idea. |
| 14:25 |
yboston |
grace beat me to it, should we send a message to those in the next conference planning committee (and the proposed "standing" comittee) to ensure that the harrasment policy and photography policy be mentioned or posted in a clear way at the start of the ocnference or during registration. that way to better educate our community, and to help cut down on misunderstandings |
| 14:26 |
yboston |
*conference |
| 14:26 |
bbqben |
#action: kmlussier to discuss amended draft policy with SFC for next meeting |
| 14:26 |
kmlussier |
yboston: I've already spoken to the next conference planning group about getting the word out widely about the new policies. |
| 14:26 |
yboston |
kmlussier: excelent |
| 14:26 |
gmcharlt |
the proposal for a standing conference committee dovetails nicely with the possibility of having to enforce bans in the future |
| 14:27 |
bbqben |
Good convo - thanks everyone. More chance to discuss next meeting pending SFC feedback |
| 14:27 |
gmcharlt |
(unless the EOB choose not to delegate that particular responsiblity) |
| 14:27 |
|
geoffsams joined #evergreen |
| 14:27 |
bbqben |
#topic Reinstating Community IRC meetings (Kathy) |
| 14:28 |
kmlussier |
At the last meeting, there seemed to be a lot of support for reinstating the meetings. |
| 14:28 |
kmlussier |
I think the action item was for everyone to think of what might be covered at the meetings. |
| 14:29 |
kmlussier |
We had talked about how the old meetings ended up devolving into a one-hour timeframe where the different community groups delivered reports. |
| 14:29 |
kmlussier |
I would like to offer those community groups the opportunity to discuss or show something at the meeting, but perhaps not make it a standing agenda item for every group to report. |
| 14:30 |
kmlussier |
Did anyone else have some other ideas? |
| 14:31 |
montgoc1 |
I liked the idea that reports would be posted prior to the meeting. |
| 14:31 |
yboston |
montgoc1 +1 |
| 14:31 |
montgoc1 |
Then there could be discussion at the meeting. |
| 14:31 |
bbqben |
kmlussier; correct re: action items. One of the concerns was the devolution you reference - is there a way to sync the theme of the meetings with broader strategic initiatives underway (e.g. in a post-emergency fund established type world) |
| 14:31 |
yboston |
we can alwats ask the community if there are topics that poeple want to dicsuss |
| 14:32 |
sborger |
Not sure how this would actually work but it would be really valuable to talk about the most current Evergreen hot topics and then ask participants to give their local updates with regards to those topics. |
| 14:32 |
sborger |
Example: Acquisitions. Then we can ask participants to talk a bit about what they are currently doing with acquisitions. |
| 14:32 |
sborger |
yboston +1 |
| 14:33 |
abneiman |
sborger +1 |
| 14:33 |
kmlussier |
So this goes along with the theme idea that was mentioned at the last meeting? |
| 14:33 |
abneiman |
like how we have the interest groups at the conference -- what are you doing, what are your questions, but more than once a year |
| 14:33 |
sborger |
Yes, the theme idea is a good one. |
| 14:34 |
yboston |
we can suggest a few topics to the community and get votes to see which ones to cover at the first couple of meetings |
| 14:34 |
sborger |
abnieman Yes, that's exactly right. We get a lot out of sharing that information so let's try to do it more often. |
| 14:34 |
kmlussier |
But maybe the themes could be a little broader than a specific interest group area? |
| 14:34 |
bbqben |
I've lost the thread - were we thinking quarterly? or? |
| 14:35 |
kmlussier |
Because I'm thinking there are already interest groups meeting (well, one interest group) between conferences outside the context of community meetings. |
| 14:35 |
kmlussier |
I personally was thinkning quarterly. Monthly seems like it would be difficult. |
| 14:35 |
graced |
+1 to quarterly |
| 14:35 |
montgoc1 |
I think attendance would be better if it were quarterly. |
| 14:35 |
yboston |
on a related note, I was really enjoying the monthly EG newsletter. Perhpas we can promote that the interest group try to feed their reports more directly to those that are creating the newsletter |
| 14:36 |
abneiman |
I was under the impression that we were considered quarterly. And I'm certainly not opposed to broader topics. |
| 14:36 |
abneiman |
considering, rather |
| 14:36 |
montgoc1 |
yboston +1 |
| 14:36 |
bbqben |
quarterly, with pre-set themes for the year would enable cross promotion in the newsletter & maximum procrastination time too |
| 14:38 |
bbqben |
ok, so I'll invent an action here |
| 14:39 |
bbqben |
#action kmlussier et al to generate four themes / discuss by email before next eob meeting |
| 14:39 |
bbqben |
#topic Financial Report |
| 14:39 |
|
krvmga joined #evergreen |
| 14:39 |
bbqben |
#info http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-May/000772.html |
| 14:39 |
bbqben |
gmcharlt +1 |
| 14:40 |
krvmga |
here's a search http://bark.cwmars.org/eg/opac/results?query=moby+dick&fg%3Aformat_filters=6&qtype=keyword&locg=153&sort= |
| 14:40 |
krvmga |
i don't understand why the children's stuff shows up first |
| 14:40 |
kmlussier |
krvmga: We're in the middle of a meeting right now, but we'll be wrapping up in about 20 minutes. |
| 14:40 |
* krvmga |
apologizes |
| 14:40 |
bbqben |
JFYI - kmlussier has initiated her own access to ledger via SFC |
| 14:41 |
bbqben |
& thanks to gmcharlt for offering mind meld session / getting scheduling underway |
| 14:41 |
bbqben |
any q's / observations about the finances? |
| 14:41 |
bbqben |
kmlussier - books closed on the 2014 conference? |
| 14:42 |
kmlussier |
bbqben: I think so, but let me check on that. I'll let you know. |
| 14:42 |
|
mceraso joined #evergreen |
| 14:42 |
|
bshum joined #evergreen |
| 14:42 |
sborger |
I assume the graphic design expenses are to do with designing conference materials. Or are they design expenses for the t-shirts? |
| 14:43 |
RoganH_ |
The Zazzle tshirts? |
| 14:44 |
kmlussier |
sborger: If they included printing in there, that looks along the lines of what we did for the conference. |
| 14:45 |
abneiman |
Stupid question, but I've always wondered. Why are liabilities listed positive, and assets listed negative? |
| 14:45 |
gmcharlt |
abneiman: just the accounting convention that the ledger users |
| 14:45 |
gmcharlt |
*uses |
| 14:46 |
abneiman |
OK, thanks. |
| 14:46 |
bbqben |
abneiman: reverse accounting psychology |
| 14:46 |
bbqben |
ok, moving on |
| 14:46 |
bbqben |
#topic Evergreen 2.7 Release Manager's Report |
| 14:47 |
kmlussier |
bshum is in London. |
| 14:47 |
bbqben |
mmm ... bhsum away, IIRC |
| 14:47 |
bbqben |
London ++ |
| 14:48 |
bbqben |
sorry, heavily caffeinated today. anyone else care to comment on 2.7 or shall we move on? |
| 14:49 |
bbqben |
fair enough - we'll catch up on this next time |
| 14:49 |
bbqben |
#Topic Evergreen Conference Report(s) |
| 14:49 |
bbqben |
How are Buzzy and gang doing in Oregon? |
| 14:50 |
kmlussier |
Amy and I had a call with Buzzy a couple of weeks ago to hand things off. I'm pulling together lots of documents to send to him. |
| 14:50 |
kmlussier |
I think I forgot to mention that there are conference committee reports at the EOB meetings. |
| 14:51 |
bbqben |
Glad to hear the hand off has begun. kmlussier reminds me that I skipped a relevant topic so let's go there now |
| 14:51 |
bbqben |
#Topic Standing Conference Planning Committee Proposal |
| 14:52 |
bbqben |
#info http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-May/000787.html |
| 14:52 |
bbqben |
kmlussier, over to you |
| 14:52 |
|
mrpeters left #evergreen |
| 14:52 |
kmlussier |
The proposal's in the e-mail. Does it look good to everyone? |
| 14:52 |
yboston |
yes |
| 14:53 |
montgoc1 |
Yes |
| 14:53 |
graced |
yes |
| 14:53 |
bbqben |
marvelous |
| 14:53 |
abneiman |
yes |
| 14:54 |
sborger |
kmlussier +1 |
| 14:54 |
bbqben |
fair if we write up a terms of reference |
| 14:54 |
bbqben |
if not an insane idea, will make that an action |
| 14:54 |
sborger |
I think this will make a huge different for ease of local planning and consistancy between conferences. |
| 14:55 |
kmlussier |
A terms of reference might be good. But, if possible, can we begin recruiting for the standing committee now so that we can begin working with Buzzy and his crew as soon as possible? |
| 14:55 |
sborger |
bbqben What do you mean by terms of reference? |
| 14:56 |
bbqben |
kmlussier: works for me |
| 14:56 |
bbqben |
sborger: outlining the scope of the standing committee just to keep things clear for all parties, including the SFC |
| 14:56 |
sborger |
Thanks, sounds good. |
| 14:57 |
bbqben |
great, ok 2 actions then... |
| 14:57 |
bbqben |
#action kmlussier and graced to draft a Terms of Reference for a Standing Confernce Planning Committee |
| 14:57 |
bbqben |
#action call for volunteers for standing conference planning committee |
| 14:58 |
bbqben |
kmlussier: were you wanting to call for volunteers like _now_? |
| 14:58 |
krvmga |
i'm willing to volunteer. |
| 14:59 |
kmlussier |
Now, as in this IRC room? No. But I can send out an e-mail. |
| 14:59 |
kmlussier |
Maybe tomororw? |
| 14:59 |
bbqben |
kmlussier - ok. krvmga - thanks! |
| 15:00 |
bbqben |
conscious of time - yboston ok if we carry on the thread re: oclc records via mail? |
| 15:00 |
yboston |
sure |
| 15:00 |
bbqben |
yboston: thank you sir! |
| 15:01 |
|
Elizabeth joined #evergreen |
| 15:01 |
bbqben |
#topic Research if EG community can use OCLC records |
| 15:01 |
bbqben |
#action carry on conversation via mail |
| 15:01 |
bbqben |
#topic Next meeting |
| 15:02 |
bbqben |
I wondered whether we might like to meet by phone perhaps at the next (or the one after) regular meeting. |
| 15:02 |
bbqben |
I'll get a survey out next week to see what you think |
| 15:02 |
kmlussier |
bbqben: Out of curiousity, why by phone? |
| 15:03 |
bbqben |
kmlussier: thought you'd never ask! |
| 15:04 |
bbqben |
Came to my attention at the conference that some folks feel a little je ne sais quoi about IRC - just wanting to test the waters on that especially around strategic discussions, e.g. |
| 15:05 |
bbqben |
Obviously IRC provides a very full record of the conversation, and is totally inclusive - not wanting to sacrifice that, but perhaps go after some of the tonal qualities |
| 15:05 |
bbqben |
e.g. a recorded teleconference once / twice a year |
| 15:05 |
bbqben |
anyways, you asked. I'll survey :) |
| 15:05 |
krvmga |
and there could be a transcript anyway |
| 15:06 |
bbqben |
ok, unless there's no other business (in 10 seconds...) |
| 15:07 |
bbqben |
our next meeting is 19.06.14 @ 11 Pacific |
| 15:07 |
bbqben |
thanks all for coming out / have a great Thursday & here's hoping you maybe get Monday off |
| 15:07 |
bbqben |
#endmeeting |
| 15:08 |
pinesol_green |
Meeting ended Thu May 15 15:07:59 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:08 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-05-15-14.03.html |
| 15:08 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-05-15-14.03.txt |
| 15:08 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-05-15-14.03.log.html |
| 15:08 |
graced |
bbqben++ |
| 15:08 |
kmlussier |
bbqben: Do you get Monday off? |
| 15:08 |
kmlussier |
bbqben++ |
| 15:09 |
bbqben |
kmlussier; "off" - technically, it is a civic holiday here, but we're in the middle of our 13/14 audit, so ... how about you? |
| 15:09 |
kmlussier |
No holiday on this side of the border. :( |
| 15:09 |
kmlussier |
We get one the week after. |
| 15:10 |
RoganH_ |
Every day is a holiday for me. (not really) |
| 15:11 |
kmlussier |
RoganH_: Sure, I get that "always on a holiday" vibe from you. |
| 15:11 |
* RoganH_ |
starts looking for cerveza. |
| 15:12 |
bbqben |
RoganH_ ++ |
| 15:12 |
kmlussier |
A question for the devs in the room who didn't fall asleep during the EOB meeing. Do you think it would be a problem to change the dev meeting from Monday to Tuesday at the same time? |
| 15:13 |
Dyrcona |
I can't guarantee that I can make a Tuesday meeting. |
| 15:13 |
kmlussier |
I chose Monday because it was the best day when all of the core commiters could attend. But it turns out one core commiter couldn't make the Monday meeting, so I was thinking of switching to a day that worked for more people. |
| 15:13 |
Dyrcona |
We have executive and membership annual meetings that day. |
| 15:14 |
kmlussier |
Dyrcona: Ok, then I'll stick with Monday since you are a core commiter too. |
| 15:15 |
RoganH_ |
I'll throw out that if someone is thinking about hosting the Hack-A-Way I encourage them to come forth. I have one tentative offer and while the locale is great it may be a way off for a lot of folks. |
| 15:19 |
csharp |
one does not simply host the Hack-A-Way |
| 15:19 |
csharp |
RoganH_: how far away? (or is that secret at the moment?) |
| 15:20 |
RoganH_ |
It's not public knowledge since it's a tentative offer. It's a great place and great folks but a long trip for many. |
| 15:25 |
krvmga |
ok, back to my question. why do the children's materials show up first in this search of our catalog http://bark.cwmars.org/eg/opac/results?query=moby+dick&fg%3Aformat_filters=6&qtype=keyword&locg=153&sort= |
| 15:25 |
krvmga |
i can't figure it out |
| 15:25 |
krvmga |
it's a search for moby dick |
| 15:25 |
kmlussier |
krvmga: The bib records look small. |
| 15:26 |
kmlussier |
krvmga: http://markmail.org/message/ykzdejpb735t33t2 |
| 15:27 |
krvmga |
kmlussier: i see the question has not been answered for over two years. |
| 15:27 |
kmlussier |
krvmga: The question was answered. |
| 15:27 |
krvmga |
whoops! sorry missed that. |
| 15:28 |
kmlussier |
krvmga: I don't know the best way to address that issue, but I don't advise changing those CD_modifiers settings. We did it on your system for a brief period, and it resulted in terrible relevance ranking for most of your searches. |
| 15:29 |
* kmlussier |
can give you more details if you want to walk over to her desk. :) |
| 15:35 |
|
edoceo joined #evergreen |
| 15:39 |
jboyer-isl |
Speaking of mysteries; Re: my earlier metabib.metarecord strangeness from this morning, it seems that this record simply will not populate metabib.record_attr no matter what: https://evergreen.lib.in.us/eg/opac/record/20155257?expand=marchtml#marchtml |
| 15:41 |
jboyer-isl |
I've changed the reingest_on_same_marc (or similar) flag and triggered it by hand, edited it in the staff client, etc. nothing works. The annoying result is that in the client you can select Search, Title by TCN and pull it up, but TCN searching in the OPAC is a no-go. |
| 15:41 |
jeff |
jboyer-isl: is there no row for that bib in mra? |
| 15:42 |
jboyer-isl |
jeff: Nope. |
| 15:42 |
jeff |
jboyer-isl: i believe if you've gotten into a situation where the bib exists but the mra row has somehow been deleted, it will not be re-created (only updated if it already exists) |
| 15:43 |
kmlussier |
phasefx: You raise an interesting question. Would the patron have to see "PATRON_EXCEEDS_FINES" or could it be offered in more user friendly language? |
| 15:43 |
jboyer-isl |
So I could insert a bogus set of attrs and then save the record, perhaps? |
| 15:43 |
phasefx |
kmlussier: if the age protected item wasn't there, Patron A would have seen "Patron has reached the maximum fine amount" |
| 15:44 |
phasefx |
kmlussier: but the other error message is trumping that error message |
| 15:44 |
jeff |
jboyer-isl: yes, or even a null value in the attrs column (can't remember if it can be null) |
| 15:44 |
jboyer-isl |
Trying it out as we type. (''::HSTORE also works) |
| 15:45 |
|
gsams joined #evergreen |
| 15:45 |
kmlussier |
It's an interesting question to ponder. My knee jerk reaction was that patrons don't want to see a big list of reasons, but I'm reconsidering. |
| 15:46 |
* csharp |
thinks end users get confused if you get too specific about reasons |
| 15:46 |
jboyer-isl |
jeff: ah-ha. That does allow it to populate. Now to see if it helps searching at all. |
| 15:46 |
phasefx |
maybe we can come up with a simple hierarchy of errors, or some heuristic for emphasizing one over another |
| 15:46 |
csharp |
(despite the innate librarian urge to communicate via signs, etc.) |
| 15:47 |
phasefx |
but that might be a rabbit hole |
| 15:47 |
kmlussier |
phasefx: In that world, it seems like age hold protected messages should come last in the hierarchy. |
| 15:47 |
phasefx |
yet this whole set of functionality was a reaction to folks not liking the "hold failed, go see a librarian" thing |
| 15:47 |
eeevil |
jboyer-isl: sounds like you might be missing a fix ... I thought I added some protection against re-vivicated records losing their record_attr row |
| 15:47 |
kmlussier |
csharp / phasefx: I think staff would find it useful to see a list of reasons. |
| 15:48 |
phasefx |
kmlussier: or non-item specific failures should come first |
| 15:48 |
kmlussier |
phasefx: Yes, I agree. |
| 15:48 |
* csharp |
wonders if a "for details click here" link would be appropriate |
| 15:48 |
jeff |
eeevil: ah. i couldn't remember if there was a fix, or even a bug on it. |
| 15:48 |
eeevil |
(or, if not, you can make sure all have one pretty easily) |
| 15:48 |
phasefx |
kmlussier: in the case of the age protect failure, that failure was just on one item, and didn't apply to other items. And since the hold was a title hold, and not an item hold, it's very misleading |
| 15:49 |
eeevil |
jeff: it may not have hit LP, actually. just rolled into a larger fix |
| 15:49 |
* jeff |
nods |
| 15:49 |
jboyer-isl |
eeevil: depends on where it fell in the upgrade scripts. I recently had to add 6 or 7 in the 084X range recently. |
| 15:49 |
jboyer-isl |
And I've apparently graduated from the department of redundancy department. |
| 15:50 |
eeevil |
jboyer-isl: oh, it's much earlier than that ... if I'm not mis-remembering |
| 15:51 |
kmlussier |
phasefx: So if age protect failure came last, it wouldn't show in that particular situation because the old would go through? |
| 15:51 |
kmlussier |
Unless there was another reason to block the hold, which would have come first. |
| 15:52 |
jboyer-isl |
eeevil: Not all of our upgrade patches over the years have been applied 100% in order... :/ |
| 15:52 |
|
vlewis joined #evergreen |
| 15:53 |
jboyer-isl |
It's been frustrating to determine what is and isn't a problem vs. our problem. |
| 15:53 |
phasefx |
kmlussier: I'm not sure if the reason the age failure is showing over the fines failure is due to order of the results, or the "kind" of result in the error message map file. Patron B, when placing the hold, ultimately succeeded, even though Item A resulted in a age failure, Item B was fine. But Patron B, couldn't get either Item A or Item B, and all the failure reasons got pooled together |
| 15:53 |
* Dyrcona |
sympathizes with jboyer-isl. |
| 15:53 |
phasefx |
kmlussier: sorry, Patron A, couldn't get either, I mean |
| 15:54 |
* Dyrcona |
just figured out one of those "a problem vs. our problem" things. |
| 15:54 |
eeevil |
kmlussier: I looked into this earlier, and it seems order is less important than "type" ... IOW, some things are dealt with in the DB, some in the ML , and some just reported by the UI |
| 15:54 |
Dyrcona |
It was our problem. |
| 15:54 |
phasefx |
kmlussier: for Patron A, we have Item A -> age failure, fine failure, Item B -> fine failure. entire hold placement attempt was a failure, and all reasons were returned, but the UI only showed the age failure |
| 15:54 |
mmorgan |
phasefx: kmlussier: Trying to catch up on the scrollback. I think it's useful for patrons to know why their hold failed, but I'm not sure they would want to see a long list of reasons. |
| 15:54 |
phasefx |
kmlussier: for Patron B, we have Item A -> age failure, Item B -> success. entire hold placement attempt was a success |
| 15:55 |
jboyer-isl |
Dyrcona: I was curious about how that would end up. How was it fixed? |
| 15:55 |
Dyrcona |
jboyer-isl: This is something else. :) |
| 15:55 |
jboyer-isl |
(Or is this not the maketext thing?) |
| 15:55 |
jboyer-isl |
Ah. |
| 15:55 |
Dyrcona |
The maketext thing seems resolved by berick's code. |
| 15:56 |
Dyrcona |
I just figured out and fixed why our manage authorities screen looked like this: https://jason.mvlcstaff.org/manage_authorities.png |
| 15:56 |
* kmlussier |
likes the idea of a hierarchy of errors. |
| 15:56 |
Bmagic |
Off the top of your head, does anyone know the table in the database that contains "Library Settings" |
| 15:57 |
mmorgan |
So with a hierarchy of errors, would the patron see only one? |
| 15:57 |
kmlussier |
If that were a plausible option, I would vote for that one. If not, then maybe csharp's "more details" link might work? |
| 15:57 |
berick |
Bmagic: actor.org_unit_setting has the values |
| 15:57 |
Dyrcona |
Bmagic: actor.org_unit_setting and config.org_unti_setting_type |
| 15:57 |
* Dyrcona |
prefers a confederacy of dunces. :) |
| 15:58 |
berick |
Dyrcona++ maketext testing |
| 15:58 |
Bmagic |
berick++ Dyrcona++ |
| 15:58 |
|
bbqben joined #evergreen |
| 15:59 |
kmlussier |
Did the ESI quassel server just crash? |
| 15:59 |
yboston |
Dyrcona: I am late to the gane, what was it that fixed the issue? |
| 16:00 |
Dyrcona |
yboston: I didn't say. :) |
| 16:00 |
jboyer-isl |
It was an impressive error, I must say. |
| 16:00 |
Dyrcona |
We had some lines in Apache config that we didn't need any longer and it was affecting /eg/cat/authority. |
| 16:00 |
phasefx2 |
kmlussier: mmorgan: before losing internet, I was saying maybe we need to emphasize the errors held in common across all items testef |
| 16:00 |
Dyrcona |
yboston: You saw the screenshot above? |
| 16:01 |
|
gsams joined #evergreen |
| 16:01 |
yboston |
Dyrcona: yes, and it the issue was shown in the authoriites meeting |
| 16:01 |
Dyrcona |
yboston: I don't think anyone else had seen that on their systems though. |
| 16:02 |
kmlussier |
phasefx2: And it would still just show one error, right? |
| 16:02 |
yboston |
Dyrcona: then again, not a lot of people are using authoritites |
| 16:02 |
|
ericar joined #evergreen |
| 16:02 |
Dyrcona |
yboston: I don't think anyone else will see it. It was something that was not working at one point, so we added some apache config to "fix" that. |
| 16:03 |
|
Callender joined #evergreen |
| 16:03 |
|
tfaile joined #evergreen |
| 16:03 |
yboston |
Dyrcona: good to knoe |
| 16:03 |
yboston |
know |
| 16:03 |
Dyrcona |
yboston: Later, when the problem was resolved, the apache config made the view come out scrambled. |
| 16:03 |
yboston |
Dyrcona: I see |
| 16:03 |
mmorgan |
phasefx2: trying to understand. If there are a number of age protected items, and only one patron exceeds fines, and we were emphasizing common errors, would it be the age protection that shows? |
| 16:03 |
|
BigRig joined #evergreen |
| 16:03 |
mmorgan |
Because that's misleading to the patron. |
| 16:03 |
kmlussier |
phasefx2: Or are you saying it would provide a list, but just show the errors that are across all items? |
| 16:04 |
phasefx2 |
Phone typing = painful :) |
| 16:04 |
mmorgan |
Ouch! |
| 16:04 |
Dyrcona |
phasefx2: Indeed! |
| 16:04 |
kmlussier |
mmorgan: No, I don't think he said we are emphasizing common errors. We would emphasize the ones that apply to all copies. Like exceeding max fines. |
| 16:05 |
mmorgan |
Ok, makes sense. |
| 16:05 |
* kmlussier |
is trying to speak for phasefx2 so that he doesn't have to type on the phone. |
| 16:05 |
phasefx2 |
Right now, age protect failure reason trumps fine failure reason for display |
| 16:06 |
|
phasefx joined #evergreen |
| 16:06 |
kmlussier |
phasefx: Welcome back! |
| 16:06 |
|
mtate joined #evergreen |
| 16:06 |
phasefx |
we could hard-code some exception to that, so that fine exception displays over age exception, but it's not elegant, and wouldn't cover any other cases in the same vein that might crop up |
| 16:07 |
phasefx |
thanks :) |
| 16:07 |
mmorgan |
Actually, this is more complicated. In our situation, age protect shouldn't be a failure at all. |
| 16:07 |
phasefx |
and, I'm not familiar with that code at all, so don't know how hairy it might really be |
| 16:08 |
kmlussier |
mmorgan: Because you have the auto-override setting set to True? |
| 16:08 |
phasefx |
mmorgan: yeah, it's really the fines reason that failed the entire hold for your test patron |
| 16:08 |
mmorgan |
kmlussier: Yes |
| 16:08 |
phasefx |
but the way it works now, is that all the failure reasons come across the wire, if the hold fails altogether |
| 16:08 |
phasefx |
and the UI picks one over another |
| 16:09 |
phasefx |
so one thought is that maybe the only failure reasons we should send over the wire are the ones held in common across all the items that were tested for the hold |
| 16:09 |
phasefx |
so in the example, only the fines one would get sent |
| 16:10 |
phasefx |
but let's say it was fines and long overdue... the UI as written today will still pick only one to display |
| 16:10 |
phasefx |
but, at least either would make sense |
| 16:11 |
phasefx |
it's only the failures that happen for a subset of the items tested that don't make sense |
| 16:11 |
mmorgan |
phasefex: Right. |
| 16:12 |
kmlussier |
phasefx: So let's say you only send reasons that are held in common across all items. What happens in a case where a patron is trying to place a hold on a title where all of the items are in a copy location, like reference, that doesn't allow holds? They have no other problems on their record that would prevent the hold. |
| 16:12 |
kmlussier |
Would they get a reason for the hold failing? |
| 16:12 |
phasefx |
yes |
| 16:12 |
phasefx |
well |
| 16:12 |
phasefx |
I see what you did there |
| 16:13 |
phasefx |
let's say all items fail, but for different reasons |
| 16:13 |
phasefx |
that's a situation that breaks my idea |
| 16:13 |
kmlussier |
Yes, they are all copy-specific reasons. |
| 16:13 |
phasefx |
it's like we'd need a meta-event to handle that one |
| 16:13 |
phasefx |
No Eligible Items |
| 16:16 |
kmlussier |
I hate to throw another monkey wrench in to it, but then you have those age-protected items where patrons are allowed to override the hold block, but the system may not have that auto-override setting set. If all of the items on the record are age-protected, and that's the only issue with the hold, would they still get the option to override? |
| 16:16 |
phasefx |
so back to the hierarchy notion.. some events would get precedence over others for being displayed. how workable that is, I don't know |
| 16:17 |
kmlussier |
Holds make my head hurt. Along with authorities and billing. |
| 16:17 |
mmorgan |
I'm thinking about displaying more than one failure reason for a hold, or making them all available in a link. I don't think that's a bad idea. |
| 16:17 |
phasefx |
kmlussier: I'm not proposing any changes to how overrides work. You're asking about current behavior? |
| 16:18 |
mmorgan |
If you only display one, then the patron (and staff) may think that's the only thing they need to resolve. |
| 16:18 |
phasefx |
that's always been an issue |
| 16:18 |
phasefx |
say, in the staff client for other actions |
| 16:19 |
kmlussier |
phasefx: No, I'm not asking about current behavior. I'm just wondering if the picking which reasons to send down the wire approach would change that behavior. |
| 16:19 |
phasefx |
and related, you end overriding everything if you have permission too, and you may not be aware of all the conditions you're overriding |
| 16:20 |
phasefx |
kmlussier: yeah, I'm not sure how it works exactly currently, so I don't know how some of these ideas might affect things |
| 16:20 |
phasefx |
one reason why I thought it might be a thorny problem |
| 16:20 |
mmorgan |
OK, so if you have multiple failure reasons, and have permission to override one but not another, you get the "You have permission...", then hit the override, and nothing happens. |
| 16:21 |
phasefx |
is that what happens? ughers |
| 16:21 |
* mmorgan |
has seen this behavior, and wonders if this is why |
| 16:22 |
* mmorgan |
's head hurts, too. |
| 16:22 |
kmlussier |
@dessert mmorgan |
| 16:22 |
* pinesol_green |
grabs some Lemon Chess Pie for mmorgan |
| 16:22 |
csharp |
mmmm pie |
| 16:23 |
csharp |
@dessert |
| 16:23 |
* pinesol_green |
grabs some Mint Chocolate Chip Ice Cream for csharp |
| 16:23 |
mmorgan |
kmlussier: Thank you! |
| 16:24 |
mmorgan |
dessert cures many ills :) |
| 16:24 |
kmlussier |
csharp: So should I be adding Lemon Chess Pie to my list of things to try the next time I visit Atlanta? Along with fried chicken and waffles, which I missed out on during my last trip. |
| 16:24 |
csharp |
kmlussier: Chess Pie of any variety, yes. I actually prefer straight-up Chess Pie myself ;-) |
| 16:24 |
phasefx |
kmlussier: mmorgan: so right now, all failure events are trumping the PATRON_EXCEEDS_FINE event for display. We could reverse the order of that test, and let exceeds fine trump everything else :) |
| 16:25 |
phasefx |
that looks relatively simple |
| 16:25 |
csharp |
America's Test Kitchen's home cookbook has a great recipe for it, btw - it's very easy (as pie baking goes) |
| 16:25 |
phasefx |
well, almost all. if something isn't coded for in the error map, I'm not sure what happens to it |
| 16:25 |
kmlussier |
But what about events like exceeding overdue count or others that apply to all copies? |
| 16:26 |
mmorgan |
Seems like failures due to blocks on the patron should be more important, and trump failures due to items |
| 16:26 |
phasefx |
I don't think there's an explicit friendly message for any of the other standing penalties |
| 16:26 |
phasefx |
so that would be a hierarchy |
| 16:26 |
csharp |
kmlussier: http://www.takingonmagazines.com/lemon-chess-pie-from-cooks-country-aprilmay-2010/ is pretty close to what I've made before |
| 16:27 |
kmlussier |
csharp: ooh! That looks tasty. |
| 16:27 |
phasefx |
but maybe not so trivially implemented. some of the patron based events are coming from the hold matrix, and others are coming from penalties |
| 16:28 |
phasefx |
if a hold matrix rule causes a failure, it's not apparent what in the rule caused it |
| 16:29 |
hbrennan |
csharp++ for sharing recipes |
| 16:29 |
phasefx |
could be item related, org related, patron related.. combination |
| 16:29 |
mmorgan |
So holds can fail because the patron is blocked, because of a hold matrix rule, and because of some characteristic of the item. |
| 16:30 |
mmorgan |
And the failure reasons come through in what order? Is it random? |
| 16:30 |
phasefx |
maybe in part, where it loops over items |
| 16:32 |
phasefx |
and there are two maps in hold_error_messages.tt2, FAIL_PART_MSG_MAP and EVENT_MSG_MAP. The first gets precedence over the second (and the second is where PATRON_EXCEEDS_FINES is defined/translated) |
| 16:32 |
mmorgan |
If a patron is blocked, and can't place a hold at all, does it still loop over all the items? Sounds like it does. |
| 16:33 |
phasefx |
let's say something is handled by FAIL_PART_MSG_MAP.. I'm not sure if it's the first event or the last event in the list of failure events that get returned |
| 16:33 |
phasefx |
mmorgan: I think that's a true statement |
| 16:34 |
phasefx |
and then if you override, it's looping through all the events, and testing for related .override permissions on each one |
| 16:35 |
mmorgan |
Doesn't seem very efficient ;-) |
| 16:35 |
phasefx |
this stuff evolves :) the tests used to be javascript, and it was efficient enough for a while |
| 16:36 |
phasefx |
then the move to in-db circ; much faster, but maybe room for improvement still |
| 16:36 |
kmlussier |
Patron Exceeds Fines is the only event in EVENT_MSG_MAP? Am I reading that right? |
| 16:36 |
phasefx |
of course, if we could get rid of all the flexibility, we could make it very efficient :D |
| 16:37 |
phasefx |
kmlussier: yeap |
| 16:37 |
phasefx |
so you'd have to add entries for other standing penalties to get them translated. I'm not sure what happens if an event not listed is returned |
| 16:38 |
phasefx |
looks like it'll eventually just return the raw fail_part or event textcode |
| 16:38 |
mmorgan |
Where is EVENT_MSG_MAP? |
| 16:38 |
phasefx |
so, if PATRON_EXCEEDS_FINE wasn't listed there, you'd actually see "PATRON_EXCEEDS_FINES" |
| 16:38 |
kmlussier |
phasefx: That's what I was thinking. But it should be easy enough for one of us to test. |
| 16:39 |
kmlussier |
You can see it in the hold_error_messages.tt2 file. I'm looking at it here: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/templates/opac/parts/hold_error_messages.tt2;h=50a0ebff941e408770ce5b9f970ca61d6266563f;hb=HEAD |
| 16:39 |
phasefx |
would probably be an improvement to show the event's native description rather than the textcode at that point |
| 16:39 |
mmorgan |
Oh, ok, it's in the .tt2 file. Duh. |
| 16:40 |
phasefx |
place_hold_result.tt2 is where hold_error_messages.tt2 actually gets used |
| 16:40 |
phasefx |
search for Problem: in that file |
| 16:42 |
kmlussier |
phasefx: Is improving the language just a matter of adding PATRON_EXCEEDS_LOST_COUNT => l("Patron has reached the maximum number of lost items") to that tt2 file? Or is it more complicated than that? |
| 16:42 |
phasefx |
kmlussier: that should do it |
| 16:43 |
phasefx |
kmlussier: with a comma between entries |
| 16:43 |
kmlussier |
Wow! That's something even I could handle. But it strays from the original question. :) |
| 16:43 |
phasefx |
kmlussier: and, of course, you should edit a copy of that file in a custom template folder |
| 16:43 |
mmorgan |
I would love to change the "Patron has..." parts of those messages. |
| 16:44 |
mmorgan |
Seems like an easily maintainable customization that would mean a big improvement in placing holds. |
| 16:45 |
kmlussier |
Well, I was thinking some standard, stock penalties could be added there and contributed to core. It seems like something others might benefit from. |
| 16:45 |
mmorgan |
Yes, that too! |
| 16:46 |
kmlussier |
phasefx: I think it makes sense for the EVENT_MSG_MAP failures to come first. |
| 16:46 |
kmlussier |
Well, currently, I guess it would be failure, but maybe we can add some more to make it a little more useful. |
| 16:47 |
eeevil |
kmlussier / mmorgan: (almost got to send this before the internet outage at the office...) this is all related to what I was mentioning yesterday, about a bigger project to rework all the circ and hold failure reporting so that all layers of the stack could react appropriately (and it would be easier to, say, add new failure reasons, a la Bmagic's standing penalty thing from earlier) |
| 16:48 |
eeevil |
there's no simple change that will please all in every situation, AFAICT ... with the current mapping of events |
| 16:49 |
kmlussier |
eeevil: Yes, but I'm guessing that's a much larger project. I would like to see it, but maybe this could improve things a little bit in the meantime. |
| 16:50 |
eeevil |
kmlussier: likely, sure. maybe moving things between maps would be enough for the short term (though, I'm not sure there wouldn't be other implications) |
| 16:56 |
kmlussier |
@hate scheduling meetings |
| 16:56 |
pinesol_green |
kmlussier: The operation succeeded. kmlussier hates scheduling meetings. |
| 16:56 |
mmorgan |
@dessert kmlussier |
| 16:57 |
* pinesol_green |
grabs some banana split for kmlussier |
| 16:58 |
* mmorgan |
has acquired some knowlege today! |
| 16:58 |
mmorgan |
kmlussier++ phasefx++ |
| 17:16 |
|
akilsdonk_ joined #evergreen |
| 17:18 |
|
mmorgan left #evergreen |
| 17:18 |
|
eby__ joined #evergreen |
| 17:21 |
|
wjr_ joined #evergreen |
| 17:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:31 |
|
kmlussier left #evergreen |
| 17:37 |
|
RBecker joined #evergreen |
| 18:06 |
|
phasefx_ joined #evergreen |
| 18:07 |
|
tfaile_ joined #evergreen |
| 18:07 |
|
Callender_ joined #evergreen |
| 18:08 |
|
BigRig_ joined #evergreen |
| 18:10 |
|
mtate joined #evergreen |
| 19:02 |
|
kmlussier joined #evergreen |
| 19:33 |
|
rangi joined #evergreen |
| 19:37 |
|
dcook joined #evergreen |
| 20:11 |
hbrennan |
Arg. Who knows what permission is needed to edit Library Settings? I can't find it... |
| 20:19 |
hbrennan |
I feel like I'm close, but this is perplexing .... |
| 20:19 |
hbrennan |
UPDATE_ORG_SETTING. Allow a user to update an organization unit setting |
| 20:19 |
hbrennan |
vs |
| 20:19 |
hbrennan |
UPDATE_ORG_UNIT. Allow a user to change the settings for an organization unit |
| 20:20 |
hbrennan |
Settings for an org unit vs. org unit setting.... |
| 20:28 |
eeevil |
hbrennan: you want the former. the latter is for changing the name, can_have_users, etc |
| 20:29 |
* eeevil |
disappears in a puff of smoke |
| 20:29 |
hbrennan |
Gracias, eeevil. |
| 20:29 |
hbrennan |
:) |
| 20:29 |
hbrennan |
eeevil++ # for acting like a superhero |
| 21:39 |
jeff |
reading the "acting like a superhero" comment first, I then read hbrennan's "Who knows what" line a la "Who knows what evil lurks in the hearts of men? The Shadow knows..." |
| 21:39 |
hbrennan |
Haha |
| 21:39 |
hbrennan |
I often read IRC backwards and find fun things |
| 21:40 |
jeff |
I still hear people's voices in my head as I read their words in IRC. It's stronger just after seeing people in person or talking to them on the phone, but is seeming to become a permanent thing. |
| 21:41 |
hbrennan |
I love conferences for that reason |
| 21:41 |
hbrennan |
So much easier to keep track of who's who |
| 21:42 |
hbrennan |
Though there are a few people who are so much more outgoing on here, you'd never put their real self with their IRC personality |
| 21:44 |
* jeff |
nods |
| 21:44 |
jeff |
and the reverse -- many people at the conference never make an appearance on irc, or rarely say anything if/when they do. |
| 21:45 |
jeff |
nothing wrong in either case, of course. |
| 21:46 |
|
berick joined #evergreen |
| 21:51 |
jeff |
dbwells++ pullrequests against iNCIPit |
| 21:53 |
hbrennan |
oh, that reminds me dbwells++ for coming up with not one but TWO solutions on how to get around my serials bug |
| 21:56 |
hbrennan |
Welp, my arm is burning hot from the sun so it must be 6! |
| 21:56 |
hbrennan |
Until tomorrow everyone |
| 22:24 |
|
ningalls joined #evergreen |
| 22:25 |
|
BigRig joined #evergreen |
| 22:26 |
|
tfaile joined #evergreen |
| 22:26 |
|
Callender joined #evergreen |
| 22:27 |
|
RBecker joined #evergreen |
| 22:27 |
|
RBecker joined #evergreen |
| 22:28 |
|
phasefx joined #evergreen |
| 22:29 |
|
mtate joined #evergreen |
| 22:54 |
|
MilkWhistle joined #evergreen |
| 22:54 |
|
MilkWhistle left #evergreen |
