| Time |
Nick |
Message |
| 03:39 |
|
gsams joined #evergreen |
| 06:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:07 |
|
agoben joined #evergreen |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
tlittle joined #evergreen |
| 07:33 |
|
collum joined #evergreen |
| 07:38 |
|
bdljohn joined #evergreen |
| 08:48 |
|
idjit joined #evergreen |
| 08:58 |
|
kmlussier joined #evergreen |
| 09:00 |
|
collum joined #evergreen |
| 09:13 |
|
yboston joined #evergreen |
| 09:14 |
|
lsach joined #evergreen |
| 09:18 |
miker |
Bmagic: one of the reasons evergreen doesn't have a sort-by-item-creation is that it's not entirely clear what that means. we have a create date, an active date, and it's not obvious whether the first or last item added is what's important in all cases. you can sort by bib creation time, which may be an OK proxy in most cases. there is, however, the new item supercat feed which sorts by the newest item create date per record, and can be limited by |
| 09:18 |
miker |
circ lib, status, and location |
| 09:20 |
|
jvwoolf joined #evergreen |
| 09:26 |
|
gmcharlt joined #evergreen |
| 09:37 |
|
collum joined #evergreen |
| 10:00 |
|
frank_g joined #evergreen |
| 10:02 |
frank_g |
Hi all, Yesterday I updated from 3.0.4 to 3.1.1 EG, but I am checking the TPAC and I cannot see the facet_box_wrapper section in search results, Is there any kind of new config to could see it? |
| 10:10 |
kmlussier |
frank_g: I can't think of anything added to 3.1 that would change the display of facets. There isn't a new config options for them. |
| 10:12 |
frank_g |
I dont know if modifyng styles I could re-write something wrong, |
| 10:12 |
kmlussier |
frank_g: Do you have entries in metabib.facet_entry ? |
| 10:14 |
frank_g |
kmlussier: yes, actually before updating this section was beeing displayed well |
| 10:16 |
|
jwoodard joined #evergreen |
| 10:16 |
kmlussier |
frank_g: OK. Since there is a full reingest as part of the 3.1 upgrade, I didn't know if something may have gone awry with the facet entries. |
| 10:17 |
|
beanjammin joined #evergreen |
| 10:21 |
frank_g |
kmlussier: Do you have the reingest command to re-run it? |
| 10:24 |
|
collum joined #evergreen |
| 10:24 |
kmlussier |
frank_g: It should be somewhere in the 3.1 upgrade script. But if you have those facet entries in the table, I don't think that would be the problem. |
| 10:26 |
miker |
frank_g: the internal search result format changed a bit from 3.0 to 3.1, IIRC, so you may want to confirm that any custom templates got the updates they need from the 3.1 stock versions, and just to be double-sure, confirm that /all/ EG perl modules on all servers involved (if you have separate app and apache servers) were updated and everything was restarted. (low hanging fruit first) |
| 10:28 |
Bmagic |
miker: Thanks for the details! I am wondering if such a development could be feasible? If we jumped the active/create date issue? |
| 10:31 |
miker |
Bmagic: I don't think we should ignore any of the open questions. there are solutions for each, if even via different sort names. but it wouldn't be hard to teach sort() to accept more than one parameter and use them as appropriate in context, really. if there are known open questions, we should solve them rather than getting used to half-implementations, IMO, especially if the extra effort is low relative to the "main" problem |
| 10:32 |
Bmagic |
miker: I might help some of our members create a specification |
| 10:33 |
miker |
I have a pet peeve where a new feature does /just enough/ to cover one use case, when with 10% more time/effort, it could be made into a general solution that future dev could build on. </rant> ;) |
| 10:33 |
Bmagic |
I certainly understand that |
| 10:36 |
Bmagic |
The use case for sorting items by create/active date seems to come up often. The bug that Justin filed is from 2014. Bug 1271725 |
| 10:36 |
pinesol_green |
Launchpad bug 1271725 in Evergreen "An OPAC integrated New Books feature sure would be nice" [Wishlist,Triaged] https://launchpad.net/bugs/1271725 |
| 10:36 |
|
Jaswinder joined #evergreen |
| 10:47 |
miker |
Bmagic: right, but which, and first or last copy? or should those /all/ be options? |
| 10:48 |
Bmagic |
I'm afraid I don't understand |
| 10:48 |
miker |
which of active/create, and do you want to know when something was first added, or most recently added (per org, say)? because I can see strong uses for /any/ of those |
| 10:49 |
Bmagic |
I gotcha, a new copy of an old title isn't as important as a new copy of a new title |
| 10:49 |
miker |
right |
| 10:50 |
Bmagic |
I believe a feature in this area should be able to cover those use cases |
| 10:50 |
miker |
and sometimes create date is more important than active date for, say, a "coming soon" list |
| 10:50 |
Bmagic |
yep, understood |
| 10:50 |
miker |
but sometimes it's active date, for "new, and available!" |
| 10:51 |
Jaswinder |
Hey Guys, I would like to know which table contains the Advance Search Fields |
| 10:52 |
Bmagic |
Jaswinder: Are you asking about format selection box and audience selection box for example? |
| 10:52 |
miker |
anyway, it looks like there's a bug that's stopping the "opac" format from workng as intended and redirecting the new-item feed to a result list. but, fixing that might be a stop gap |
| 10:53 |
Bmagic |
miker: /opac/extras/browse/rss2-full/item-age ? |
| 10:58 |
Bmagic |
Jaswinder: config.metabib_field and config.record_attr_definition will get you started |
| 10:58 |
miker |
Bmagic: yes, however, looking more closely, opac format isn't implemented for that particular feed type :( |
| 10:58 |
kmlussier |
I would think most recently added per org unit would be most useful. As far as a coming soon list, it would need to be based on more than just a create date since a consortium could have a mix of libraries that enter and do not enter on order materials. |
| 11:02 |
frank_g |
miker: How could I confirm all the perl modules involved are correctly installed? |
| 11:03 |
miker |
kmlussier: certainly, there are more details to fully support various use cases. my point is that we should recognize those other use cases when they're fairly obvious. and, "coming soon" is probably not the best example :) |
| 11:05 |
miker |
frank_g: the easiest way is probably to use `diff -purbB` to compare the installed copies to the copies in the tarball on each server. but the easier first step is to confirm template updates, if you have any search result customizations |
| 11:08 |
frank_g |
miker: Yes, I already checked the template updates |
| 11:11 |
|
collum joined #evergreen |
| 11:14 |
Jaswinder |
Bmagic: thanks |
| 11:14 |
Jaswinder |
let me check these tables; |
| 11:19 |
Jaswinder |
Bmagic: for the list of multiselect fields, is there an identifier to get a unique lsit |
| 11:24 |
|
collum_ joined #evergreen |
| 11:25 |
|
collum joined #evergreen |
| 11:27 |
Jaswinder |
I have this query which makes sense to me: SELECT distinct name, label, description FROM record_attr_definition where description is not null order by name; |
| 11:27 |
Bmagic |
Jaswinder: there are several tables involved |
| 11:27 |
Bmagic |
select distinct label from config.marc21_physical_characteristic_subfield_map will give you some stuff |
| 11:28 |
Bmagic |
select distinct label from config.marc21_physical_characteristic_type_map; |
| 11:28 |
Jaswinder |
Will there always be description for the search fields that appear on a Advanced search page? |
| 11:29 |
Bmagic |
config.marc21_physical_characteristic_value_map is another one. If you inspect the tables, you can see the relationships. That should help you down your path. |
| 11:32 |
|
jlamos joined #evergreen |
| 11:49 |
|
sandbergja joined #evergreen |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:16 |
|
yboston joined #evergreen |
| 12:18 |
|
bdljohn joined #evergreen |
| 12:38 |
|
jvwoolf joined #evergreen |
| 12:40 |
|
beanjammin joined #evergreen |
| 12:40 |
|
khuckins joined #evergreen |
| 12:49 |
|
terran joined #evergreen |
| 12:54 |
|
bdljohn joined #evergreen |
| 13:12 |
|
collum_ joined #evergreen |
| 13:28 |
|
kmlussier joined #evergreen |
| 15:04 |
|
yboston joined #evergreen |
| 15:45 |
|
kmlussier joined #evergreen |
| 16:14 |
|
khuckins joined #evergreen |
| 17:16 |
|
kmlussier joined #evergreen |
| 17:22 |
|
jvwoolf left #evergreen |
| 17:39 |
jeffdavis |
A bunch of our libraries are reporting problems with SIP since our upgrade to 3.1 but I can't reproduce any problems in testing. |
| 17:41 |
jeffdavis |
We had been running a pretty outdated version of SIPServer. It's up to date now. I've got some automated tests and they can consistently login, retrieve patron info, etc. No timeouts either. |
| 17:43 |
jeffdavis |
3M, Bibliotheca, PC Res all affected at one library or another. |
| 17:58 |
miker |
jeffdavis: do you have Socket::Linux installed? |
| 17:59 |
jeffdavis |
As of last night, yes (libsocket-perl and libsocket-linux-perl packages). It made an error message go away but libraries still report problems. |
| 17:59 |
miker |
hrm :( |
| 18:01 |
jeffdavis |
We're using the PreFork flavor, I'm thinking of trying Multiplex purely for lack of any better ideas. |
| 18:01 |
miker |
I have nothing better than that except to make sure they don't have transparent firewalls that drop idle sockets faster than 120s |
| 18:02 |
miker |
oh, I'd def move to multiplex. we only use that now |
| 18:03 |
miker |
If you do that, I recommend setting worker-keepalive to 65 on the server-params element |
| 18:03 |
miker |
hth ... I'm running away now! :) |
| 18:04 |
jeffdavis |
thanks, I'll give it a try |
| 18:30 |
pinesol_green |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
