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 sodgerstadl.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.georgialibraries.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/evergreen/+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 |