| Time |
Nick |
Message |
| 02:05 |
|
wjr joined #evergreen |
| 05:25 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:03 |
|
collum joined #evergreen |
| 08:08 |
|
ericar joined #evergreen |
| 08:09 |
|
akilsdonk joined #evergreen |
| 08:27 |
|
Dyrcona joined #evergreen |
| 08:30 |
|
mrpeters joined #evergreen |
| 08:44 |
|
tspindler joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:47 |
|
jwoodard joined #evergreen |
| 08:49 |
|
kbeswick joined #evergreen |
| 09:08 |
|
collum joined #evergreen |
| 09:10 |
|
Stompro joined #evergreen |
| 09:23 |
|
Shae joined #evergreen |
| 09:24 |
|
book` joined #evergreen |
| 09:52 |
|
kmlussier joined #evergreen |
| 10:09 |
|
rjackson-isl joined #evergreen |
| 10:34 |
|
jwoodard joined #evergreen |
| 10:56 |
|
remingtron joined #evergreen |
| 11:17 |
|
ericar joined #evergreen |
| 11:27 |
mrpeters |
anyone else hit upon this when upgrading 2.5.3 > 2.6.0? |
| 11:28 |
mrpeters |
http://pastie.org/9261348 |
| 11:29 |
mrpeters |
it appears i don't have an "evergreen.located_uris" schema |
| 11:30 |
mrpeters |
err, table |
| 11:31 |
mrpeters |
yikes, looks like thats from 2.1>2.2 |
| 11:31 |
dbwells |
That error isn't a missing table, but a missing function. |
| 11:32 |
mrpeters |
yeah, i see that now |
| 11:32 |
mrpeters |
but, i do have it |
| 11:32 |
mrpeters |
http://pastie.org/9261361 |
| 11:34 |
dbwells |
Not sure, maybe a search_path issue? |
| 11:36 |
remingtron |
is it a problem of nonmatching function params? |
| 11:36 |
remingtron |
looking for: located_uris(bigint, integer, integer) |
| 11:36 |
remingtron |
but you have: (id bigint, name text, label_sortkey text, rank integer) |
| 11:36 |
dbwells |
no, that's what it returns |
| 11:36 |
remingtron |
ah, right |
| 11:38 |
dbwells |
~search_path |
| 11:38 |
pinesol_green |
When restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 11:39 |
Dyrcona |
Search path don't work during a restore because of the way schemas are used. |
| 11:39 |
Dyrcona |
After a restore, if you remember to rest it, yeah. |
| 11:39 |
Dyrcona |
s/rest/reset/ |
| 11:40 |
dbwells |
Yeah, I think that's what the tip is trying to say. |
| 11:40 |
dbwells |
Should probably say "After restoring..." |
| 11:40 |
dbwells |
@blame csharp |
| 11:40 |
pinesol_green |
dbwells: csharp is why we can never have nice things! |
| 11:41 |
dbwells |
:) |
| 11:42 |
dbwells |
If I were smart enough to fix it, I would. |
| 11:42 |
bshum |
~no search_path is After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 11:42 |
pinesol_green |
I'll remember that bshum |
| 11:42 |
bshum |
~search_path |
| 11:42 |
pinesol_green |
search_path is After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 11:43 |
bshum |
Hmm |
| 11:43 |
bshum |
Not quite what I was aiming for |
| 11:43 |
dbwells |
bshum: can anyone do the ~no command? I think you want <reply> before "After" |
| 11:43 |
bshum |
dbwells: Yeah that's what I was just reading up |
| 11:44 |
bshum |
The ~no is a prefix to replace the contents of a given note |
| 11:44 |
bshum |
You just need to be registered with the bot and marked as an editor of the encyclopedia plugin |
| 11:44 |
bshum |
~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 11:44 |
pinesol_green |
I'll remember that bshum |
| 11:44 |
bshum |
~search_path |
| 11:44 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 11:44 |
bshum |
dbwells++ |
| 11:44 |
dbwells |
bshum++ thanks |
| 11:49 |
mrpeters |
evergreen=# alter database evergreen set search_path = 'evergreen, public, pg_catalog'; |
| 11:49 |
mrpeters |
NOTICE: schema "evergreen, public, pg_catalog" does not exist |
| 11:49 |
mrpeters |
. |
| 11:50 |
mrpeters |
is that the right syntax for multiple schemas? |
| 11:51 |
mrpeters |
ALTER DATABASE evergreen SET search_path TO evergreen, public, pg_catalog; |
| 11:52 |
mrpeters |
if you want to fix pinesol :) |
| 11:54 |
mrpeters |
ew - ERROR: cannot ALTER TABLE "record_entry" because it has pending trigger events -- that should be fun |
| 11:55 |
mrpeters |
easy in a test db, maybe more tricky in production |
| 12:02 |
|
kmlussier joined #evergreen |
| 12:25 |
bshum |
mrpeters: = worked fine for me the other day, over TO |
| 12:25 |
bshum |
Maybe it's a version thing. |
| 12:26 |
bshum |
Or how the command was issued |
| 12:26 |
mrpeters |
maybe |
| 12:27 |
Dyrcona |
mrpeters: try it at night when no one should be cataloging. |
| 12:27 |
mrpeters |
Dyrcona: its a test db |
| 12:28 |
Dyrcona |
Ah. i saw production above. |
| 12:28 |
mrpeters |
what do i need to do to clean up? |
| 12:28 |
mrpeters |
i have no pending at.events |
| 12:28 |
bshum |
That's not what it's sayinig |
| 12:28 |
Dyrcona |
It's not at events. It's a database trigger on biblio.record_entry. |
| 12:28 |
bshum |
It's saying that record_entry has triggers it's waiting to run |
| 12:28 |
mrpeters |
2014-06-05 11:55:29 EDT ERROR: cannot ALTER TABLE "record_entry" because it has pending trigger events |
| 12:29 |
|
dconnor joined #evergreen |
| 12:29 |
mrpeters |
ah, my mind just quickly went at action triggers |
| 12:29 |
bshum |
What's the command it's attempting to run? Perhaps there's an ALTER in the script following some other command to make changes to the table data. |
| 12:29 |
mrpeters |
2014-06-05 11:55:29 EDT ERROR: cannot ALTER TABLE "record_entry" because it has pending trigger events |
| 12:29 |
mrpeters |
2014-06-05 11:55:29 EDT STATEMENT: ALTER TABLE authority.record_entry ENABLE TRIGGER a_marcxml_is_well_formed; |
| 12:29 |
|
kbutler joined #evergreen |
| 12:30 |
bshum |
(that sort of thing can happen depending on how the script is structured) |
| 12:48 |
kmlussier |
gmcharlt: I noticed when you removed open-ils.ingest references from http://wiki.evergreen-ils.org/doku.php?id=scratchpad:random_magic_spells#how_to_include_a_specific_marc_field_with_a_specific_search_class, you also removed the non-reingest method of populating metabib_keyword_field_entry based on a newly-created index. |
| 12:49 |
* gmcharlt |
looks |
| 12:49 |
kmlussier |
Is that because we shouldn't be using that method to populate the index? |
| 12:50 |
Dyrcona |
mrpeters: Just rearrange the upgrade script so that any updates on biblio.record_entry happen in a different transaction from the alter table steps. |
| 12:53 |
dbwells |
mrpeters: I think your particular problem is fixed in the repo and is part of the 2.6.1 release. Since that release has been in preview mode for a week now, I am adding it to the main downloads page now. |
| 12:54 |
gmcharlt |
kmlussier: it's not horrid to do it that way, but it's less correct (e.g., if the index class happens to be set up as combined) |
| 12:55 |
kmlussier |
gmcharlt: OK, that's good to know. I always knew it was less correct, but it tended to serve our purposes well. :) |
| 12:58 |
dbwells |
downloads page has been updated for newest releases |
| 12:59 |
bshum |
dbwells++ |
| 13:02 |
mrpeters |
dbwells++ |
| 13:02 |
mrpeters |
so, there is a 2.5.3 > 2.6.0 that is updated in the 2.6.1 release, or a 2.5.3 > 2.6.1 upgrade script? |
| 13:02 |
bshum |
Oh right... replying to that thread. |
| 13:02 |
* bshum |
goes and digs up his drafts |
| 13:03 |
mrpeters |
thanks for uploading the release, we've been waiting for it to build the debs for 2.6.1 ;) |
| 13:03 |
pinesol_green |
[evergreen|Bill Erickson] LP#1326806 Minor repairs to EDI admin documentation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=66836d6> |
| 13:03 |
|
hbrennan joined #evergreen |
| 13:07 |
mrpeters |
confirmed fixed |
| 13:07 |
mrpeters |
dbwells++ |
| 13:08 |
dbwells |
mrpeters: thanks for the feedback |
| 13:08 |
mrpeters |
safe to skip the 2.5 reingest of bibs, since it happens again in 2.6? |
| 13:11 |
dbwells |
I would think so, but that's untested. |
| 13:16 |
berick |
bshum++ # edi docs merge |
| 13:16 |
bshum |
berick++ # made good sense to me when I read the diff :) |
| 13:44 |
|
gerson joined #evergreen |
| 14:00 |
remingtron |
did yboston find someone to lead the DIG meeting today? supposed to start at 2pm I think. |
| 14:00 |
kmlussier |
Mixing metarecord holds with part holds - is that even in the realm of possibility for future development? |
| 14:01 |
kmlussier |
Oops! I forgot about the meeting. I'll save my question for later. :) |
| 14:01 |
kmlussier |
How many people are here for the meeting? |
| 14:03 |
remingtron |
hm, not seeing many regulars on the logged in list |
| 14:03 |
kmlussier |
If it's just the two of us, I think it would be a good idea to reschedule. If there are more, I can start up meetbot. |
| 14:04 |
remingtron |
alright, let's give it a few minutes and see if anyone else comes. |
| 14:04 |
kbutler |
I wasn't sure if it was going to be at 2 or 3, based on what yboston said on the list. |
| 14:08 |
remingtron |
ah, just saw his email |
| 14:08 |
remingtron |
kmlussier: are you free at 3pm today? |
| 14:09 |
kmlussier |
Ah, I see. He left it somewhat ambiguous. |
| 14:09 |
kmlussier |
I'm around until 4 p.m., so either time works for me. |
| 14:09 |
remingtron |
I can meet at 3pm, so let's all check in with yboston then, and if we need to reschedule for a different day, then we can. |
| 14:10 |
remingtron |
kbutler: does that work for you too? |
| 14:13 |
kbutler |
yep, that works fine for me. |
| 14:15 |
remingtron |
great, see you folks at 3pm |
| 14:15 |
kmlussier |
Since we're delaying the meeting, I'll re-ask my question. Mixing metarecord holds with part holds - is that even in the realm of possibility for future development? Or am I just talking crazy talk? |
| 14:15 |
bshum |
kmlussier: Crazy talk, obviously. |
| 14:16 |
kmlussier |
bshum: I knew what your answer would be! :D |
| 14:16 |
* bshum |
is kidding, of course. Though now he's ready to go hang himself. |
| 14:16 |
bshum |
How would part holds be connected with metarecords? Like just putting all parts of different metarecords together in some picker? |
| 14:17 |
bshum |
Or something more complex? |
| 14:17 |
bshum |
Like, all parts named the same thing get meta-part'd together? |
| 14:17 |
bshum |
(sounds complicated when I write that) |
| 14:18 |
kmlussier |
I honestly don't know. I guess to provide some way, for example, to allow patrons to place a hold on either the DVD or BluRay format of Breaking Bad, Season 4 Disc 1? |
| 14:18 |
Dyrcona |
Yeah, parts are like the antithesis of metarecords. |
| 14:18 |
Dyrcona |
Metarecord: I don't care which one I get. |
| 14:18 |
bshum |
kmlussier: But what if the DVD and Blu-ray disc 1's don't have the same episodes on them? |
| 14:18 |
Dyrcona |
Part: I want that specific one, right there, yes, part 1, not part 2. |
| 14:18 |
kmlussier |
Or even just the DVD, since there are distinct records for widescreen and letterbox. Maybe the user doesn't care. |
| 14:19 |
|
yboston joined #evergreen |
| 14:19 |
kmlussier |
With metarecord, you don't care what format you get. But you might care what part you get. |
| 14:19 |
kmlussier |
Or you don't care what edition (widescreen/letter box) you get. |
| 14:19 |
jeff |
solution: don't break up multi-disc sets. ;-) |
| 14:19 |
kmlussier |
Yeah, yeah. |
| 14:19 |
bshum |
jeff++ # logic? WHAT?! |
| 14:19 |
* Dyrcona |
ignores jeff and his /solution/. |
| 14:20 |
kmlussier |
I'm actually one of the few patrons who prefers to get DVD's one disc at a time. |
| 14:20 |
kmlussier |
We don't have enough time to watch DVD's during the course of a week. |
| 14:20 |
jcamins |
kmlussier: you get DVDs for a week? |
| 14:20 |
Dyrcona |
But, if I don't care if I get the audio book, the large print, the library binding, or the DVD of the movie that has only the title in common with the book? How do part come into it at all? |
| 14:20 |
kmlussier |
jcamins: From my library? Yup! Why? How long do you get yours? |
| 14:20 |
jeff |
yeah. we have some TV series that are 4 day circ and a long hold queue. depending on when it comes in, you're not going to be able to watch it all. |
| 14:21 |
mmorgan |
Dyrcona: The audiobook is in 2 parts ... |
| 14:21 |
jcamins |
kmlussier: two days. |
| 14:21 |
kmlussier |
jcamins: Yikes! I would never watch anything. |
| 14:21 |
bshum |
Dyrcona: Well, chances are good that the books will not map to metarecord with the videos. Different authors, so different bib fingerprints. |
| 14:21 |
jcamins |
^^ why I don't use the library for A/V. |
| 14:21 |
bshum |
So it's really only the video stuff that might end up on the same metarecord |
| 14:21 |
bshum |
I would think |
| 14:22 |
hbrennan |
Our DVDs check out for a week as well. We have patrons who live 30 miles away, and some across a bay with only boat access. Gotta have time to watch shows. |
| 14:22 |
kmlussier |
bshum: I think you're right. I often see DVD's separated from other formats when I group formats and editions. |
| 14:22 |
bshum |
Or at least, that's been my experiences so far. |
| 14:22 |
Dyrcona |
But parts are broken and so, apparently, are metarecords, so the question is nonsensical. |
| 14:23 |
kmlussier |
Parts aren't broken. They just need a little love. |
| 14:23 |
bshum |
a "little" love? |
| 14:23 |
* kmlussier |
won't speak to metarecord holds because she hasn't used them enough yet. |
| 14:24 |
Dyrcona |
Good luck using them without an Internal Server Error. |
| 14:24 |
bshum |
kmlussier: Yeah I think it's cause the lead author on videos ends up being an actor or director. |
| 14:24 |
|
dluch joined #evergreen |
| 14:24 |
bshum |
So the fingerprint ends up not matching up with the book versions |
| 14:24 |
kmlussier |
bshum: I gathered as much. And it didn't really bother me much because the movie isn't really a direct equivalent of the book or audiobook. |
| 14:25 |
* bshum |
may never turn on metarecord holds now. |
| 14:25 |
Dyrcona |
World War Z: Enjoy the movie that has everything you loved about the title of the book! |
| 14:25 |
bshum |
To avoid the parts + metarecord weirdness that will result |
| 14:26 |
kmlussier |
From what I understand, if you try to place a metarecord hold on a title that only contains parts, you'll get a message saying there are no copies that an fill the hold. |
| 14:26 |
kmlussier |
s/an/can |
| 14:27 |
yboston |
My apologies for those that showed up for the DIG meeting today, I was delayed at a presentation |
| 14:28 |
kmlussier |
yboston: We decided to regroup again at 3. Does that work for you? |
| 14:29 |
yboston |
absolutely |
| 14:35 |
|
mllewellyn joined #evergreen |
| 14:38 |
jeff |
hrm. I wonder why my logging isn't... logging. |
| 14:40 |
bshum |
Opinions: "Patron: password from phone #" setting currently applies the phone number's last four digits as the password every time you update the patron's day_phone. |
| 14:40 |
bshum |
But the description from the setting is that it applies when registering the patron (i.e. new registrations only?) |
| 14:41 |
bshum |
For sites that may be using PIN only, should we add another library setting to continue locking in password set whenever phone is updated? |
| 14:41 |
bshum |
And then leave the default behavior for the current setting to only apply phone to password during new patron registration only? |
| 14:42 |
|
geoffsams joined #evergreen |
| 14:43 |
hbrennan |
I would much prefer only using phone as password during registration |
| 14:43 |
hbrennan |
I think patrons would too |
| 14:43 |
* kmlussier |
agrees with hbrennan. |
| 14:43 |
bshum |
yeah that's what I was thinking, but I just wanted to get some more opinions |
| 14:43 |
kmlussier |
Since users can change their passwords after it is set, it seems like it would be frustrating if the system automatically changed it for them at a later date. |
| 14:43 |
kbutler |
+1 to only using phone during the initial registration. |
| 14:44 |
hbrennan |
Yes, I didn't know it did that |
| 14:44 |
kmlussier |
bshum: Has it always done that? |
| 14:44 |
jeff |
i can see a number of use cases here. some libraries want the patron password to always be four digits matching the last four of the patron phone number. some want to use that as the initial password. others may want to also use it as the value that is assigned when the password is "reset", rather than four random digits. |
| 14:44 |
hbrennan |
Probably the reason why many patrons don't understand when their PIN stops working |
| 14:44 |
kbutler |
we've had problems with it being unintentionally changed. |
| 14:44 |
bshum |
kmlussier: Yeah, it's been one of the reasons I've been hammering back to staff here that changing/updating the phone will also replace the password. |
| 14:44 |
bshum |
kmlussier: I think it's done that since 2.0 |
| 14:44 |
bshum |
Just haven't gotten around to dealing with it before now |
| 14:45 |
jeff |
that behavior outside of an explicit step to enable it is a violation of least surprise, at least to me. :-) |
| 14:45 |
hbrennan |
But the patron should be incontrol of their password, correct? The only reason I see a library wanting it to always match phone is that the library is using patron's passwords |
| 14:46 |
kbutler |
we even have issues with it sometimes during reg, due to the order of the boxes on the registration screen. But that's another issue entirely. |
| 14:46 |
hbrennan |
kbutler: I understand that as well. Staff took a while to learn that they shouldn't write down the initial password given, because it changes after the phone is entered |
| 14:46 |
bshum |
Or maybe I'm lying, because I see the patron.isnew() in the widget code in the register.js...? |
| 14:46 |
hbrennan |
kbutler: It's like bait |
| 14:47 |
* bshum |
is confused now |
| 14:47 |
kmlussier |
bshum: Join the club! |
| 14:47 |
kbutler |
hbrennan: exactly. Even I forget, and then I see it change. |
| 14:48 |
pinesol_green |
In pinesol_green, dbwells said: ~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 14:48 |
pinesol_green |
In pinesol_green, dbwells said: ~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog'; |
| 14:48 |
pinesol_green |
In pinesol_green, dbwells said: ~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 14:48 |
pinesol_green |
In pinesol_green, dbwells said: ~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 14:48 |
bshum |
Oh boy. |
| 14:48 |
hbrennan |
Yikes |
| 14:48 |
kmlussier |
OK, that seems a little random. |
| 14:48 |
dbwells |
sorry :) |
| 14:49 |
dbwells |
I was attempting a private conversation with pinesol_green, but it never learned any manners. |
| 14:49 |
jeff |
that plugin isn't very supybot-like |
| 14:49 |
bshum |
kbutler: Yeah, the order of input always irks me (and our libraries) a bit. |
| 14:49 |
bshum |
@blame Ubuntu |
| 14:49 |
pinesol_green |
bshum: Ubuntu 's bugfix broke bshum's feature! |
| 14:49 |
kmlussier |
pinesol_green: Learn some manners! |
| 14:49 |
pinesol_green |
kmlussier: Have you tried turning it off and back on again? |
| 14:49 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 14:50 |
hbrennan |
haha |
| 14:50 |
jeff |
$logger->info('some text') isn't logging where i would expect. that's unusual. |
| 14:51 |
jeff |
test/dev system, might just be configured wrong. |
| 14:52 |
dbwells |
bshum: P.S. if you (or someone else with editing privileges) could run that last ~no, it would fix the quote issue mrpeters pointed out earlier. Whether we use '=' or 'TO' doesn't seem to matter, but feel free to change that as well. |
| 14:52 |
bshum |
Oh sure. |
| 14:53 |
bshum |
~no search_path is <reply> After restoring a database, make sure to reset the search_path accordingly with something like: ALTER DATABASE unpredicable_haxxors_go_away SET search_path = 'evergreen, public, pg_catalog'; |
| 14:53 |
pinesol_green |
I'll remember that bshum |
| 14:56 |
yboston |
heads up, DIG will have its (rescheduled) monthly meeting at 3 PM EST ( a few minutes from now) |
| 14:58 |
bshum |
kmlussier: kbutler: hbrennan: Hmm, with testing, I can't seem to create the problem I thought existed with the password and phone thing. Nevermind, guess it does work the way I thought it should... |
| 14:58 |
hbrennan |
So it only changes during the first entering of phone? |
| 14:59 |
bshum |
Yeah, it seems to only apply it during new registrations so far in my testing. |
| 14:59 |
kbutler |
hmm |
| 14:59 |
bshum |
Changing it after, and then updating the password doesn't change it |
| 14:59 |
bshum |
At least on my test users |
| 14:59 |
bshum |
Err, changing the phone afterwards doesn't change the password from what I changed it to.... |
| 14:59 |
* bshum |
can't explain anything today apparently |
| 15:00 |
jeff |
ah. logging was not the issue. |
| 15:00 |
hbrennan |
On a related note, I noticed before that the password boxes weren't talking to each other.. so it didn't matter if they matched.. has that bug been fixed? |
| 15:00 |
bshum |
o.O |
| 15:00 |
jeff |
hbrennan: that sounds similar to a recent bug i've seen in launchpad |
| 15:01 |
kbutler |
bshum: I can't get it to do the password/phone thing either. Weird. I swear it was doing it before. |
| 15:01 |
bshum |
Yeah me too... |
| 15:01 |
bshum |
Maybe it was fixed recently |
| 15:01 |
jeff |
bug 1068656 |
| 15:01 |
pinesol_green |
Launchpad bug 1068656 in Evergreen "Password changes not verified when editing user" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1068656 |
| 15:01 |
hbrennan |
Ah, there we go |
| 15:01 |
yboston |
#startmeeting 2014-06-05 - DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
| 15:01 |
pinesol_green |
Meeting started Thu Jun 5 15:01:30 2014 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:01 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 15:01 |
pinesol_green |
The meeting name has been set to '2014_06_05___dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' |
| 15:01 |
yboston |
The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20140605-agenda |
| 15:01 |
jeff |
including comments from mpeters, jboyer-isl, hbrennan and kmlussier :-) |
| 15:02 |
jeff |
er. sorry. enjoy the meeting! |
| 15:02 |
yboston |
#topic Introductions |
| 15:02 |
yboston |
Please feel free to start introducing yourselves... |
| 15:02 |
yboston |
#info yboston is Yamil Suarez @ Berklee college of Music - DIG meeting facilitator |
| 15:02 |
hbrennan |
I'm on the circ desk now so I'm going to be quiet. Thanks everyone! |
| 15:02 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 15:02 |
kmlussier |
Wow. I don't even remember that bug. |
| 15:03 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 15:03 |
bshum |
#info bshum is Benjamin Shum, Bibliomation |
| 15:03 |
kbutler |
#info kbutler is Kate Butler, Rodgers Memorial Library |
| 15:04 |
|
dbwells joined #evergreen |
| 15:05 |
yboston |
BTW, I was going to try to emulate the developer meetings sty;e for today, apologies in advance |
| 15:05 |
remingtron |
yboston: no worries, go for it |
| 15:05 |
yboston |
they usually start with past items, so I will start listing them for us to decide if we should address it now, shelve it, or push it to next meeting |
| 15:05 |
yboston |
#action Think of ways to increase participation, create an informal survey, training during a DIG hack-a-way, or online DIG training sessions between conferences (by Yamil) |
| 15:05 |
yboston |
#action brainstorming on survey draft (Yamil) |
| 15:06 |
yboston |
oops |
| 15:06 |
yboston |
#topic past agenda items |
| 15:06 |
yboston |
#action Think of ways to increase participation, create an informal survey, training during a DIG hack-a-way, or online DIG training sessions between conferences (by Yamil) |
| 15:06 |
yboston |
#action brainstorming on survey draft (Yamil) |
| 15:07 |
yboston |
we have not covered this in a while, should we shelve it for next week or put it in the back burner (some wiki page) in th meantime? |
| 15:07 |
|
dbwells joined #evergreen |
| 15:07 |
remingtron |
we had lots of participation at the April meeting right after the conference |
| 15:07 |
remingtron |
I'm sure that's normal |
| 15:07 |
yboston |
we can decide to revisit this issues after we finsish with 2.6? |
| 15:07 |
remingtron |
yes, I agree |
| 15:08 |
remingtron |
that will hopefully be our next meeting, right? |
| 15:08 |
kmlussier |
remingtron: Yes, absolutely! :D |
| 15:09 |
remingtron |
alright, let's push it off to next meeting |
| 15:09 |
yboston |
I was thinking the august meeting, |
| 15:09 |
yboston |
but the next one is fine |
| 15:09 |
remingtron |
ah, that's probably wise |
| 15:09 |
yboston |
quick vote on July vs August? |
| 15:09 |
remingtron |
August |
| 15:10 |
yboston |
August |
| 15:10 |
remingtron |
(unless no one shows up for our July mtg) |
| 15:10 |
remingtron |
:) |
| 15:11 |
yboston |
the next meeting woudl fall on Thursday July 3rd, which might be bad for some |
| 15:11 |
yboston |
we can pick a different date to meet in July |
| 15:11 |
remingtron |
right, given American Independence Day, July 4 |
| 15:11 |
kbutler |
not July3++ |
| 15:11 |
bshum |
August seems fine to me. :) |
| 15:11 |
remingtron |
next meet July 10? |
| 15:12 |
kmlussier |
I won't be around July 3. |
| 15:12 |
kmlussier |
Or the 10th. |
| 15:12 |
yboston |
three votes for August and none for July are good enough to move on? |
| 15:12 |
kmlussier |
+1 |
| 15:12 |
remingtron |
yes, should we decide the next meeting date now, or at end of meeting? |
| 15:13 |
yboston |
I would rather ask on the list |
| 15:13 |
remingtron |
sounds fine |
| 15:13 |
yboston |
to get more peopel to particiate |
| 15:13 |
yboston |
#action move the agenda items on increasing DIG participation and the survey to the Agust meeting |
| 15:14 |
yboston |
#action ask on the DIG mailing list for an alternate July meeting date |
| 15:14 |
yboston |
may I move on? |
| 15:14 |
kmlussier |
yboston: Who is taking that last action item? |
| 15:14 |
yboston |
#action yboston will ask on the DIG mailing list for an alternate July meeting date |
| 15:14 |
yboston |
(thanks) |
| 15:15 |
kmlussier |
yboston++ |
| 15:15 |
remingtron |
great |
| 15:15 |
yboston |
#info Including technical information in end-user docs - http://markmail.org/message/twcwas7r4yuavxcq (by Kathy) |
| 15:15 |
* jeff |
looks up |
| 15:15 |
yboston |
I think we have a general consensus on this |
| 15:15 |
kmlussier |
Oops, I forgot to take that item off of the agenda. |
| 15:16 |
kmlussier |
Did you want to add the action item I suggested in the e-mail? |
| 15:16 |
jeff |
can you summarize the general concensus or point to where it was previously summarized? |
| 15:16 |
yboston |
of course after kmlussier takes it off the agenda, we can always revisit at a future date |
| 15:16 |
jeff |
consensus, even. |
| 15:16 |
* kmlussier |
looks. |
| 15:17 |
kmlussier |
http://georgialibraries.markmail.org/thread/7vkqwo5hkqcaxg6n |
| 15:17 |
yboston |
should we move on, or does anyone have aby comments? |
| 15:17 |
kmlussier |
the consensus from that discussion was that people preferred to gather all of the information about a particular feature (technical, administrative, end user) into one place. |
| 15:17 |
jeff |
kmlussier++ thanks |
| 15:17 |
yboston |
#link http://georgialibraries.markmail.org/thread/7vkqwo5hkqcaxg6n |
| 15:18 |
yboston |
#action kmlussier will remove the agenda item for tec docs from the agenda for the next meeting |
| 15:18 |
yboston |
*tech |
| 15:19 |
yboston |
may I move on? (sorry, want to blow through old stuff, feel free to tell me to slow down) |
| 15:19 |
kmlussier |
#action kmlussier will add to the DIG style guide info on gathering technical and end user info in one place. |
| 15:19 |
remingtron |
yboston: go right ahead |
| 15:19 |
kmlussier |
+1 to moving on. |
| 15:19 |
yboston |
#info Post conference DIG hackfest discussion |
| 15:19 |
yboston |
# 1) remaining work to be finished |
| 15:19 |
yboston |
#info ideas for next year's conference |
| 15:20 |
remingtron |
I believe the main focus was on bringing old missing docs into current docs, which has been postponed until we get 2.6 finished, right? |
| 15:20 |
remingtron |
(the focus of the hackfest, that is) |
| 15:20 |
yboston |
yes, I was about to say this is another good thing to postpone until August |
| 15:20 |
remingtron |
yes, I agree |
| 15:20 |
kbutler |
I agree re: postponing |
| 15:21 |
kmlussier |
+1 |
| 15:22 |
yboston |
#action yboston will move action item about finishing DIG 2013 hackfest work to August meeting agenda |
| 15:22 |
yboston |
#action yboston will move action item about finishing DIG 2014 hackfest work to August meeting agenda |
| 15:22 |
yboston |
I think we can ignore the brainstorming for now |
| 15:23 |
yboston |
will move on (?) |
| 15:23 |
remingtron |
go ahead |
| 15:23 |
yboston |
#info Reminder to use (and keep improving) the DIG AsciiDoc Style Guide |
| 15:24 |
remingtron |
just wanted to remind people that it exists |
| 15:24 |
remingtron |
feel free to edit, improve, etc. |
| 15:24 |
yboston |
we could move this to that page about our general todos? |
| 15:24 |
remingtron |
yes, great idea |
| 15:24 |
remingtron |
I'll do that |
| 15:25 |
yboston |
should I create the action item for you or do you want to do it? |
| 15:25 |
remingtron |
#action remingtron will move style guide reminder to DIG ToDo page |
| 15:25 |
yboston |
nice |
| 15:25 |
remingtron |
thanks |
| 15:25 |
yboston |
moving on |
| 15:25 |
yboston |
#info Discuss if we should pick a new monthly day and time for DIG to meet (Yamil) |
| 15:26 |
yboston |
we have had OK attendace so far since after the conference. I think the IRC practice helped a bit |
| 15:26 |
yboston |
we can postpone this for a while, maybe part of the outreach to the general comunity |
| 15:26 |
remingtron |
summer is tricky, what if we try using Doodle to schedule the next meeting or two? |
| 15:26 |
yboston |
*community |
| 15:26 |
yboston |
we can try with the July meeting |
| 15:27 |
kmlussier |
+1 |
| 15:27 |
yboston |
I can set up the doodle |
| 15:27 |
yboston |
I will pick 2 or 3 PM for several days in the first two weeks of July (?) |
| 15:28 |
kbutler |
+1 |
| 15:28 |
remingtron |
maybe just pick one week |
| 15:28 |
yboston |
BTW, I am picking afternoons to help make it easy on West coast folks. |
| 15:28 |
yboston |
yes, I can start with one week only for now |
| 15:29 |
yboston |
will pick the second week of july |
| 15:29 |
remingtron |
sounds good |
| 15:29 |
kmlussier |
The week of July 7? |
| 15:29 |
kmlussier |
I'll be out that week, but I can always miss a meeting. :) |
| 15:29 |
yboston |
yes, July 7th, unless that is bad for you |
| 15:29 |
remingtron |
if it's bad for others, we can always change weeks |
| 15:30 |
yboston |
Is the first week any worse? |
| 15:30 |
remingtron |
I think so, because of 4th of July |
| 15:30 |
yboston |
I will do the first two weeks (a few days in both) |
| 15:30 |
remingtron |
sounds fine |
| 15:31 |
yboston |
@action yboston will set up a doodle poll for scheduling the July DIG meeting |
| 15:31 |
* pinesol_green |
yboston will set up a doodle poll for scheduling the July DIG meeting |
| 15:31 |
yboston |
#action yboston will set up a doodle poll for scheduling the July DIG meeting |
| 15:31 |
yboston |
#New DIG Workflow: Document all new 2.6 features by July 1, and all new future version features by the time the version is released. |
| 15:31 |
yboston |
#info New DIG Workflow: Document all new 2.6 features by July 1, and all new future version features by the time the version is released. |
| 15:32 |
yboston |
#info 1. To review: All members choose 1-3 new features to document each month, emailing the list with questions and calls for help. |
| 15:32 |
yboston |
#info 2. Assignments: Everyone choose another 1-3 remaining new features for the next month |
| 15:32 |
yboston |
#info 3. Progress Reports: How did this month go? Suggestions for improving the workflow? Tough features that need special attention? |
| 15:33 |
remingtron |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.6_needs&#cataloging |
| 15:34 |
remingtron |
oops, ignore the "cataloging" part |
| 15:34 |
yboston |
kbutler was working on something, and I am sorry I did not have an abswer for your question |
| 15:34 |
remingtron |
#link: evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:2.6_needs |
| 15:34 |
kmlussier |
I expect to have mine complete by July 1. |
| 15:34 |
kbutler |
I took the silence as an 'nope, this isn't documented yet' response. |
| 15:34 |
remingtron |
kbutler: you were correct! |
| 15:35 |
kbutler |
Adding that in means I'm not done yet but I should be done by the deadline. :) |
| 15:35 |
kmlussier |
kbutler: I find that often happens when I'm documenting something that seems to be a small task. |
| 15:35 |
yboston |
kbutler: I started doing a low level text search of the raw docs, but I did not get far enough to get you an answer |
| 15:35 |
yboston |
(I checked out the repo and just used "grep -i standing") |
| 15:36 |
yboston |
I think there is one or two things that are new in 2.6 that are not in my list, but I need to verify and list them on this list. I think they might be simple enough that I can maybe docuemnt them myself by th edeadline |
| 15:37 |
yboston |
(I looked at it a month ago and don't remmeber what I saw) |
| 15:37 |
kbutler |
thanks to everyone who looked. |
| 15:37 |
remingtron |
kbutler: do you want any help, or want to handle it yourself? |
| 15:38 |
kbutler |
I think I'm ok, but if anyone has thoughts on where it should go within the documentation I would be happy to hear them. |
| 15:38 |
kbutler |
But I will send that to the list. |
| 15:39 |
remingtron |
my only suggestion is to do a quick Google search, which will hopefully turn up wiki pages, email conversation, Evergreen blogs, etc. which might help |
| 15:39 |
kbutler |
good idea |
| 15:40 |
remingtron |
I grabbed another todo item today, should be done soon. |
| 15:40 |
yboston |
There are also docs by the BC and Indianapolis libraries that might cover it, for example |
| 15:41 |
yboston |
BTW, another side project for us is to move that content to the main docs |
| 15:41 |
kmlussier |
All of it? Or just the parts that aren't already covered by the docs? |
| 15:41 |
yboston |
I meant the parts that we are missing |
| 15:41 |
remingtron |
yboston: we should add an action of "prioritize missing or external docs to add in" |
| 15:42 |
yboston |
for example, in the general to dos page? |
| 15:42 |
remingtron |
sure! |
| 15:43 |
yboston |
can you take care of that one? |
| 15:43 |
yboston |
or somebody else? |
| 15:43 |
remingtron |
I'll do it |
| 15:43 |
remingtron |
#action remingtron will start a prioritized list of missing or external docs to bring in |
| 15:44 |
yboston |
BC libraries mentioned they want to help with integrating their content with us |
| 15:44 |
remingtron |
great! |
| 15:44 |
yboston |
btw, we are at the 45 minute mark, we are doing well |
| 15:45 |
kbutler |
integrated content++ |
| 15:45 |
yboston |
do we want to stay on this topic a little longer or move on? |
| 15:45 |
remingtron |
haven't heard much progress from Jennifer or Elliot |
| 15:46 |
yboston |
Do we have any ESI folks that could comment on their 2.6 doc progress? |
| 15:47 |
kmlussier |
yboston: They usually introduce themselves at the beginning when they're here. |
| 15:47 |
yboston |
I know, but I was wondering if they showed up on the later side :) |
| 15:48 |
yboston |
BTW, at this point we only have to "new" agenda issues to discuss. SHould I move on, with the assumption that we can keep talking about 2.6 on the list? |
| 15:49 |
remingtron |
sure, I'll send another progress requst to the list |
| 15:49 |
remingtron |
#action remingtron will email the DIG list for a progress report |
| 15:49 |
yboston |
thanks |
| 15:50 |
yboston |
#topic Early plans for updating documentation for new web-client (Yamil) |
| 15:50 |
yboston |
this has been discussed a bit on the list so far |
| 15:50 |
yboston |
on one hand we can do too much at this time while the client is so rapidly evolvimg |
| 15:51 |
yboston |
(can't do) |
| 15:51 |
kmlussier |
I think we should take the approach remingtron recommended for new features. If a piece of the web client is ready at release time, then it should be included as new features to document by the general release deadline. |
| 15:51 |
yboston |
I suspect a version of the browser client could appear in 2.7 with very limted functional |
| 15:52 |
remingtron |
kmlussier++ |
| 15:52 |
kbutler |
kmlussier++ |
| 15:52 |
yboston |
remingtron++ kmlussier++\ |
| 15:53 |
yboston |
I think that for now that is enough to cover ont his topic, but I am open to talking more about it now too |
| 15:53 |
remingtron |
sounds fine for now |
| 15:54 |
kbutler |
not much can be done until there are firmer plans for a release date |
| 15:54 |
yboston |
moving on |
| 15:54 |
yboston |
#info Do we need to plan a DIG hack-a-way for before Evergreen 2.7 is released? |
| 15:55 |
yboston |
for the record, DIG hack-a-way have been held around October/November, but we do not need to stick to that |
| 15:55 |
yboston |
we can also postpone this dicsussion until a future meeting |
| 15:55 |
remingtron |
can we get a quick vote of interest? |
| 15:55 |
yboston |
perhpas, depending on how well we do with 2.6 |
| 15:56 |
yboston |
first can we determine a rough date for when 2.7 might come out? |
| 15:56 |
* kmlussier |
looks at bshum |
| 15:56 |
bshum |
The dates are on the calendar already |
| 15:56 |
bshum |
I plan to stick to them. |
| 15:56 |
yboston |
I should have emphasized "might" |
| 15:56 |
yboston |
let me look |
| 15:57 |
remingtron |
Sept 18 for 2.7.0 Final |
| 15:57 |
remingtron |
August 7 -- 2.7 beta |
| 15:57 |
kmlussier |
So August 7 is when we know what we need to document. |
| 15:57 |
remingtron |
DIG can do most of our work once beta is out |
| 15:57 |
remingtron |
yup |
| 15:58 |
yboston |
I am up for a DIG hack-a-way before Sept 18 for 2.7.0 Final |
| 15:58 |
remingtron |
me too |
| 15:59 |
kbutler |
me too |
| 15:59 |
yboston |
do we want/can we start working on it before the beta? |
| 16:00 |
remingtron |
sure, we can document features as they get committed |
| 16:00 |
kmlussier |
Sounds like a good idea. |
| 16:00 |
remingtron |
starting now |
| 16:00 |
yboston |
Also, I can host folkt at Berklee again, but we can try somewhere else too |
| 16:00 |
remingtron |
who wants to watch the git logs and make a list for us? |
| 16:00 |
* kmlussier |
can do that. |
| 16:00 |
remingtron |
kmlussier++ |
| 16:00 |
yboston |
my concerd is that there is no 2.7 branch yet (or is there) |
| 16:01 |
yboston |
I thought some things that are in master, in theory, might not make it to 2,7 |
| 16:01 |
* kmlussier |
commits to documenting any MassLNC-sponsored billing features if and when they make it in. |
| 16:01 |
kmlussier |
yboston: No, if they are in master, they will make it to 2.7 |
| 16:01 |
bshum |
Correct. |
| 16:01 |
bshum |
master is basically what will become 2.7 till we branch it. |
| 16:02 |
yboston |
OK, tha tmakes sense |
| 16:03 |
yboston |
*that |
| 16:03 |
yboston |
so should that mean that we might not want to focus much on older missing stuff until October? |
| 16:04 |
yboston |
or maybe just that most of us will focus on 2.6/2.7 and a few of us can focus on older/missing stuff |
| 16:04 |
bshum |
Thing is, things will always change |
| 16:04 |
yboston |
(BTW, we are at a little past the hour mark) |
| 16:04 |
bshum |
But how much of it might change a lot with the web client coming up? At the very least, screenshots. |
| 16:04 |
bshum |
But that's like... way past 2.7 :) |
| 16:05 |
remingtron |
I think the majority of our time should go toward new stuff, but some old priority stuff should get done too |
| 16:05 |
remingtron |
70-80% new features, the rest on filling in the gaps in the docs |
| 16:06 |
remingtron |
(that's % of our time) |
| 16:06 |
yboston |
I think as we get better at documenting, we can do both more easily |
| 16:07 |
remingtron |
great, I think we got through everything on the agenda! |
| 16:07 |
yboston |
so should we create an action item for adding something to the august agenda to start working on 2.7? |
| 16:07 |
remingtron |
yes |
| 16:08 |
yboston |
#action yboston will add an agenda item to the august meeting to have DIG start looking at 2.7 new features |
| 16:09 |
yboston |
we are past the 1 hour mark, and we have quickly goen over all the agenda items |
| 16:09 |
yboston |
shoudl we wrap it up for today? |
| 16:09 |
kmlussier |
yboston++ #Making it through all the agenda items! |
| 16:09 |
remingtron |
I think so |
| 16:09 |
remingtron |
yboston++! |
| 16:10 |
yboston |
thanks everyone, to be continued |
| 16:10 |
yboston |
#endmeeting |
| 16:10 |
pinesol_green |
Meeting ended Thu Jun 5 16:10:15 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:10 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-06-05-15.01.html |
| 16:10 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-06-05-15.01.txt |
| 16:10 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-06-05-15.01.log.html |
| 16:10 |
remingtron |
bshum: thanks for being present for RM questions |
| 16:10 |
kbutler |
yboston++ |
| 16:11 |
bshum |
remingtron: Sure, I'm writing an RM email now... because I just looked at my own timeline and forgot where all the time has gone. |
| 16:11 |
bshum |
As an FYI, I'm going to extend the date to target new features towards 2.7 to next Thursday, June 12th (instead of today) |
| 16:12 |
remingtron |
bshum++ |
| 16:12 |
bshum |
If anyone out there knows of new stuff that'll be actively developed / planning to develop something, this is the time to start telling the world about it. |
| 16:13 |
yboston |
remingtron: I wanted to share with you that in the past few weeks I have been trying to parse the full documentation on my Mac. So far I can build the epub version without errors |
| 16:13 |
|
kmlussier left #evergreen |
| 16:13 |
|
ericar joined #evergreen |
| 16:13 |
yboston |
remingtron: I get errors when building the the HTML version through asciidoc, turns out Robert first exports to DocBook, then creates the HTML. I need to try that locally |
| 16:14 |
yboston |
remingtron: I also figured out how to solve the "source-highlighting" error I was getting way back at the DIG hack-a-way. Just had to isntall the library on my MAc |
| 16:15 |
yboston |
remingtron: BTW, the error with Asciidoc to HTML is that asciidoc get confused about image paths because we are using the "include:file_name.txt" directive, in terms of resloving paths |
| 16:21 |
|
tspindler left #evergreen |
| 16:27 |
remingtron |
yboston: glad you're making progress. Is there a particular reason you want to build it all locally? |
| 16:29 |
yboston |
remingtron: So I can test major changes to the docs, to see if I am breaking the converson |
| 16:29 |
yboston |
*converson |
| 16:29 |
yboston |
remingtron: without waiting until midnight for the docs server to proces the content |
| 16:30 |
yboston |
remingtron: also, to fostre redundancy in case the server goes down |
| 16:38 |
remingtron |
yboston: right, nice to not have to wait until midnight to see what breaks. :) |
| 16:38 |
yboston |
remingtron: I'll keep you posted on my progress |
| 16:38 |
remingtron |
great, thanks |
| 17:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:08 |
|
mmorgan left #evergreen |
| 19:55 |
bshum |
gmcharlt: Just read https://bugs.launchpad.net/evergreen/+bug/1326983, sounds straightforward, but I have a question about it. the .example file doesn't overwrite an existing file if setup on the system, right? So we need to inform folks about the bug fix (if they don't actually read the changelogs). Release notes aren't really done for point releases, but maybe there's some other method we can think of. |
| 19:55 |
pinesol_green |
Launchpad bug 1326983 in Evergreen 2.5 "stock A/T filter for hold_request.shelf_expires_soon hook is too broad" (affected: 1, heat: 6) [Low,New] |
| 19:56 |
bshum |
Or hmm, I haven't looked lately at whether the file copies on install now. /me checks again |
| 19:57 |
gmcharlt |
bshum: it doesn't overwrite AFAIK |
| 19:57 |
gmcharlt |
but then again, that puts it in the same boat as, say, opensrf.xml |
| 19:58 |
gmcharlt |
one easy place to put it - the release announcement |
| 19:59 |
bshum |
Huh |
| 19:59 |
bshum |
My action_trigger_filters.json is different than stock |
| 20:00 |
bshum |
Oh wacky |
| 20:00 |
bshum |
I already have fulfillment_time on our utility server |
| 20:03 |
bshum |
gmcharlt++ # I'll go push it through then, we'll just have to make a mental note to mention this bug fix when we announce the next point releases. |
| 20:03 |
bshum |
Thanks! |
| 20:07 |
pinesol_green |
[evergreen|Galen Charlton] LP#1326983: excluded fulfilled holds when adding hold_request.shelf_expires_soon events - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1a9e623> |
| 20:19 |
bshum |
@later tell berick Question on backporting for https://bugs.launchpad.net/evergreen/+bug/1301599 (WCAG, part 2): at least one string change (image of item to book cover) occurs, so I'm hesitant to backport to rel_2_6. Any opinions about only affecting that change to master? (also not sure how I feel on wording yet) |
| 20:19 |
pinesol_green |
bshum: The operation succeeded. |
| 20:19 |
pinesol_green |
Launchpad bug 1301599 in Evergreen 2.6 "TPAC accessibility (WCAG) improvements: Round 2" (affected: 1, heat: 8) [Undecided,New] |
| 20:33 |
pinesol_green |
[evergreen|Dan Scott] LP#1303544 Trim junk from the ISBN in record summary - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d1cb0e7> |
| 20:41 |
|
shadowspar joined #evergreen |
| 21:14 |
|
kmlussier joined #evergreen |
