| Time |
Nick |
Message |
| 00:56 |
|
terranmc joined #evergreen |
| 01:54 |
|
terranmc joined #evergreen |
| 05:29 |
|
artunit_away joined #evergreen |
| 05:53 |
|
artunit_away joined #evergreen |
| 07:22 |
|
rjackson_isl joined #evergreen |
| 07:38 |
|
Dyrcona joined #evergreen |
| 07:40 |
|
rlefaive joined #evergreen |
| 07:51 |
pinesol_green |
[evergreen|Jason Stephenson] Add entries to .mailmap. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e6f79f6> |
| 07:52 |
|
ericar joined #evergreen |
| 07:55 |
graced |
TGIF #evergreen |
| 07:55 |
graced |
@coffee |
| 07:55 |
* pinesol_green |
brews and pours a cup of Kenya Kiandu, and sends it sliding down the bar to graced |
| 08:03 |
Dyrcona |
@tea |
| 08:03 |
* pinesol_green |
brews and pours a pot of Bio Pao Chung Pouchong, and sends it sliding down the bar to Dyrcona (http://ratetea.com/tea/teehaus-bachfischer/bio-pao-chung-pouchong/7609/) |
| 08:03 |
* Dyrcona |
is bug wranglin'. |
| 08:04 |
Dyrcona |
series/milestone wranglin', too. |
| 08:11 |
Dyrcona |
Prepare for a "flood" of email. :) |
| 08:14 |
JBoyer |
postfix at 12.0.0.1 says: 250 DELUG |
| 08:26 |
Dyrcona |
:) |
| 08:27 |
Dyrcona |
Just 25 emails so far, and I'm done. |
| 08:29 |
|
mrpeters joined #evergreen |
| 08:30 |
Dyrcona |
At some point, we should remove series targets on "Won't Fix" bugs. Maybe at the next point release. |
| 08:31 |
JBoyer |
I'd think that could be done any time since they're considered Won't Fix? |
| 08:31 |
Dyrcona |
True. |
| 08:32 |
Dyrcona |
I didn't want to do it this morning so people could have a chance to review them. |
| 08:32 |
Dyrcona |
2.8.8 was the last release in that series barring security fixes. |
| 08:33 |
Dyrcona |
The handful that are still targeted at 2.7 could probably be dropped from the series immediately. |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:42 |
|
maryj joined #evergreen |
| 08:43 |
jeff |
launchpad doesn't really have an "affects" metadata field, does it? |
| 08:45 |
Dyrcona |
No, but you can can say a bug also affects another project. |
| 08:45 |
Dyrcona |
Targeting at series and milestones are the closest to what I think you mean. |
| 08:46 |
Dyrcona |
I did remove the 2.8 and 2.9 series on one "bug" that is wishlist. |
| 08:47 |
* Dyrcona |
personally thinks we should be more strict in what we consider a bug vs. a new feature. |
| 08:48 |
Dyrcona |
There are a number of bugs that I think are new features, but there's often an explanation of why the OP considers it a bug and not a feature. |
| 08:48 |
Dyrcona |
So, I go with it. |
| 08:51 |
Dyrcona |
edoceo++ # When I Googled a ssh error the other day, your site came up as the top result. |
| 08:56 |
JBoyer |
I think for a lot of people less familiar with software "it doesn't work the way I want" is always considered a bug, even when "the way they want" involves adding a new feature. :) Makes bugs interesting. |
| 08:57 |
Dyrcona |
One person's bug is another person's feature. :) |
| 09:00 |
JBoyer |
I don't know much about selling computers, but I think if you're offering a $2M option for a $20K machine something has gone awry. |
| 09:00 |
JBoyer |
But the company does have "Enterprise" in the name, so... par for the course I suppose? |
| 09:01 |
Dyrcona |
Yep. |
| 09:01 |
mmorgan |
@decide Bug or Feature |
| 09:01 |
pinesol_green |
mmorgan: go with Bug |
| 09:02 |
* mmorgan |
usually does just that! |
| 09:03 |
|
dbwells joined #evergreen |
| 09:04 |
Dyrcona |
@decide Spy or Resistance |
| 09:04 |
pinesol_green |
Dyrcona: go with Resistance |
| 09:23 |
Dyrcona |
@decide Chrissie Hynde or Chrissy Amphlett |
| 09:23 |
pinesol_green |
Dyrcona: go with Chrissie Hynde |
| 09:48 |
|
mllewellyn joined #evergreen |
| 10:00 |
|
mmorgan1 joined #evergreen |
| 10:22 |
gmcharlt |
Dyrcona: berick: I'll put together a blog post announcing the releases now |
| 10:22 |
gmcharlt |
are there any additional comments you'd like me to include? |
| 10:22 |
Dyrcona |
Nothing from me. |
| 10:22 |
Dyrcona |
gmcharlt++ |
| 10:23 |
berick |
gmcharlt: thanks. nothing from me. 2.8.8 was almost a non-release |
| 10:23 |
berick |
gmcharlt++ |
| 10:24 |
gmcharlt |
berick: am I remember correctly that starting with 2.8.9, 2.8.x is going security-only? |
| 10:24 |
berick |
gmcharlt: yes, that's right |
| 10:24 |
berick |
def. worth mentioning |
| 10:24 |
bshum |
If there is a 2.8.9 |
| 10:24 |
gmcharlt |
right |
| 10:25 |
gmcharlt |
I'll phrase it something like this: "2.8.8 is the last normal release in the 2.8.x series, although security releases may be made if warranted" |
| 10:25 |
berick |
poifect |
| 10:27 |
|
rlefaive joined #evergreen |
| 10:28 |
Dyrcona |
nyuk nyuk nyuk |
| 10:29 |
|
collum joined #evergreen |
| 10:36 |
Dyrcona |
@cookie |
| 10:36 |
pinesol_green |
Dyrcona: Have you tried taking it apart and putting it back together again? |
| 10:36 |
Dyrcona |
No, but I did try eating it. It was delicious. |
| 10:37 |
|
Bmagic joined #evergreen |
| 10:37 |
|
ericar_ joined #evergreen |
| 10:38 |
|
ericar__ joined #evergreen |
| 10:42 |
|
Christineb joined #evergreen |
| 10:46 |
|
justdoglet joined #evergreen |
| 10:56 |
|
cprince joined #evergreen |
| 11:01 |
|
brahmina joined #evergreen |
| 11:35 |
|
bmills joined #evergreen |
| 11:47 |
dbs |
youse_guys++ |
| 11:50 |
Dyrcona |
heh |
| 12:02 |
|
maryj joined #evergreen |
| 12:07 |
|
mmorgan joined #evergreen |
| 12:13 |
|
jihpringle joined #evergreen |
| 12:24 |
|
mrpeters joined #evergreen |
| 12:36 |
|
mllewellyn1 joined #evergreen |
| 12:40 |
|
rfrasur joined #evergreen |
| 12:42 |
* tsbere |
shakes his fist at spammers that think his name is Mike Rylander |
| 12:43 |
Dyrcona |
heh |
| 12:49 |
|
sandbergja joined #evergreen |
| 12:54 |
|
terranmc joined #evergreen |
| 12:54 |
miker |
ha! |
| 12:56 |
rfrasur |
apparently, I was mistaken that / blame was a command. Too bad. |
| 12:58 |
Dyrcona |
@blame rfrasur for being mistaken. |
| 12:58 |
pinesol_green |
Dyrcona: rfrasur stole Dyrcona's ice cream! for being mistaken. |
| 12:58 |
Dyrcona |
;) |
| 12:58 |
rfrasur |
syntax. Thank you. |
| 12:58 |
rfrasur |
@blame google |
| 12:58 |
pinesol_green |
rfrasur: google broke Evergreen. |
| 12:59 |
rfrasur |
@blame google for mistaking tsbere for miker |
| 12:59 |
pinesol_green |
rfrasur: google wants the TRUTH?! google CAN'T HANDLE THE TRUTH!! for mistaking tsbere for miker |
| 12:59 |
bshum |
chocolate++ # snickers satisfies |
| 13:00 |
* rfrasur |
chuckles |
| 13:14 |
|
terranmc joined #evergreen |
| 13:37 |
|
geoffsams joined #evergreen |
| 13:48 |
|
jvwoolf joined #evergreen |
| 13:58 |
|
mmorgan left #evergreen |
| 14:02 |
jvwoolf |
Hello lovely people! Does anyone know the reporter source where one may find messages generated through the "Staff-Generated Penalties/Messages" interface? |
| 14:04 |
jvwoolf |
User Standing Penalties seemed to make sense to me, but all I seem to be getting are system-generated penalties. |
| 14:08 |
tsbere |
jvwoolf: If you are looking at what I think you are then both would show up there. Have you confirmed that the users you are looking at have staff generated ones? |
| 14:09 |
jvwoolf |
Could very well be that I grabbed a library that doesn't use them. Just wanted to make sure I was barking up the right tree. |
| 14:09 |
tsbere |
jvwoolf: You could limit yourself to standing_penalty entries in a specific list, picking out only the manual-entry ones you care about. |
| 14:12 |
jvwoolf |
tsbere: Thanks. I was trying to run a big list first to see what the manual ones looked like. |
| 14:12 |
jvwoolf |
Maybe I'll poke at the database to see if I can find some before I go back to the reporter |
| 14:15 |
jeffdavis |
dbwells: do you have a moment to talk serials? |
| 14:16 |
dbwells |
jeffdavis: sure |
| 14:19 |
jeffdavis |
I have been revisiting serials sorting in bug 1429317. I have suggested a different approach there, and since you have done a lot with serials and had some feedback on an earlier attempt I was wondering if you think it seems feasible. |
| 14:19 |
pinesol_green |
Launchpad bug 1429317 in Evergreen "Serials in holdings view should be able to sort in ascending and descending order as well as by call number" [Wishlist,Incomplete] https://launchpad.net/bugs/1429317 |
| 14:20 |
jeffdavis |
It would involve modifying evergreen.ranked_volumes and/or evergreen.rank_cp to do some special handling for serials, which I'm not super keen about. |
| 14:22 |
jeffdavis |
(I am also pretty new to serials so it's entirely possible that I'm missing a ton of context and this is just a plain bad idea. :) |
| 14:23 |
dbwells |
It might be better for me to comment on the bug for general tracking of the conversation, but here are a few thoughts. |
| 14:24 |
dbwells |
First, my top priority would be getting the unit data into the copy table as an analog to the parts column. Like parts, the design of unit labels is meant to complement/complete the call number. |
| 14:25 |
dbwells |
I have code written from way back when that does this for JSPAC, so probably not too much work to adapt it to TPAC. |
| 14:26 |
dbwells |
Not sure if that should be a standalone bug (maybe it already is). |
| 14:27 |
dbwells |
Second, I don't think we need different sorts for chron and enum. If we do the job right, they should always be the same, I think. |
| 14:31 |
jeffdavis |
The chronological sort is the piece that our libraries have specifically asked for, I think because of inconsistency with enumeration. |
| 14:32 |
dbwells |
Finally, I don't think we need to bother with detecting anything. Once we have our "sorter" determined, we just add it to the pile, and only need to decide whether copies with no unit come before or after the copies with units, and where the new sorter falls in the sort chain. |
| 14:33 |
dbwells |
That last question is probably the trickiest bit, and might need a setting eventually to please everyone, but I think your recommendation of making serial order the top criteria makes enough sense to start with that and see how it goes. |
| 14:36 |
miker |
dbwells / jeffdavis: I have a thought. In the jspac days, units were just copies, and sorted like them, but the issues (and issuances) behind units were displayed seperately and in chron/enum order with a basic paging interface. Is there a reason we shouldn't keep issu{e|ance} and unit separate in the tpac, using the strengths of each? |
| 14:37 |
miker |
IOW, could we just bring back the expanded issuance display we had before? |
| 14:37 |
dbwells |
jeffdavis: We can certain factor both chron and enum into the sortkey. It would be super great if your libraries could provide an example case they would produce a different sort. It's not hard to believe such cases exist, but nothing jumps to mind for me. |
| 14:37 |
dbwells |
miker: we already have that. |
| 14:37 |
miker |
sorry, I thought we only had compressed issuance display |
| 14:40 |
dbwells |
Maybe I misunderstand. The setting is called "fully compressed" display, which can be a confusing overload of the word "compressed" in this context, but it acts how it always, did, giving you folded trees of issues. |
| 14:41 |
jeffdavis |
One option would definitely be to make that display more prominent, but as discussed the other day, I think you run into issues there with a confusing user experience. |
| 14:42 |
miker |
dbwells: do you have a record at heckman that looks like that? (I'm paging through a journal title search, but that's probably not an efficient way of looking for an example) |
| 14:44 |
jeffdavis |
dbwells: re chron vs enum, examples would include where the enumeration style changes either by cataloguers - IIRC I've seen changes from "V. 1" to "Vol. 1" which affected sort order - or by the serial itself (e.g. New Left Review changed its enumeration style in 2000). |
| 14:44 |
jeffdavis |
A sufficiently sophisticated sort order algorithm might handled those, but chron sort bypasses the difficulties and seems to work well. |
| 14:44 |
dbwells |
miker: our units do not circulate and are staff view only, unfortunately. |
| 14:44 |
miker |
jeffdavis: do you have an example link? I don't use serials much personally so I'm going from memory |
| 14:44 |
miker |
dbwells: ah, gotcha |
| 14:44 |
jeffdavis |
https://bwlcr.bc.catalogue.libraries.coop/eg/opac/record/108220410 |
| 14:45 |
jeffdavis |
miker: ^ see "Issues Held" near the bottom |
| 14:46 |
miker |
thanks |
| 14:47 |
|
rlefaive joined #evergreen |
| 14:50 |
dbwells |
jeffdavis: I absolutely agree that chron is the better baseline for sorting with enum as the secondary tie-break. So I guess the question is if anything exists the other way, such that a choice is needed. |
| 14:50 |
jeffdavis |
ah, I see |
| 14:52 |
dbwells |
I should also clarify something, as I'm being a little loose with my terms there. |
| 14:54 |
dbwells |
I think the primary sort for issuances should be 'date_published', which should match the chron caption when present, but will often be more complete. After all, in some cases, the there will be no chron caption at all, but we still record the date published. |
| 14:59 |
jeffdavis |
And for units with items from more than one issuance, we'd just sort using the earliest date_published? |
| 15:00 |
miker |
just a note ... the ranked_volumes function may be changing: https://bugs.launchpad.net/evergreen/+bug/1315552 |
| 15:00 |
pinesol_green |
Launchpad bug 1315552 in Evergreen "Duplicate initial search results where copy circ lib/call number owning lib are different" [Medium,Confirmed] |
| 15:01 |
miker |
that may be orthogonal to this discussion, or may not be ... I'm not sure because I'm not entirely clear on the end-user visible goal of the serials part |
| 15:01 |
miker |
(which may be an open question right now?) |
| 15:01 |
jeffdavis |
i.e. when the unit is created/edited (or an issuance is modified), generate a sort_key based on the date_published of the earliest issuance for any of the items contained in the unit? |
| 15:01 |
|
jihpringle joined #evergreen |
| 15:02 |
dbwells |
jeffdavis: yes |
| 15:02 |
miker |
jeffdavis: let's use the avg date! (j/k, and I'll step out of the serials question for now ;) ) |
| 15:02 |
dbwells |
:) |
| 15:02 |
jeffdavis |
Ok, makes sense. Although using "static" unit-based sort keys is tricky if we want to support different sort types by different org units... |
| 15:02 |
jeffdavis |
miker: I like it! :) |
| 15:03 |
jeffdavis |
also, the goal (at least for me) is to make serial units sort in a more consistent/coherent way in the main holdings display. |
| 15:03 |
jeffdavis |
which for serials I think is basically chronological order, disregarding weighting by availability (or inessential variations in call number format) |
| 15:04 |
miker |
do you have an idea for what it would look like? a mock up maybe? |
| 15:04 |
miker |
(I'm doing a GREAT job of stepping out of the serials discussion, I know!) |
| 15:04 |
jeffdavis |
miker: that link above shows how it is working for us now: https://bwlcr.bc.catalogue.libraries.coop/eg/opac/record/108220410 |
| 15:05 |
jeffdavis |
but Liam's changes to make that happen are not a good fit for inclusion in the main codebase, so I'm looking at other ways to implement the same effect |
| 15:05 |
miker |
jeffdavis: ah, ok, so that's sitka-local. I wonder if there's any stock examples, because your page looks good to me |
| 15:06 |
jeffdavis |
https://bwlcr.testing-210-2.catalogue.libraries.coop/eg/opac/record/108220410 shows the same record in 2.10, with Liam's fix reverted |
| 15:07 |
jeffdavis |
(it doesn't work as-is in 2.10, so rather than just tweaking it slightly, this seemed like a good time to see if I could rework it before we upgrade next month) |
| 15:12 |
jeffdavis |
dbwells: fwiw I'm asking locally to see if there is any use case for ever NOT using chronological sorting for serials; if not, that should simplify things |
| 15:12 |
dbwells |
jeffdavis: cool, sounds good |
| 15:14 |
jeffdavis |
dbwells: also, thanks for the discussion! I'll think about this some more and update LP when I have things sorted (so to speak) in my own mind |
| 15:16 |
dbwells |
jeffdavis: I am going to dig up my branch and rework it. I had similar conversations with a few others at the conference, so I think there's enough interest in seeing this in action to better understand and react to it. I think it fits this bug enought that I'll post it there early next week. Does that sound alright? |
| 15:17 |
jeffdavis |
That sounds great, thanks! |
| 15:21 |
dbwells |
jeffdavis: and thank you, too. Having more invested parties is always a good thing! |
| 15:31 |
dbs |
MFHD serials 4evah |
| 15:34 |
dbwells |
dbs: our serials person literally cried when MFHD record support got added. I'm pretty sure she was happy. |
| 15:40 |
|
jvwoolf left #evergreen |
| 15:49 |
|
sam_l joined #evergreen |
| 15:59 |
dbs |
dbwells: wow! |
| 16:07 |
|
jvwoolf joined #evergreen |
| 16:07 |
|
rlefaive joined #evergreen |
| 16:11 |
|
terranmc joined #evergreen |
| 16:12 |
dbs |
oh https://bugs.launchpad.net/bugs/1031335 some day you will be loved again |
| 16:12 |
pinesol_green |
Launchpad bug 1031335 in Evergreen "Email templates should always escape headers" [Medium,Confirmed] |
| 16:23 |
jeffdavis |
What is preventing that bugfix from getting into point releases? Signoff, tests, change in status...? |
| 16:27 |
pinesol_green |
[evergreen|Pasi Kallinen] Fix LP#1031335 by escaping some email headers automatically - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d88e362> |
| 16:27 |
pinesol_green |
[evergreen|Dan Scott] LP#1031335 No-op the escape_email_header helper - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6a8a4f0> |
| 16:29 |
jeffdavis |
heh |
| 16:30 |
dbwells |
turns out the only thing preventing it was an IRC expression of yearning |
| 16:31 |
Dyrcona |
Mabye... |
| 16:31 |
Dyrcona |
Maybe, even. |
| 16:34 |
dbs |
dbwells++ |
| 16:34 |
|
brahmina joined #evergreen |
| 17:11 |
|
jvwoolf left #evergreen |
| 21:32 |
jeff |
oh lovely. a vendor (who probably had trouble reaching an auth endpoint here) failed open instead of closed, and did so in a persistent manner. |
| 21:32 |
jeff |
such that I needed to place a phone call and am re-providing auth details from scratch. |
| 21:33 |
jeff |
probably has nothing to do with the fact that the vendor in question uses a CPC model. :P |
| 22:02 |
jeff |
So I get to write a script to verify a CSV of patrons and then either correct the ones who typed their card number incorrectly, or determine how to break the news to the patrons who aren't eligible for the service in the first place. |
| 22:02 |
jeff |
Ah well. |
| 22:07 |
|
dbs joined #evergreen |
| 22:07 |
|
gmcharlt joined #evergreen |
| 22:07 |
jeff |
never boring :-) |
| 22:13 |
* jeff |
wonders if both dbs and gmcharlt are at Zayo in Atlanta |
| 22:13 |
jeff |
yup! both Atlanta Linodes :-) |
| 22:13 |
jeff |
sorry for your connectivity issues :-) |
| 22:14 |
jeff |
https://linode.statuspage.io/incidents/gllf68tfzhtr |
| 22:36 |
jeff |
and of course i can leverage the failure to auth cards to break the CSV |
