Evergreen ILS Website

IRC log for #evergreen, 2019-08-12

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:00 sandbergja joined #evergreen
00:31 sandbergja joined #evergreen
00:45 sandbergja joined #evergreen
00:56 sandbergja joined #evergreen
03:25 Lucifer23 joined #evergreen
03:30 Shiv_Lucifer I am looking for a way to retrieve all the book details when i search for title but it is giving list of TCN ids.  For eg: https://<myapi>/osrf-gateway-v1?service=open-ils.​search&method=open-ils.search.biblio.multiclass.q​uery.staff&param={%22limit%22:20,%22offset%22:0}&​param=%22(title:harry%20potter%20hallows)&param=1
04:47 Glen joined #evergreen
04:47 gmcharlt joined #evergreen
04:47 Glen joined #evergreen
06:07 Shiv_Lucifer left #evergreen
06:08 shiv_Lucifer joined #evergreen
06:10 shiv_Lucifer I am looking for a way to get details of book when searching by title. It gives me list of ids now. For eg : https://<myapi>/osrf-gateway-v1?service=open-ils.​search&method=open-ils.search.biblio.multiclass.q​uery.staff&param={%22limit%22:20,%22offset%22:0}&​param=%22(title:harry%20potter%20hallows)&param=1 .. Is there anyway i can get all details whe
06:10 shiv_Lucifer n querying. Thank in advance.
06:54 JBoyer joined #evergreen
06:59 agoben joined #evergreen
07:11 rjackson_isl joined #evergreen
07:23 Lenin joined #evergreen
08:14 troy__ joined #evergreen
08:19 Lenin Does any one know how to retrieve record details without fetching record Ids. Doing a title search just gives list of record Ids instead of record details. I am trying to reduce the number of requests to fetch record details. Thanks.
08:20 bos20k joined #evergreen
08:38 mmorgan joined #evergreen
09:02 Lenin joined #evergreen
09:09 yboston joined #evergreen
09:17 jvwoolf joined #evergreen
09:31 * csharp wonders if Dyrcona's fix to bug 1799272 might prevent the timeouts we were seeing after enabling the "retrieve hold IDs, not titles" option
09:32 pinesol Launchpad bug 1799272 in Evergreen "SIP2 Hold Items Count Includes Unavailable Holds" [Wishlist,New] https://launchpad.net/bugs/1799272
09:45 * csharp also wonders if a "verified in production"-style tag for LP bugs would be useful
09:46 csharp I mean, if PINES is running something in production that no one else can realistically test, that might be a de facto signoff?
09:46 csharp (or CW MARS or Evergreen Indiana or KCLS, etc)
09:47 csharp @monologue
09:47 pinesol csharp: Your current monologue is at least 5 lines long.
09:47 alynn26 +1 verified in Production
09:50 mmorgan1 joined #evergreen
09:53 collum joined #evergreen
10:03 khuckins joined #evergreen
10:27 bos20k_ joined #evergreen
10:32 sandbergja joined #evergreen
10:38 Shiva joined #evergreen
10:59 aabbee joined #evergreen
11:01 mmorgan joined #evergreen
11:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
11:09 bos20k joined #evergreen
11:18 Christineb joined #evergreen
11:49 khuckins joined #evergreen
11:58 berick csharp: "verified in production" would be useful, I think, but not a de facto sign off
11:59 berick it's like a half sign off
12:03 jihpringle joined #evergreen
12:03 * mmorgan feels like if a system is running a fix in production, that should be at least as good as testing that fix in a Concerto test system.
12:05 sandbergja joined #evergreen
12:05 berick mmorgan: i don't disagree, but presumably whoever adds the 'verified in production' tag would also be adding a sign-off
12:05 berick my point is the combo is not the same as 2 sign-off's
12:06 berick it's 1 really good sign-off
12:07 JBoyer The other could be as simple as "I looked this over and didn't find any rotten code smell," if it's difficult to test directly. Just making sure that a fix to a weird problem doesn't accidentally introduce some local assumptions / policy is still valuable, even if you didn't encouter the original issue.
12:07 dbs It doesn't necessarily cover review for accessibility or other parts of the sign-off checklist that we're supposed to go through
12:08 dbs translation, etc
12:20 mmorgan berick: yes, a really good sign-off. So maybe a 'verified in production' tag could put a fix in a state where a core committer could do the final review like JBoyer suggests?
12:21 JBoyer Also, dbs++ for bringing up accessibility.
12:25 * mmorgan feels like she should know this, but where does the sign-off checklist live?
12:35 JBoyer don't feel bad mmorgan, once I found it, it was more unfamiliar to me than one would hope: https://wiki.evergreen-ils.org/doku.​php?id=dev:signoff_review_checklist
12:35 * JBoyer bookmarks
12:36 mmorgan JBoyer++
12:36 * dbs is unsure if there is anything that has superceded that checklist
12:40 collum joined #evergreen
12:42 JBoyer If so it should probably be updated, but some of the additions seem relatively modern.
12:42 JBoyer Should probably be some mention of the npm test steps in the web client(s) though.
12:49 Lenin joined #evergreen
12:55 collum_ joined #evergreen
12:56 collum__ joined #evergreen
13:19 csharp berick: makes sense to me that "verified in production" would be considered strong evidence in favor of a signoff and not an actual signoff
13:19 csharp (in other words, we agree :-) )
13:19 khuckins joined #evergreen
13:20 jvwoolf joined #evergreen
13:22 csharp my goal in thinking about that was addressing those fixes that linger because of difficulty in testing (jeffdavis has/has had a number of these over the years)
14:04 berick agoben: these dates are locked in, yeah? https://wiki.evergreen-ils.org/doku​.php?id=hack-a-way:hack-a-way-2019
14:11 rhamby berick: they are
14:12 berick thanks rhamby
14:21 awitter joined #evergreen
14:23 collum joined #evergreen
15:02 khuckins joined #evergreen
15:10 agoben Sorry, distracted, but those are the dates as confirmed by rhamby, yes.
15:11 rhamby rhamby: you haven't upgraded to doing 20 things at once yet?  :)  (joking as even without knowing specifics I know you're busy as heck)
15:11 rhamby agoben: ^^^^ (apparently I really am talking to myself)
15:11 agoben :)  Sleep is for the weak, amiright?
15:12 rhamby I'm pretty weak then, I mostly slept this weekend.
15:15 berick berick: get a load of this rhamby guy.
15:15 berick agoben: no worries, kind of a dumb question, just making extra sure
15:15 rhamby heh
15:20 agoben Weekends are good for crashing if you don't sleep all week though.  I'm a fan of the Weekend Luxury Nap Experience myself!
16:12 mmorgan sleep++
16:12 mmorgan naps++
16:23 jvwoolf left #evergreen
17:08 mmorgan left #evergreen
17:10 khuckins joined #evergreen
18:58 sandbergja joined #evergreen
22:47 sandbergja joined #evergreen
23:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat
http://irc.evergreen-ils.org/evergreen/2019-08-12
irc.evergreen-ils.org
crawl=CC-MAIN-2019-43
31730
application/http; msgtype=response
sha1:J7K7AGLWW4JH3BLKYOEUEOVJCK275ZKW
<urn:uuid:bafa0c04-2066-4292-9bdf-b8f51acb4c28>
2019-10-19T02:14:53Z
168.25.130.30
application/xhtml+xml
sha1:P4V7STE7QIV2RNSHNJEXHA7CDPYYN7AW
<urn:uuid:35fd44d3-7e27-4ab5-9844-373b74dc3034>
http://irc.evergreen-ils.org/evergreen/2019-08-12
response
<urn:uuid:25b2ed1b-a36d-4d94-ab49-84de973a3a03>
isPartOf: CC-MAIN-2019-43
publisher: Common Crawl
description: Wide crawl of the web for October 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-47.ec2.internal
software: Apache Nutch 1.16 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/