Evergreen ILS Website

IRC log for #evergreen, 2019-05-09

| 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
05:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:02 dteston joined #evergreen
11:34 serflog joined #evergreen
11:34 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
11:41 serflog joined #evergreen
11:41 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
11:44 serflog joined #evergreen
11:44 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
11:47 serflog joined #evergreen
11:47 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
11:48 serflog joined #evergreen
11:48 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
11:48 pinesol joined #evergreen
11:51 Dyrcona Bmagic: I didn't think that required extra permission. It's just a warning that pops up and says you're deleting the last copy.
11:52 jihpringle joined #evergreen
11:53 jeffdavis Is gitolite admin causing headaches?
11:54 serflog joined #evergreen
11:54 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
11:54 pinesol joined #evergreen
11:54 gmcharlt jeffdavis: it's not causing any immediate problems for me either
11:54 Dyrcona Bmagic: Depending on settings, the user may also require the DELETE_VOLUME and DELETE_RECORD permissions if they delete the last copy.
11:54 pastebot "gmcharlt" at 168.25.130.30 pasted "I am the very model of a moder" (1 line) at http://paste.evergreen-ils.org/10000
11:55 jeff The sodgers@tadl.org account doesn't show signs of being accessed.
11:55 jeff er.
11:55 jeff *sigh*
11:55 jeff paste 10000, whee!
11:56 Dyrcona yay! the bots are working... gmchartl++ jlamos++ awitter++ dteston++ csharp++
11:57 Dyrcona gmcharlt++ // spelling
12:04 jeffdavis Github might make it easier for more people to contribute code. But our biggest problems right now are (a) the complexity and difficulty of the process to get code accepted and relatedly (b) a shortage of experienced developers/testers who can review and commit changes. Merely contributing a patch is actually the easy part.
12:06 jeffdavis (not an argument against switching, just an acknowledgement of what it won't do for us)
12:07 gmcharlt and switch wouldn't per se speed up the patch review process
12:07 gmcharlt although indrectly, it might in time
12:08 yboston joined #evergreen
12:08 gmcharlt via the potential for more tooling to to do at least basic checks on patches automatically
12:08 gmcharlt and the longer-term potential of lowering the barrier a bit, thereby in time getting more folks to review patches
12:09 gmcharlt but to be hoenst, I'm not per se much concerned about lowering the barrier for random drive-by contributions
12:09 gmcharlt I mean, sure, there will be the occassion superpatron or a random coder or documenter who may want to adopt Evergreen as a hobby project
12:09 gmcharlt it's more the barrier to library staff (and library-adjacent staff) that I think matters
12:10 Bmagic Drycona: right, it should just be an informational dialog box, but it seems that when deleting in batch from copy bucket, it's a login prompt. I've asked the library for a screen shot.
12:10 gmcharlt (though note: not an argument for or against switching either)
12:12 Dyrcona Bmagic: That sounds like their auth session timed out if they're getting a login prompt.
12:12 Bmagic or perhaps there is a permission required that they don't have but they didn't tell me what it was
12:13 Dyrcona Bmagic: Or that... They'll need the extra permissions that I mentioned earlier if the options are set to delete the last volume and bib record when the last copy is deleted.
12:14 Bmagic that could be it
12:14 csharp they could be calling the "override this if you have the right perms" box a "login prompt"
12:14 Bmagic csharp: yeah, I don't think there is confusion about that
12:14 Dyrcona or the warning box.
12:14 csharp ok
12:15 Bmagic they are getting a login prompt for sure. They provide the admin login and it works
12:15 Dyrcona OK, so likely a missing permission.
12:15 Bmagic circ staff are doing the bucket delete but having to provide admin login when an item in the group of items is "special" - last volume is what they said they see.
12:16 Dyrcona They probably need the DELETE_RECORD permission, then. You should check the perms for their profile.
12:16 Dyrcona I'm not sure I'd want to give circ staff that permission, though.
12:17 Dyrcona So, changing the options to delete empty bibs might be a better choice, but that's up to you and your group to decide.
12:17 mmorgan Bmagic: Could there be one or more items in the bucket that they do not have permission to delete?
12:18 Bmagic we did cover that
12:18 Bmagic mmorgan: the copy is their copy
12:19 * Dyrcona questions having circ staff deleting copies in buckets, but not my circus...
12:20 mmorgan Oh, only one copy in the bucket?
12:22 Bmagic mmorgan: several copies, but just one with the issue
12:24 Bmagic OK - more info - it's a cataloger account, not circ, Sorry Dyrcona. The volume has a "creator" of 1 but an owning_lib of thier lib. The staff account has DELETE_VOLUME at the system level. Does it need the creator to be themselves?
12:25 Bmagic DELETE_RECORD is also granted to this account at the consortium level (0)
12:25 csharp I would expect *something* to show up in the logs about it
12:25 Bmagic yeah, the lag time between this report and now is to great
12:26 csharp oh - hmm
12:27 mmorgan Bmagic: volume creator doesn't need to be that usr.
12:27 Bmagic mmorgan: ok, that's good
12:28 mmorgan How do you know which item in the bucket is causing the login prompt?
12:28 Bmagic They provided the barcode, I assume because the interface told them
12:28 Bmagic using web client
12:30 nfBurton joined #evergreen
12:30 miker re gitlab, there's also the directory protection (docs committers, recently discussed I think?) that we'd lose IIRC. maybe that's not important and we can enforce by policy since we're stingy with the commit bit?
12:34 jeff I don't know without looking if you can protect a directory with GitLab or GitHub. The docs commit workflow could move to a docs branch + pull request, and docs automations/CI could build off the docs branch. Roughly sketched, other details here.
12:35 jeff That is to say, I did look at GitHub regarding that feature the other day, and didn't find anything promising.
12:35 miker sorry, I meant github
12:36 Dyrcona Either choice will lead to some workflow changes.
12:36 miker I'm in favor of dropping gitlab as a selfhosted successor option to gitolite
12:37 miker I have FEELINGS about spinning off our main repo to a hosted solution, but they're admittedly mostly rooted in the non-distributed world. breaking everything is much harder now that we each have a full, real copy
12:37 bshum Just thinking aloud, but couldn't we split off docs into their own branch like we used to do if it'll work better with the new process
12:38 bshum Meaning they used to be separate, they could be separate again
12:40 jeff Bmagic: were you working on some LOST/LONGOVERDUE bug/branch/proposal at the conference? I have this vague recollection of a debate regarding LONGOVERDUE...
12:41 csharp so many debates about LONGOVERDUE  :-/
12:41 * jeff nods
12:41 csharp thinking mainly of the internal PINES debates :-)
12:42 csharp but the result PINES landed on is super confusing to the rest of the EG folks
12:43 phasefx miker: I still have feelings about purity over pragmatism
12:43 phasefx to be clearer, I'm more in favor of purity
12:44 csharp https://pines.georgialibrar​ies.org/annual-meeting-2006 was the first discussion of long-overdue in PINES iirc
12:44 Bmagic jeff: bug 1331174
12:44 pinesol Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174
12:45 Bmagic berick reviewed my patch at the conference and I am making some agreed upon changes asap
12:46 Bmagic we've been running the patch as-is in production for 4 years
12:54 mmorgan csharp: What result did PINES land on re: longoverdue?
12:54 mmorgan This bug comment describes NOBLE's process: https://bugs.launchpad.net/eve​rgreen/+bug/1562061/comments/6
12:54 pinesol Launchpad bug 1562061 in Evergreen 3.1 "Marking a Long Overdue transaction Lost adds a second bill to the patron record" [Medium,Confirmed]
12:56 mmorgan Ultimately, we opted to charge the bill at the long overdue stage, so bug 1331174 no longer affects us.
12:56 pinesol Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" [Wishlist,Confirmed] https://launchpad.net/bugs/1331174
13:09 jeff not only did i just unexpectedly run across a comment of my own in that bug, i'm pretty sure i know exactly where i was when i made the comment.
13:09 jeff (which is probably better than "i have no memory of this place" gandalf)
13:11 jeff unfortunately, i can not recall which aspect of this i was debating...
13:13 jeff oh, nope. i think i've got it now. :P
13:19 sandbergja joined #evergreen
13:32 berick miker: i had similar feelings re: handing the code off to somebody what could make it disapper. a CRON'ed regular 'git remote update' on a local clone mostly resolved that for me.
13:32 berick anyone recall if the github or gitlab tickets/issues/whatever are tracked in a repo as well?
13:32 berick i know you can clone the github wiki repos...
13:39 berick looks like both have csv exports
13:39 berick not seeing any indication of them being in a checkout-able repo
13:40 csharp mmorgan: for PINES, longoverdue was originally meant to do exactly what automatic lost does but with a different label so that staff immediately knew that it was done by the system as opposed to a staff member manually marking an item lost
13:41 csharp but when we saw what "lost.auto" was doing, there were a few tweaks in the way we wanted longoverdue items to work vs. lost.auto
13:43 csharp especially in the way fines and charges were handled (voiding fines when marked longoverdue and applying replacement cost + proc fee, then reversing the process if the item was returned within 6 months)
13:44 csharp but when that landed in stock EG, lots of other libraries started using the feature as something like an intermediate status between "overdue" and "lost", which led to some bug reports that had us scratching our heads
13:44 csharp not sure what people out there in the Real World™ are doing nowadays :-)
13:45 csharp we probably have the PINES requirements doc lying around somewhere
13:58 stephengwills joined #evergreen
13:59 khuckins joined #evergreen
14:03 jeff when testing A/T event defs for email, our general workflow is to run with a dedicated granularity on a system configured to hold all messages in its queue, then review the messages and either release them or delete them.
14:03 sandbergja_ joined #evergreen
14:04 jeff if we go the "delete" route, we then "reset" the events in the database, fix, re-run, etc.
14:05 jeff i think others may override the To: address in the template to all go to a single mailbox for review, then after success and changig the To: back to normal, reset/re-run the events (or perhaps just wait for the next "actual" run, depending).
14:05 abowling missing something here and hoping someone can help solve a pretty simple thing. in config.coded_value_map, i have opac_visible set to 'f' for some items on ctype "search_format," but they still appear in the dropdown on the main opac search page, in spite of the fact that they shouldn't?
14:05 jeff anyone else here (or in a presentation somewhere) have a different/better approach?
14:06 abowling to wit: 611 | search_format | braille      | Braille                       | Braille                       | f
14:06 abowling where 'f' is opac_visible column
14:07 abowling disregard.
14:07 abowling autogen was run...but apache2 was not restarted.
14:07 abowling ^fixed the issue
14:07 csharp rubber_ducking++
14:08 abowling csharp++
14:09 abowling csharp: calling jlamos has the same effect for me 97%+ of the time. the second he says 'hello', he almost always gets 'nevermind. figured it out'
14:10 csharp haha - yep
14:25 * berick writes many emails 3 times, learning so much along the way
14:28 jeff berick++ yep!
14:31 jeff "When deleting an email without sending it whose body contains more than four paragraphs, the Mail User Agent MUST quack like a duck via one of the methods described in Appendix C."
14:34 sandbergja_ joined #evergreen
14:40 Dyrcona So, gitlab basically said, "Sign up to see if you qualify," and sent me a link. They also said that "all of your projects need to be open source to qualify."
14:41 Dyrcona Sounds like the community/foundation would have no trouble getting a free license, but for an organization like CW MARS, it may be more tricky, though I'm pretty sure we qualify, too.
14:41 Dyrcona And as for hosted vs. self-hosted, I think the community would benefit from a hosted solution, as it will be one less server to worry about maintaining.
14:46 Dyrcona I also think that I should have objects to both gitlab and github on the grounds of neither is really F/OSS, but I obviously don't have very strong objects because I am using both.
14:46 Dyrcona s/objects/objections/
14:49 * Dyrcona forgot the g on the above substitution. :)
14:51 Dyrcona @blame Allergies
14:51 pinesol Dyrcona: It really IS Allergies's fault!
14:57 yboston joined #evergreen
14:59 * mmorgan 's system is one of those to which csharp refers, using long overdue as an intermediate between overdue and lost.
15:00 * mmorgan needs to shift gears and ask an edi question. I have a row in acq.edi_message that is stuck with status 'translated'. How can I get that unstuck so it completes?
15:03 Dyrcona mmorgan: What type of message?
15:04 mmorgan Dyrcona: ORDERS
15:05 Dyrcona Have you tried manually running the order pusher to see what happens?
15:06 Dyrcona I've not actually had to deal with this, so I might be of limited help. I've usually had situations where the a/t fails to complete.
15:07 mmorgan Dyrcona: First waited til the pusher ran again to see if it would complete, but pusher ran, and it did not complete :-(
15:07 Dyrcona Is there an error_time in the database table?
15:08 Dyrcona And an error.
15:11 mmorgan Dyrcona: Nope, no error. The problem was that someone restarted services at a bad time :-[
15:12 Dyrcona So, here's what I would do: 1. Find the a/t event in the action_trigger.event table. 2. Delete the acq.edi_message. 3. Open up srsfsh and make the following request:
15:12 pastebot "jeffdavis" at 168.25.130.30 pasted "reset an EDI purchase order" (16 lines) at http://paste.evergreen-ils.org/10001
15:13 Dyrcona request open-ils.trigger open-ils.trigger.event.fire {action_trigger.event.id}
15:13 Dyrcona Or, you could do what jeffdavis does. :)
15:14 mmorgan Dyrcona++
15:14 mmorgan jeffdavis++
15:14 jeffdavis More or less the same thing I think. Sorry to interrupt! :)
15:14 Dyrcona I'm pretty sure event.fire works on completed events, but it may not.
15:15 Dyrcona I mostly use it on "collected" events.
15:15 jeffdavis There should probably be a UI to do this, it happens to us every couple months.
15:15 mmorgan I would have been a little concerned if the suggested fixes were different :)
15:15 Dyrcona S'pose I could check, but I don't remember it checking the state of an event before running it again.
15:16 * mmorgan runs off to clean up mess
15:16 mmorgan Thanks!
15:16 Dyrcona What happens to me every couple of months is the event gets stuck in collected. I don't seem to have a problem with the messages if the event actually goes to complete.
15:16 JBoyer I think I saw reference to an A/T bug report today that should help with that significantly. You know, on the other side of the fix/test/patch process. :)
15:17 jeffdavis bug 1218423 for the feature request, but perhaps other changes will make it unnecessary?
15:17 pinesol Launchpad bug 1218423 in Evergreen "Acq: Do we need a feature to resend EDI purchase orders?" [Wishlist,Triaged] https://launchpad.net/bugs/1218423
15:20 Dyrcona And, unrelated, but a pg_restore of an Evergreen schema seems to work into Pg 10, even if the Pg 10 patches have not yet been applied to the schema.
15:20 Dyrcona I'm testing Pg 11 also because it's there.
15:21 Dyrcona I think it was installed because the generic postgresql packages were installed when I switched apt repos and did the upgrade.
15:21 Dyrcona Well, I know that's how ti showed up.... :)
15:24 Dyrcona So, maybe we'll support Pg 11 by the time that Pg 12 comes out... :)
15:26 csharp mmorgan: what you're dealing with is exactly why we've happily moved to non-A/T EDI ordering - in that case, you would just delete the bad EDI message and don't have to deal with the A/T resetting headache
15:27 mmorgan1 joined #evergreen
15:42 JBoyer gmcharlt++
15:58 abowling1 joined #evergreen
16:06 abowling joined #evergreen
16:13 yboston joined #evergreen
16:55 mmorgan joined #evergreen
17:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:23 mmorgan left #evergreen
17:39 yboston joined #evergreen
23:59 sandbergja joined #evergreen

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