| Time |
Nick |
Message |
| 00:58 |
|
shadowspar joined #evergreen |
| 01:14 |
|
shadowspar joined #evergreen |
| 06:25 |
|
edoceo joined #evergreen |
| 06:36 |
|
edoceo joined #evergreen |
| 07:08 |
|
timf joined #evergreen |
| 08:02 |
kmlussier |
We're due for a developers meeting. Doodle poll at http://doodle.com/shbpr649h6xint7r |
| 08:02 |
* kmlussier |
most likely won't be able to attend the next meeting. |
| 08:16 |
|
Shae joined #evergreen |
| 08:26 |
|
akilsdonk joined #evergreen |
| 08:31 |
kmlussier |
@wunder 02771 |
| 08:31 |
pinesol_green |
kmlussier: The current temperature in Ladd Observatory, Providence, Rhode Island is 27.1°F (8:30 AM EST on February 05, 2014). Conditions: Light Snow. Humidity: 95%. Dew Point: 26.6°F. Windchill: 21.2°F. Pressure: 30.07 in 1018 hPa (Falling). Winter Storm Warning in effect until 6 PM EST this evening... |
| 08:32 |
kmlussier |
A very snowy winter indeed. |
| 08:56 |
|
rfrasur joined #evergreen |
| 08:57 |
|
rfrasur joined #evergreen |
| 08:57 |
|
collum joined #evergreen |
| 08:57 |
rfrasur |
jboyer-isl: will SIP2 authentication still be available during the upgrade or will the whole thing be down? |
| 08:59 |
rfrasur |
I see that OD will still be available. Does that go for other stuff as well? |
| 09:25 |
|
Dyrcona joined #evergreen |
| 09:30 |
|
rjackson_home joined #evergreen |
| 09:38 |
|
ericar joined #evergreen |
| 09:49 |
Dyrcona |
Aren't snow days wonderful? |
| 09:51 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Better way to do this or cache it in tpac?" (8 lines) at http://paste.evergreen-ils.org/12 |
| 09:52 |
Dyrcona |
So, I wrote that code above, and that seems fine for a script that will only be run occasionally, but I want to put this into TPAC eventually. |
| 09:53 |
Dyrcona |
The question is: Is there a better way to do that already in TPAC or is there a good way to cache the item_type hash? |
| 09:53 |
dbs |
Dyrcona: hey, I think we could use the auditor tables to revert changes for small batches of bibliographic objects! |
| 09:54 |
Dyrcona |
dbs: yeah, you could, but we clear ours every 6 months, so if there will be more than 6 months between changes, then it won't work for us. That's why we made the custom table. |
| 09:54 |
dbs |
Dyrcona: I'm making a joke about me mentioning audit tables and then you saying the same thing in that thread :) |
| 09:55 |
Dyrcona |
Ah ha! I'm making a joke of myself, apparently. :) |
| 09:55 |
dbs |
If we ever do base functionality on audit tables I guess we should document that it might be subject to a given site's purging practices. |
| 09:55 |
* dbs |
doesn't think we have any purging practices... probably should look into that some day |
| 09:55 |
berick |
Dyrcona: ctx.search_ccvm('name', 'item_type') |
| 09:56 |
berick |
will cache |
| 09:56 |
Dyrcona |
berick: Thank you muchly! I'll give that a whirl when I get to TPACifying the code. |
| 09:56 |
jeff |
tpacification |
| 09:57 |
Dyrcona |
I figured there had to be something that I overlooked, since TPAC needs that info in a number of places. |
| 09:58 |
jeff |
I'm starting a fake library content vendor. We're going to have no content, but exemplary patron authentication and user experience. :P |
| 09:58 |
dbs |
MuchDogeVendor? |
| 09:58 |
dbs |
GoodVendorDoge |
| 09:59 |
jeff |
wOw! such auth! very UX! |
| 09:59 |
jeff |
Welcome to your library's doge-ital branch! |
| 10:05 |
Dyrcona |
jeff: I see what you did there. |
| 10:05 |
Dyrcona |
well, dbs, really. |
| 10:05 |
Dyrcona |
jeff: So, it's a mining operation, is it? |
| 10:07 |
Dyrcona |
Hmm... Maybe EG needs a cryptocurrency payment module? |
| 10:08 |
Dyrcona |
Set fine rates in Satoshis. :) |
| 10:17 |
jeff |
heh |
| 10:17 |
jeff |
I'm assuming that I mangled the doge-speak above. |
| 10:25 |
jeff |
But no, the idea isn't to mine bitcoins or accept dogecoin. :-) |
| 10:25 |
Dyrcona |
No, it sounds almost like the dogecoin website exactly: much coin! such community! much news! very fashion! |
| 10:26 |
Dyrcona |
so, very UX is spot on. :) |
| 10:26 |
jeff |
The idea is to have an example of "this would be a great way to auth patrons" and "this would be a great way to treat patrons", rather than [current status quo of library content vendors here]. |
| 10:26 |
* Dyrcona |
wishes library vendors actually had a clue. |
| 10:26 |
jeff |
I get worked up about this when evaluating new services. Sometimes the interest fades, sometimes not. |
| 10:27 |
jeff |
But part of the idea too is that it would give me some perspective on Evergreen/Koha/etc from a "content provider" point of view also. |
| 10:28 |
dbs |
jeff: this would let us test improved core security too, like replacing unsalted MD5-hashed passwords |
| 10:29 |
jeff |
"here's an idea, let's not use a self checkout protocol with access to holds/circ/bills/more just to verify that you are a patron, and let's not require your library card number (which one?) and library password be entered on the vendor site, and let's not have the vendor store your library password in cleartext in their systems!" |
| 10:29 |
jeff |
dbs: yes, though i see that as a parallel, higher priority goal. :-) |
| 10:29 |
dbs |
jeff: so teaching Evergreen to be an OAuth2 provider? |
| 10:29 |
jeff |
yep. |
| 10:30 |
jeff |
and/or other options. |
| 10:30 |
jeff |
but that seems to be the most promising in terms of "go implement this" -- a web standard vs a library standard. |
| 10:30 |
dbs |
jeff: jrochkind says its as simple as switching md5 to bcrypt. EASY! |
| 10:31 |
dbs |
jeff++ |
| 10:32 |
dbs |
web_standards++ |
| 10:35 |
Dyrcona |
dbs: Now, you go and tell all the library vendors that its easy. |
| 10:35 |
Dyrcona |
You know the same vendors that can't follow the existing library standards. |
| 10:36 |
* Dyrcona |
is jaded after 10 years of dealing with this nonsense. |
| 10:37 |
dbs |
Dyrcona: heh, and I'm being more than a little tongue in cheek when I say "EASY!" because of course the easiest part is for jrochkind to say it's easy :) |
| 10:37 |
Dyrcona |
Heh. |
| 10:38 |
Dyrcona |
That's the great thing about standards! There are so many ways to get it subtly wrong! |
| 10:38 |
dbs |
Wow that's a lot of bugfixes getting pushed out :/ |
| 10:38 |
dbs |
dbwells++ |
| 10:52 |
Dyrcona |
Zawinski's Law is coming to Evergreen. |
| 10:52 |
Dyrcona |
Although, really, it's already here. |
| 10:54 |
Dyrcona |
For reference: http://www.catb.org/jargon/html/Z/Zawinskis-Law.html |
| 10:55 |
jeff |
Dyrcona: someone's trying to make Evergreen read mail? :-) |
| 10:55 |
Dyrcona |
jeff: Yep. |
| 10:55 |
jeff |
Dyrcona: link/pointer? |
| 10:56 |
Dyrcona |
http://masslnc.cwmars.org/node/2927 |
| 10:56 |
Dyrcona |
Really, though, he was talking about the tendency of applications to turn into frameworks, which Evergreen already is. |
| 10:57 |
* Dyrcona |
has read the blog post the quote comes from. |
| 10:57 |
* jeff |
nods |
| 11:00 |
|
jboyer-laptaupe joined #evergreen |
| 11:04 |
|
finnx_ joined #evergreen |
| 11:06 |
rfrasur |
Dyrcona: You wrestling with Ebsco? |
| 11:07 |
Dyrcona |
I was, why? |
| 11:07 |
rfrasur |
Just reading back comments. |
| 11:07 |
Dyrcona |
Ok. |
| 11:12 |
|
ningalls joined #evergreen |
| 11:29 |
Dyrcona |
bshum: You getting snow today? |
| 11:30 |
bshum |
Dyrcona: Just a lil' bit. |
| 11:30 |
bshum |
:) |
| 11:30 |
Dyrcona |
We haven't gotten tons, but it was coming down really hard right at the height of the morning commute. |
| 11:31 |
Dyrcona |
I'm going to push a commit to the "real" Marque.pm branch in a moment. |
| 11:32 |
Dyrcona |
It'll be a force push. I rebased on master since the branch had been sitting for a couple of months. |
| 11:32 |
Dyrcona |
I'm going to try to add the missing mfhd and progress features real soon. |
| 11:34 |
bshum |
I think we've gotten about 8 inches or so here at my house. I've been told towards our offices it's like 12-14 inches right now. |
| 11:34 |
Dyrcona |
I'm not sure how much we've gotten. I haven't gone out side. |
| 11:35 |
Dyrcona |
Half of our members have emailed in that they are closed. |
| 11:35 |
bshum |
And yay, Marque.pm whee! |
| 11:35 |
Dyrcona |
I'm target it for the beta now. I'll see if I can't finish it by the end of the week. |
| 11:36 |
Dyrcona |
Everything is going into working/dyrcona/lp1223903-MARC-export-Mk.2 from now on. |
| 11:37 |
jboyer-laptaupe |
bshum: Re: commit db7b99e8ccba2ebf81a345157de5a90ba5387626, is there anything else that may need changing for rel_2_5? We have a test system built from rel_2_5 pulled just after that commit went in, but auto-print still doesn't seem to stick on the checkout page with a fresh staff client. |
| 11:37 |
pinesol_green |
[evergreen|Ben Shum] Revert "Eliminate an annoying and useless warning in the JavaScript Console." - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db7b99e> |
| 11:38 |
bshum |
jboyer-laptaupe: It's a server side change. |
| 11:38 |
bshum |
Not just a client one |
| 11:38 |
jboyer-laptaupe |
Ah, the path led me astray. I haven't checked the server side file yet. |
| 11:39 |
bshum |
/openils/var/web/xul/server/OpenILS/global_util.js |
| 11:39 |
bshum |
Yeah for the staff client I usually tend to check first if there's a server equivalent. |
| 11:40 |
bshum |
The one that gets me is the chrome directory stuff I think |
| 11:44 |
Dyrcona |
Yeah, just changing the file on the server fixed it for me. |
| 11:45 |
Dyrcona |
bshum: We've got six inches of snow at my house and its still coming down. |
| 11:45 |
jboyer-laptaupe |
Well never mind that. Our test system isn't running the version of evergreen we wanted to test. :( |
| 11:45 |
jeff |
jboyer-laptaupe: oops. |
| 11:47 |
jboyer-laptaupe |
jeff: I'd actually feel better about it if it were my fault. :/ |
| 11:49 |
|
akilsdonk joined #evergreen |
| 11:49 |
kmlussier |
Dyrcona: Did you say your office had a snow day today? Do you all do work-at-home snow days or is it a day off snow day? |
| 11:50 |
* kmlussier |
is just wondering about the likelihood of getting a response on an e-mail I sent. |
| 11:52 |
Dyrcona |
kmlussier: Officially, I believe it is a work-at-home snow day. At least, I'm doing it that way. |
| 11:52 |
kmlussier |
OK, thanks! |
| 11:53 |
Dyrcona |
Password reset action trigger runner went bonkers again. |
| 11:56 |
Dyrcona |
Heh. Been that way since 8:00 am. I guess Thunderbird wasn't checking mail as often as I thought. |
| 11:56 |
bshum |
Dyrcona: Did you see any of what we sussed out at the end of the other day about action_trigger_runner and the parallel options for trigger? |
| 11:57 |
Dyrcona |
bshum: Not likely. What day was it and I can check the logs. |
| 11:57 |
bshum |
It's been a few days now since I commented out parallel in production and I haven't seen any weird collected states that are broken. |
| 11:57 |
Dyrcona |
Is this for all action trigger runners? |
| 11:57 |
bshum |
http://irc.evergreen-ils.org/evergreen/2014-02-03#i_66180 |
| 11:58 |
bshum |
For me, it mostly affected my hold ones it seemed. |
| 11:58 |
bshum |
Though I do know that before I made my overdues into granular events (by type), it broke my overdues too. |
| 11:59 |
bshum |
My gut feeling (without much extra evidence) is something weird happening since we upgraded back in December last year to the newer OpenSRF control stuff |
| 11:59 |
Dyrcona |
We've been seeing this long before last December. |
| 11:59 |
Dyrcona |
We just kill the hung process, remove the lock file, and let the others take it from there. |
| 11:59 |
bshum |
Well then I got nothing new ;) |
| 12:00 |
Dyrcona |
I'll try removing the parallel option to see if that helps. |
| 12:09 |
bshum |
Well, periodically at varying points in our history, it seems our action_trigger_runner script has died out too. I can see that from clumps of collected A/T from years past. |
| 12:09 |
bshum |
But I always assumed that it was because we weren't breaking things up more granularly. |
| 12:10 |
bshum |
@hate A/T |
| 12:10 |
pinesol_green |
bshum: The operation succeeded. bshum hates A/T. |
| 12:11 |
|
jwoodard joined #evergreen |
| 12:17 |
bshum |
Anyone have an opinion on https://bugs.launchpad.net/evergreen/+bug/1125471 ? |
| 12:17 |
pinesol_green |
Launchpad bug 1125471 in Evergreen 2.4 "Use label instead of id in recording in-house use prompt" (affected: 2, heat: 10) [Medium,Confirmed] |
| 12:17 |
bshum |
Seems like it'd be a straightforward change from ID to type. |
| 12:18 |
bshum |
phasefx: Any reason we used ID over name? |
| 12:19 |
* phasefx |
looks |
| 12:22 |
phasefx |
bshum: ooh, I don't remember any of that stuff; I'll take a look again after lunch :) I think that was just oversight. No reason not to show the name/label of the noncat type there instead of a barcode |
| 12:23 |
bshum |
phasefx: No worries, it's pretty old, but I wasn't sure if there was some sort of reason. Thanks. |
| 12:39 |
|
jwoodard joined #evergreen |
| 12:42 |
|
snowball joined #evergreen |
| 12:42 |
|
sseng joined #evergreen |
| 12:49 |
|
ktomita joined #evergreen |
| 12:49 |
|
sseng joined #evergreen |
| 13:05 |
|
jihpringle joined #evergreen |
| 13:13 |
|
jboyer_laptaupe joined #evergreen |
| 13:19 |
|
ericar joined #evergreen |
| 13:26 |
fparks |
I am working on a new rendition of Boolean Search https://bugs.launchpad.net/evergreen/+bug/1152863 |
| 13:26 |
pinesol_green |
Launchpad bug 1152863 in Evergreen "Support for traditional Boolean operators" (affected: 3, heat: 18) [Wishlist,Triaged] |
| 13:26 |
fparks |
Currently I'm stuck on how to store translations for keywords. |
| 13:28 |
fparks |
Is anyone familiar with what best practices would be in this case? |
| 13:30 |
|
smyers_ joined #evergreen |
| 13:42 |
|
hbrennan joined #evergreen |
| 13:46 |
|
ktomita joined #evergreen |
| 13:50 |
|
jboyer_laptaupe joined #evergreen |
| 13:50 |
|
akilsdonk_ joined #evergreen |
| 13:50 |
|
sseng_ joined #evergreen |
| 13:51 |
|
ktomita__ joined #evergreen |
| 13:58 |
|
smyers__ joined #evergreen |
| 14:29 |
|
sseng joined #evergreen |
| 14:37 |
|
smyers_ joined #evergreen |
| 14:46 |
|
smyers__ joined #evergreen |
| 14:51 |
|
pmurray joined #evergreen |
| 14:57 |
|
roses joined #evergreen |
| 14:57 |
roses |
I'm upgrading my demo server from 2.3.7 to 2.5.2 and in the upgrade instructions it has these lines: cd /home/opensrf/Evergreen-ILS-2.5.2/Open-ILS/src/sql/Pg psql -U evergreen -h localhost -f version-upgrade/2.4.3-2.5.0-upgrade-db.sql evergreen psql -U evergreen -h localhost -f version-upgrade/2.5.0-2.5.1-upgrade-db.sql evergreen |
| 14:58 |
roses |
How do I do this from 2.3.7 to 2.5.2 |
| 15:05 |
|
sseng joined #evergreen |
| 15:11 |
dbwells |
roses: The instructions are assuming you are coming from 2.4. You cannot upgrade directly from 2.3 to 2.5, you must run the upgrade scripts in between as well. |
| 15:12 |
roses |
dbwells: I see that there are 10 scripts that I need to run. |
| 15:12 |
dbwells |
roses: In other words, you should find a script that goes from 2.3.x to 2.4.0, then 2.4.0 -> 2.4.1, and so on until you get to 2.4.3, then follow the instructions. |
| 15:12 |
|
stevenyvr joined #evergreen |
| 15:13 |
dbwells |
roses: depending on when 2.4 was released, there might not be a direct route from 2.3.7 to 2.4.0, so you may need to massage the early upgrade scripts until you are back on track. |
| 15:14 |
roses |
dbwells: I'm running the first script (.sql) and I'm having trouble with the password for evergreen - shouldn't it be evergreen because of #10 in the instructions? perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all \ --create-offline --database evergreen --host localhost --user evergreen --password evergreen |
| 15:15 |
dbwells |
roses: There is also at least one supplemental script for 2.4, so make sure you run that too, or at least understand what it does (sometimes scripts do something which gets done again later anyway, especially reingesting records). |
| 15:15 |
dbwells |
roses: Is this a test server? |
| 15:15 |
roses |
dbwells: Yes - a test server |
| 15:15 |
roses |
dbwells: Which I might just wipe and start with a fresh installation of 2.5 |
| 15:16 |
dbwells |
The password will be whatever you set it to when you set it up, your evergreen DB password. |
| 15:17 |
dbwells |
That is, if you ever login to the evergreen DB using 'psql', it will be the same username/password you use for that. |
| 15:19 |
dbwells |
It's might be nice to run through the upgrade scripts for general practice, understanding, and to test the scripts themselves, but unless you have a lot of data in your test server, installing fresh is probably easier. |
| 15:20 |
roses |
dbwells: Thanks. I found my password and now am going to run through the scripts. I might be back later. |
| 15:24 |
fparks |
I am working on a new rendition of Boolean Search https://bugs.launchpad.net/evergreen/+bug/1152863 |
| 15:24 |
pinesol_green |
Launchpad bug 1152863 in Evergreen "Support for traditional Boolean operators" (affected: 3, heat: 18) [Wishlist,Triaged] |
| 15:25 |
fparks |
Currently I'm stuck on how to store translations for keywords. |
| 15:25 |
fparks |
Is anyone familiar with what best practices would be in this case? |
| 15:30 |
|
Dyrcona joined #evergreen |
| 15:30 |
Dyrcona |
For some reason, my laptop just shut down. |
| 15:31 |
Dyrcona |
Fortunately, I only lost four lines of copy and paste, so I could past it again. |
| 15:33 |
Dyrcona |
bshum: Marque.pm exports MFHDs now! |
| 15:33 |
Dyrcona |
Unless someone really wants progress output, I think the branch is done. |
| 15:34 |
Dyrcona |
Well, one step remains and that is making marc_export a link to Marque.pm. |
| 15:44 |
Dyrcona |
'course we only 56 SREs in our database, so more eyes might be good on that part. :) |
| 15:44 |
Dyrcona |
...only [have] 56.... |
| 15:47 |
|
roses joined #evergreen |
| 16:10 |
phasefx |
bshum: I tried looking at the commit log for that line re: non-cat in-house, and I think it was indeed oversight + intermediate testing |
| 16:12 |
phasefx |
for those curious (and I only just now learned how to do this), I did git blame in_house_use.js, got a useless commit message for some whitespace cleanup, but then did this to get the commit prior to that: git blame in_house_use.js b228af4f~1 |
| 16:12 |
pinesol_green |
[evergreen|phasefx] Change each tab to 4 spaces in the staff client javascript files. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b228af4> |
| 16:35 |
Dyrcona |
learning++ |
| 16:35 |
Dyrcona |
I learned a new git trick today. |
| 16:35 |
Dyrcona |
I learned how to split up an old commit into different ones. |
| 16:36 |
dbs |
reset / add -p ? |
| 16:42 |
|
sseng joined #evergreen |
| 16:58 |
|
dcook joined #evergreen |
| 17:50 |
kmlussier |
Dyrcona: For https://bugs.launchpad.net/evergreen/+bug/980296, can I change the status from "In Progress" and remove you from "Assigned To"? You're done with that for now, right? |
| 17:50 |
pinesol_green |
Launchpad bug 980296 in Evergreen "Marking a lost item Claimed Returned does not void lost charges " (affected: 3, heat: 18) [Wishlist,In progress] - Assigned to Jason Stephenson (jstephenson) |
| 18:18 |
Dyrcona |
kmlussier: I just took care of it. |
| 18:18 |
kmlussier |
Dyrcona++ |
| 18:18 |
Dyrcona |
I was away from the keyboard having something to eat, then shoveling some snow. |
| 18:18 |
kmlussier |
If I don't get the release notes done tongiht, I'll do it in the morning. |
| 18:19 |
kmlussier |
Eating is good. Shoveling, not so much. |
| 18:19 |
bshum |
kmlussier: Since you assigned this... https://bugs.launchpad.net/evergreen/+bug/1155769 |
| 18:19 |
pinesol_green |
Launchpad bug 1155769 in Evergreen "Items repeated in tpac display, others not visible" (affected: 3, heat: 16) [Undecided,Confirmed] |
| 18:19 |
bshum |
Do you know how that bug is replicated? I've never been able to consistently get broken displays as described. |
| 18:19 |
Dyrcona |
dbs: git rebase -i / then edit the commit, reset HEAD^, add some files, commit, add the remaining files, commit, rebase --continue |
| 18:20 |
kmlussier |
I've seen it happen. You've got to find the right record to make it happen. |
| 18:20 |
kmlussier |
I was just about to test it and was first looking for a record. |
| 18:20 |
bshum |
And I'm not sure the change ktomita makes there to order by barcode instead of copy number would necessarily be good. Just for the folks who do use copy number in their cataloging. |
| 18:20 |
bshum |
Not us, for sure, but someone might? |
| 18:21 |
kmlussier |
Sounds like a good comment to make on the bug report. :) |
| 18:21 |
bshum |
Oh yes, I'll add it. |
| 18:21 |
kmlussier |
I was looking at that too, but then I wasn't sure what was copy number referred to there. |
| 18:21 |
bshum |
I'm just not sure how to connect the dots since I've never been able to get a record to misbehave to verify the problem. |
| 18:22 |
kmlussier |
I'll be happy to look on acorn to see if I can find one for you. |
| 18:22 |
bshum |
I assumed it was referring to asset.copy.copy_number |
| 18:23 |
bshum |
Which is normally empty if catalogers don't put a number in there during their work. |
| 18:23 |
kmlussier |
So maybe doing copy number then barcode might work. Instead of just eliminating copy number. |
| 18:25 |
bshum |
Hmm |
| 18:25 |
bshum |
I'm not sure what it'd do if there was a mix of NULL and actual numbers in that case. |
| 18:25 |
bshum |
Would it put the copy 1 ahead of the NULLs or after the NULLs |
| 18:26 |
bshum |
Either way I'll add my question to the ticket |
| 18:26 |
bshum |
I think after talking it out I understand the intent now. |
| 18:28 |
kmlussier |
Well, since it was already doing the copy number sorting, I expect it would continue handling nulls the same way as it does now, wouldn't it? |
| 18:31 |
bshum |
Probably right. |
| 18:31 |
kmlussier |
bshum: Got one for you. http://acorn.biblio.org/eg/opac/record/2881599 |
| 18:31 |
kmlussier |
The last barcode for Brookfield is duplicated on the next page when you click 10. |
| 18:31 |
kmlussier |
You'll probably find that there's one barcode missing from the display. |
| 18:32 |
kmlussier |
Or I should say the first barcode for Brookfield. |
| 18:32 |
bshum |
Gotcha, I see it there |
| 18:32 |
bshum |
Aha |
| 18:32 |
kmlussier |
Gotta love the Fifty Shades of Grey series for providing ready samples of records with lots of copies. |
| 18:43 |
bshum |
Okay, adding the fourth order by of barcode seems to resolve the issue on that record. |
| 18:43 |
bshum |
And you were right there was something hidden quietly there |
| 18:44 |
kmlussier |
I think it really became a problem because, sometimes, the hidden one might be the only copy that is checked in at the time. |
| 18:45 |
kmlussier |
So people aren't seeing that there's something on the shelf. |
| 18:45 |
bshum |
No it makes sense now. I just couldn't get enough symptoms to show, but how would you know something wasn't there unless you worked for a library affected. |
| 18:46 |
bshum |
And the solution worked out by ktomita makes sense now. Just might want to retain copy_number sorting for those who use it. |
| 18:47 |
kmlussier |
Makes sense to me. Thanks for looking at it Ben! |
| 18:47 |
kmlussier |
bshum++ |
| 20:03 |
|
afterl left #evergreen |
| 21:17 |
|
ktomita joined #evergreen |
| 22:20 |
|
stevenyvr joined #evergreen |
| 22:40 |
pinesol_green |
[evergreen|Bill Erickson] LP#1164720 Prevent empty names in TPAC lists - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=237b7e7> |
| 22:44 |
pinesol_green |
[evergreen|Ben Shum] LP1271218 - clarify how opt-in user notifications are shown in my account - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8ca1ea0> |
| 23:20 |
|
dcook joined #evergreen |
| 23:21 |
|
zerick joined #evergreen |
