| Time |
Nick |
Message |
| 03:38 |
|
graced joined #evergreen |
| 04:07 |
|
dcook__ joined #evergreen |
| 07:51 |
|
maryj joined #evergreen |
| 07:59 |
|
rjackson_isl joined #evergreen |
| 08:17 |
|
_bott_1 joined #evergreen |
| 08:21 |
kmlussier |
Bmagic: Stat cat would have found it. The problem is that LP doesn't search Fixed Released bugs by default. You have to go to advanced search to include those in your search. |
| 08:21 |
jeff |
the bott cloning project appears to have been successful (for values of success where true == 0.9972) |
| 08:22 |
|
_bott_2 joined #evergreen |
| 08:25 |
|
_bott_ joined #evergreen |
| 08:28 |
|
_bott_2 joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:33 |
|
pgardella joined #evergreen |
| 08:37 |
pgardella |
Anyone familiar with the reporter:template_folder schema and how they are shown to users? We've got a bunch of templates that don't show up in the client. |
| 08:39 |
|
mrpeters joined #evergreen |
| 08:43 |
|
mmorgan1 joined #evergreen |
| 08:44 |
jeff |
pgardella: templates are typically either per-user or shared. in the case of per-user, they'll only appear for that user. in the case of shared, they'll appear (in a different place -- under Shared, I think) only to those locations they have been shared with. |
| 08:44 |
jeff |
pgardella: can you give more specifics about one of the templates that isn't appearing where you'd expect? |
| 08:44 |
|
Shae joined #evergreen |
| 08:45 |
jeff |
pgardella: oh, and if you're looking at reporter.template_folder you'll probably also want/need to look at reporter.template. |
| 08:47 |
pgardella |
jeff: I'm looking at them now. I think that the templates are all still there, they've just been shared under different owners. They would be the Acquisitions reports that come from the equinox.git repo. |
| 08:48 |
pgardella |
jeff: So at this point, I need to go back to the catalogers to find out which one they are missing and find it. |
| 08:50 |
jboyer-isl |
pgardella: If they used to have access to shared reports and now can't see them, it may be a sharing bug. Try the queries under the List Reporter Folders with Bad Sharing Depths on this page: http://wiki.evergreen-ils.org/doku.php?id=scratchpad:random_magic_spells |
| 08:53 |
pgardella |
jboyer-isl: All three of those queries return no results. I think that's good :) |
| 08:53 |
jeff |
yep, zero results for those is good. |
| 08:53 |
jeff |
jboyer-isl++ i'd forgotten about that issue |
| 08:53 |
pgardella |
jboyer-isl++ |
| 08:53 |
pgardella |
jeff++ |
| 08:53 |
jboyer-isl |
Definitely. Now the simple fix is "is shared actually set to true" everywhere it needs to be? Hopefully that will be a simple fix. |
| 08:57 |
pgardella |
jboyer-isl: I think the issue is that the report templates are now owned by other users, which are not parent/child of one of the others. Most of the parents are null in template_folder |
| 08:58 |
pgardella |
All the folders except a few testing ones are shared, the templates just aren't where people expect them to be. |
| 08:58 |
jboyer-isl |
That's fine if they're not sub-folders. ("Templates", "Reports", and "Outputs" don't count as parent folders, even though that's how they're displayed.) |
| 09:00 |
* tsbere |
usually avoids sub-folders for a number of reasons |
| 09:21 |
|
jwoodard joined #evergreen |
| 09:22 |
|
ericar joined #evergreen |
| 09:29 |
|
_bott_ joined #evergreen |
| 09:37 |
|
maryj joined #evergreen |
| 09:38 |
Dyrcona |
So, why would the jedi column in acq,edi_message not match the results of running edi_reader.pl on the data from the edi column of the same acq.edi_message row? |
| 09:39 |
Dyrcona |
In my case, I have an INVOIC where the id of the lineitems in the jedi is the same for each lineitem: 16026. |
| 09:40 |
Dyrcona |
However, when I run the edi through edi_reader the output dump shows the id changing for each lineitem, and they're in the 33000 ball park. |
| 09:42 |
Dyrcona |
And, it only seems to happen with one library and one particular vendor. |
| 09:42 |
Dyrcona |
Other libraries don't have this problem with that or any other vendor. |
| 09:45 |
jeff |
knowing little-to-nothing about acq, if your config is similar i'd next look into something in the files themselves that is changing the behavior, either by bug or design (but not intention) |
| 09:45 |
jeff |
sorry, that's not very helpful. hopefully others have more for you. |
| 09:46 |
jeff |
oh, having just re-read... nevermind. |
| 09:47 |
Dyrcona |
Looks like I |
| 09:48 |
Dyrcona |
will have to try deleting the messages, etc., and try to inject them again to see what happens this time. |
| 09:48 |
kmlussier |
Dyrcona: Is it happening with every invoice between this library and this vendor? |
| 09:48 |
Dyrcona |
kmlussier: It looks like it is. |
| 09:49 |
Dyrcona |
I've only been looking at one in particular, but none of their other invoices process properly. |
| 09:49 |
* Dyrcona |
looks up the messages on PO 1395, it has multiple invoices. |
| 09:56 |
|
mmorgan1 joined #evergreen |
| 09:56 |
|
collum joined #evergreen |
| 09:59 |
Dyrcona |
Messages on the other purchase order look even stranger. |
| 10:00 |
Dyrcona |
I'm also comparing a Perl dump to JSON, so matching up the lineitems from one to the other is a bit annoying. |
| 10:01 |
|
_bott_1 joined #evergreen |
| 10:01 |
miker |
Dyrcona: is this vendor colloquially called by its initials joined by an ampersand? |
| 10:02 |
Dyrcona |
miker: No, it isn't. They don't seem to have a problem with that vendor. |
| 10:03 |
miker |
well, there's a first for everything, I guess ;) |
| 10:03 |
* miker |
runs to meeting #1 |
| 10:03 |
kmlussier |
Yeah, it's a vendor we usually have no trouble with. |
| 10:03 |
* kmlussier |
takes a closer look |
| 10:04 |
Dyrcona |
kmlussier: I'll put the data files I'm looking at on my dev system for you. |
| 10:14 |
|
yboston joined #evergreen |
| 10:17 |
jeff |
fun. apparently today is the day to gc every one of my remotes. |
| 10:17 |
jeff |
i suppose that might be a working copy setting and not maintained per-remote. |
| 10:21 |
|
collum joined #evergreen |
| 10:25 |
|
yboston joined #evergreen |
| 10:46 |
|
pgardella joined #evergreen |
| 10:46 |
pgardella |
I'm back looking at the template_folders again. It looks like no folders that are owned by egadmin are displayed in the client (even when logged in as egadmin). |
| 10:50 |
jeff |
given that you know the owning user's numeric user id, this query may help: SELECT id, parent, name, shared, share_with FROM reporter.template_folder WHERE owner = 123 AND shared = TRUE; |
| 10:50 |
jeff |
(replacing 123 with the numeric user id in question) |
| 10:52 |
pgardella |
jeff: all the subfolders show as expected |
| 10:54 |
tsbere |
pgardella: I will point out that as far as I know folders shared by a user do not show up in the shared section when logged in as them. Ever. |
| 10:56 |
|
dkyle1 joined #evergreen |
| 10:56 |
pgardella |
tsbere: Oh, OK. So when I log in as myself, I can see egadmin, but nothing shared by egadmin, only something shared by one of the other users |
| 10:58 |
tsbere |
pgardella: I dunno what is *wrong*, just that if you log in as yourself you don't see your own folders as "shared" folders, to my knowledge. |
| 10:58 |
pgardella |
tsbere: OK. |
| 10:58 |
tsbere |
pgardella: If logging in as egadmin causes the folders to not show up in the *upper* area for the current user's folders then I believe you have bigger concerns. |
| 10:59 |
gsams |
tsbere: that's right, your own reports only every show up under the My Folders section |
| 10:59 |
gsams |
whether shared or not |
| 10:59 |
pgardella |
tsbere: They don't show up in the "my folders" section either. |
| 11:00 |
tsbere |
pgardella: Then I suspect the folders themselves have something wrong beyond sharing issues. |
| 11:00 |
tsbere |
Maybe a bad character in one of the names? |
| 11:00 |
tsbere |
(that isn't playing nice with the interface for some reason) |
| 11:03 |
pgardella |
tsbere: Ah. Someone changed the owner of folder #1 |
| 11:03 |
pgardella |
tsbere++ |
| 11:04 |
tsbere |
pgardella: Yea, mixed ownership of parent vs sub folders will cause issues. |
| 11:04 |
gsams |
hehe, I had that happen to me just a few months ago. |
| 11:05 |
tsbere |
Tis one of the reasons I only change ownership of my own folders. Otherwise I only change the ownership and folder of the contents of the folders, leaving the original folder owner alone. |
| 11:06 |
|
vlewis joined #evergreen |
| 11:06 |
gsams |
tsbere: I try to avoid it altogether, sometimes others like to throw me a curve ball without realizing it. |
| 11:17 |
kmlussier |
A follow-up question on Dyrcona's acq problems. Would it cause problems if there is a space in the name of the PO? |
| 11:19 |
|
sandbergja joined #evergreen |
| 11:19 |
berick |
kmlussier: in the invoice? |
| 11:20 |
kmlussier |
I see 'RFF+LI:16026 AdultFic/32067' being translated as "id":"16026" when the id should be 32067 |
| 11:22 |
berick |
kmlussier: that might be a problem |
| 11:22 |
kmlussier |
berick: Yeah, I'm looking at POs from other libraries, and they don't seem to put spaces in their PO names. |
| 11:23 |
kmlussier |
It doesn't explain why the lineitems from POs with no spaces in the name are not loading at all, but it's something. |
| 11:23 |
berick |
looks like EDIReader.pm assumes (optional) PO names have no spaces. |
| 11:24 |
berick |
id => qr/^RFF\+LI:(?:\S+\/)?(\d+)/, |
| 11:24 |
kmlussier |
berick: Ah! Thanks for confirming that for me. |
| 11:24 |
berick |
i think you could change it to: |
| 11:24 |
berick |
id => qr/^RFF\+LI:(?:[^\/]+\/)?(\d+)/, |
| 11:25 |
kmlussier |
Dyrcona ^ ^ |
| 11:25 |
Dyrcona |
Yep, I was just reading it. |
| 11:26 |
Dyrcona |
Should we launchpad that? |
| 11:29 |
kmlussier |
Dyrcona: Yes, I think so. |
| 11:29 |
berick |
yeah |
| 11:29 |
|
mrpeters joined #evergreen |
| 11:29 |
kmlussier |
Either it should accommodate the spaces or it should stop people from entering them. Since it looks fairly easy to accommodate the spaces, I would go with that. |
| 11:31 |
Dyrcona |
OK. I'll give berick's suggestion a try on my dev system after lunch. |
| 11:32 |
Dyrcona |
Then, I'll LP it. |
| 11:34 |
kmlussier |
berick++ Dyrcona++ |
| 11:34 |
Dyrcona |
kmlussier++ berick++ |
| 11:50 |
* berick |
has been wanting to do this for a long time: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=c61ccec62a |
| 11:51 |
berick |
huh, thought that would wake up pinesol |
| 11:51 |
berick |
anyway, porting user update to cstore |
| 11:57 |
jboyer-isl |
berick, so close: Harder, Better, Faster, Stronger. |
| 11:58 |
berick |
jboyer-isl: doh! might call for a rebase |
| 11:58 |
jboyer-isl |
srsly though, berick++ for moving things out of .storage. |
| 12:00 |
dbwells |
berick++ indeed |
| 12:05 |
jeff |
berick++ |
| 12:05 |
miker |
berick: I think you removed the one and only use of the *.remote_update api that was intended for low-overhead object modification ... |
| 12:05 |
jeff |
berick: should verify_last_xact remain outside the transaction, or does it still retain visibility outside the transaction after this change? |
| 12:06 |
berick |
miker: ah, not surprised |
| 12:06 |
berick |
that's the only use of it I recall |
| 12:07 |
berick |
jeff: hm, no, it's checking the value before the patron is modified |
| 12:07 |
berick |
so should be fine within the transaction |
| 12:07 |
jeff |
(put another way, does it retain the ability after this change to notice when the xact has been changed outside the transaction, or is that a racy-enough condition that we can't care, compared to the usual "has changed since fetched/displayed for editing" use case? |
| 12:07 |
jeff |
yeah, i think i got there. :-) |
| 12:09 |
|
bmills joined #evergreen |
| 12:09 |
miker |
berick: we could remove about 2600 generated methods in the storage namespace ... and put storage on a nice diet. see lines ~721 and ~732 in OpenILS/Application/Storage/Publisher.pm |
| 12:09 |
|
bmills left #evergreen |
| 12:10 |
|
bmills joined #evergreen |
| 12:10 |
berick |
miker++ |
| 12:10 |
berick |
that would be great. i can look at that unless yr already in there |
| 12:12 |
berick |
looks like we can also remove sub remote_update (duh) and sub remote_update_node |
| 12:12 |
miker |
I'm not |
| 12:12 |
berick |
k |
| 12:13 |
miker |
berick: you mean in CDBI? |
| 12:13 |
berick |
yeah |
| 12:13 |
miker |
that's a different thing |
| 12:14 |
miker |
I mean, probably, but that's at a different layer ... a deeper, darker layer ;) |
| 12:14 |
berick |
heh, i'll leave it alone |
| 12:23 |
berick |
miker: seeing 1.12MB ram saving per storage drone, similar on the listener. |
| 12:24 |
* berick |
pushes to same branch |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:29 |
* miker |
is unsurprised :) |
| 12:29 |
miker |
I'm sure there's a few thousand more we could trim |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:35 |
mmorgan |
@weather 01923 |
| 12:35 |
pinesol_green |
mmorgan: Danvers, MA :: Clear :: 40F/4C | Wind Chill: 33F/1C | Tuesday: Lots of sunshine. High 43F. Winds WSW at 5 to 10 mph. Tuesday Night: Clear skies. Low 27F. Winds light and variable. | Updated: 42m ago |
| 12:36 |
* mmorgan |
supposes it could be worse when there's a fire alarm. |
| 12:37 |
mmorgan |
At least the sun was warm :) |
| 12:44 |
* kmlussier |
is glad she was working at NOBLE yesterday and not today. |
| 12:45 |
mmorgan |
Luckily it didn't last long. Not sure what the issue was, though. |
| 12:46 |
|
sarabee joined #evergreen |
| 13:23 |
kmlussier |
yboston: Where did we leave things off with an academic interest group meeting for this month? Was a date ever set? |
| 13:24 |
yboston |
no, I was not able to set a date for November |
| 13:24 |
yboston |
I need to send out an email to try to plan a December date |
| 13:24 |
yboston |
ASAP |
| 13:25 |
kmlussier |
yboston: OK, thanks. I couldn't remember where we had left it. |
| 13:27 |
|
rlefaive joined #evergreen |
| 13:30 |
krvmga |
yboston: i'm starting pilot projects with my academics on designing their own versions of the public catalog |
| 13:30 |
yboston |
krvmga: cool |
| 13:31 |
krvmga |
we (central site staff and the academics) met about this at the end of last month |
| 13:31 |
krvmga |
mass. college of liberal arts is going first |
| 13:31 |
krvmga |
probably to be followed immediately by mt. wachusett cc |
| 13:31 |
krvmga |
i'll have more details on monday, nov. 30 |
| 13:33 |
krvmga |
on another note: in my system, a title search for mickey & me does not return the same results as mickey and me unless i add an alternate title. is the system supposed to know "and" and "&" are the same word? or am i just doing something wrong? |
| 13:34 |
kmlussier |
I haven't checked, but it wouldn't think the system would know that. The only way I know that the system searches for word variations is through stemming. |
| 13:34 |
kmlussier |
/s/it wouldn't think/I wouldn't think |
| 13:34 |
* krvmga |
is still buzzing because he got to meet nichelle nicoles (uhura) over the weekend at a fan convention. |
| 13:34 |
krvmga |
nicoles -> nichols |
| 13:35 |
krvmga |
fumble fingers |
| 13:39 |
jeff |
this remains handy: \copy (SELECT ...) TO file.csv WITH CSV HEADER |
| 13:39 |
jeff |
(as a psql command for quickly outputting a query to a csv file) |
| 13:41 |
Dyrcona |
And you can do it on the client machine without the \, and you can replace the filename with stdout. ;) |
| 13:42 |
* jeff |
lods |
| 13:42 |
Dyrcona |
jeff++ |
| 13:42 |
* jeff |
nods |
| 13:42 |
Dyrcona |
I use it quite a bit, myself. |
| 13:43 |
jeff |
you can also \copy temp_staging FROM pstdin WITH CSV HEADER |
| 13:44 |
* csharp |
dives back into his "acq vandelay no longer creates copies" issue :-/ |
| 13:44 |
jeff |
which can be handy for something where you are using a psql variable like :somevar |
| 13:44 |
csharp |
I was hoping that upgrading the acq test server to 2.9.0 would Just Fix™ it |
| 13:45 |
jeff |
then you call psql -v somevar=3 -f script.sql dbname < $CSV_FILE |
| 13:46 |
csharp |
so hmm... what is supposed to happen if subfields are defined for a vendor/provider but not used in the file being uploaded? |
| 13:47 |
csharp |
$u barcode and $j call number are set up but they are not in the file being imported |
| 13:47 |
csharp |
"set up" = defined in Acquisitions -> Providers -> Holding Subfield |
| 13:51 |
kmlussier |
csharp: For barcode and call number, the system would automatically generate a call number and barcode. I think it happens at the time the real copies are created. |
| 13:52 |
kmlussier |
That could happen when the order is activated. Or, if the user selects the option to create copies at the time of upload, it would happen at that time. |
| 13:52 |
csharp |
kmlussier: do you happen to know offhand where the process that generates copies is? |
| 13:52 |
kmlussier |
csharp: No, sorry. |
| 13:52 |
csharp |
in this case, we are trying to generate copies as we upload the file |
| 13:53 |
csharp |
so that makes me wonder what happens if EG acq is expecting to get barcode and call number from the file and doesn't |
| 13:53 |
* csharp |
puts on hazmat suit to dive deep into the code |
| 13:53 |
kmlussier |
csharp: I just want to clarify something that can be confusing (apologies if you already know this). The problem you were working through last week is that acq wasn't creating acq copies. |
| 13:54 |
csharp |
yeah, this is the same issue |
| 13:54 |
kmlussier |
That happens even if you don't check off that option to create copies at the time of upload. |
| 13:54 |
csharp |
right - I've got that part |
| 13:54 |
kmlussier |
That option controls whether live copies are created in the catalog. |
| 13:54 |
csharp |
oh |
| 13:54 |
csharp |
that's right - well by "copies" I mean "lineitem details" |
| 13:55 |
kmlussier |
csharp: OK, in that case, I wouldn't check off that option, just to remove one other factor when troubleshooting the issue. |
| 13:55 |
csharp |
but asset.copy rows aren't getting created either |
| 13:55 |
kmlussier |
csharp: When you last left us, you had discovered that the subfield mapping for the provider wasn't correct, right? Are they mapped correctly now? |
| 13:56 |
kmlussier |
csharp: Sorry if I'm asking the obvious. It's habit. :) |
| 13:56 |
csharp |
yeah, turns out I was uploading them as the wrong OU |
| 13:56 |
csharp |
no problem |
| 13:56 |
csharp |
I'm still convinced that this is something front-end staff changed somewhere that broke this |
| 13:57 |
kmlussier |
csharp: Yeah, that's why I keep looking at the mapping of the subfields. It's something that can easily get changed, and I know sometimes people don't make the connection that the subfields need to be changed on both sides at the same time. |
| 13:57 |
csharp |
but I have to learn the process start to finish before I can know that for sure, which is why I... |
| 13:57 |
csharp |
@hate acq way more than before |
| 13:57 |
pinesol_green |
csharp: The operation succeeded. csharp hates acq way more than before. |
| 13:58 |
csharp |
well, they don't match in that barcode and call number are defined as holdings subfields but are not present in the uploaded file |
| 13:58 |
csharp |
but everything else lines up |
| 13:58 |
kmlussier |
csharp: I will confirm that mapping call number and barcode and then not including them in the upload shouldn't be a problem. I do it all the time in testing. |
| 13:58 |
csharp |
okay good |
| 13:59 |
csharp |
I *think* what I'm looking for is in the DB |
| 13:59 |
kmlussier |
csharp: They have values for quantity and owning library? |
| 13:59 |
csharp |
yes, they have that |
| 13:59 |
csharp |
962 $b WGRL-MR $c On Order $g dvd $p 34.99 $q 1 |
| 14:00 |
kmlussier |
Hmmm...I dunno. Another common problem is that the fund codes don't line up, but I don't think it would prevent the copy from generating. It just wouldn't have the fund code applied. |
| 14:00 |
csharp |
looks like fund code isn't being referenced here |
| 14:00 |
|
pgardella left #evergreen |
| 14:01 |
kmlussier |
csharp: I'm stumped. Sorry. |
| 14:01 |
csharp |
yep - that's where I'm spending a lot of my time lately |
| 14:02 |
csharp |
my coworkers love it! |
| 14:06 |
csharp |
huh acq.extract_provider_holding_data() returns no rows for one of the lineitems I just imported - maybe whatever is causing that not to work is the issue |
| 14:21 |
kmlussier |
csharp: I'm going to take back what I said earlier. I'm just retested, and I'm having trouble with the automatic barcode generation. I don't know if it's related to what's in the provider record or not. |
| 14:21 |
kmlussier |
I'm going to test a little further. |
| 14:21 |
kmlussier |
In my case, the acq.copies were generated, but I was getting a message saying that the barcode already exists. It was generating the same barcode for each lineitem. |
| 14:23 |
Dyrcona |
So, there isn't a good way to reprocess EDI messages, eh? |
| 14:23 |
Dyrcona |
IOW, it looks like it would be more hassle than it is worth. |
| 14:24 |
kmlussier |
@dunno |
| 14:24 |
pinesol_green |
kmlussier: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:25 |
Dyrcona |
But, to follow up on the conversation from hours ago, it does look like the problem with processing the invoic message was the space in the PO name. |
| 14:30 |
kmlussier |
csharp: After further testing, I can confirm that there is a problem with automatically generating barcodes if the provider record includes a subfield for barcodes but the incoming record doesn't include that subfield. |
| 14:31 |
csharp |
holy shiznit - I recreated the acq.extract_holding_attr_table function that was returning no rows with some RAISE NOTICE statements and after that it works |
| 14:31 |
csharp |
I have no idea why that would have work |
| 14:31 |
csharp |
ed |
| 14:31 |
csharp |
@eightball do we need to start reingesting acq functions now? |
| 14:31 |
pinesol_green |
csharp: Maybe... |
| 14:31 |
kmlussier |
csharp: Call numbers seem to generate fine in the same situation. Apparently, my comment above - "I do it all the time in testing" - was a big lie. |
| 14:31 |
csharp |
heh |
| 14:31 |
miker |
csharp: sounds like maybe you had an old version? |
| 14:32 |
csharp |
no idea |
| 14:32 |
miker |
did you edit the one actually in the db, or from master source? |
| 14:33 |
miker |
csharp: also, I think that's the closest I've ever seen you come to cursing ;) |
| 14:34 |
berick |
heh |
| 14:34 |
csharp |
oh, just in here. If this were a google hangout, y'all would've heard some creative profanity |
| 14:35 |
csharp |
https://www.youtube.com/watch?v=TwJheWwW7rw |
| 14:35 |
berick |
logging enabled: activate ned flanders mode. |
| 14:36 |
csharp |
holy shizdiddlyshiznit |
| 14:38 |
Dyrcona |
We've started saying Sean Feguson around the house. |
| 14:38 |
miker |
csharp++ |
| 14:38 |
csharp |
ha! it works now |
| 14:38 |
Dyrcona |
It comes from a story of an immigrant at Ellis Island, who asked for a good, American name from a worker. |
| 14:38 |
Dyrcona |
He was told "Rockefeller." |
| 14:39 |
Dyrcona |
He forgot the name by the time he got to the desk, and being a yiddish speaker, he "Schon fergressen" (I just forgot.) |
| 14:39 |
Dyrcona |
So, the guy at the desk wrote down Sean Ferguson. |
| 14:39 |
Dyrcona |
Oy! Who can't type this afternoon? |
| 14:40 |
csharp |
vimdiff between the old function and the new shows a difference here: '//*[@tag="' || tag || '" and position()=' || i || ']/*/@code|' vs '//*[@tag="' || tag || '"][position()=' || i || ']/*/@code|' |
| 14:40 |
csharp |
I bet that's it |
| 14:40 |
csharp |
that looks familiar |
| 14:41 |
csharp |
it's similar to the xpath issue gmcharlt jboyer-isl and I were looking at at the hackaway |
| 14:44 |
jeff |
"pull lists should be accurate at the time of their generation, but cannot be guaranteed after that" |
| 14:44 |
csharp |
jeff: but we've *always* printed our list at 9:00 to pull holds at 3:00! |
| 14:45 |
Dyrcona |
csharp jeff "Well, you're doing it wrong." ;) |
| 14:46 |
csharp |
an ILS I used at my previous library job "locked" the copies to the hold-pulling branch for 24 hours to avoid that problem |
| 14:47 |
csharp |
in fact, we had to change the status to missing for any copies we didn't find so they would move on to another library |
| 14:47 |
csharp |
otherwise they'd be there the next day |
| 14:47 |
Dyrcona |
csharp: That has a familiar ring to it. |
| 14:48 |
csharp |
starts with an H and rhymes with Verizon? |
| 14:48 |
Dyrcona |
I believe it does. |
| 14:50 |
jboyer-isl |
csharp: I'm guessing that function has "table" in the name? Last I knew we left that issue at "tell the vendor to stop that until tuits present themselves for a proper fix" |
| 14:50 |
kmlussier |
Mobile pull list. Once the web client is available, they can bring the pull list with them on the tablet. Have an option available to capture it as soon as you pull it off the shelf to verify that it is still available. |
| 14:50 |
jboyer-isl |
Or is this another, similar looking issue? |
| 14:50 |
csharp |
jboyer-isl: it's not the same issue, but it uses similar xpath to grab its values |
| 14:51 |
csharp |
it does have "table" in the name, yes |
| 14:52 |
csharp |
wait - that was it |
| 14:52 |
csharp |
our attempt to change that function at the hackaway is what broke copy creation! |
| 14:52 |
csharp |
heh |
| 14:52 |
csharp |
@blame me |
| 14:52 |
pinesol_green |
csharp: Your failure is now complete, csharp. |
| 14:53 |
* jboyer-isl |
looks up at the sky, whistles. |
| 14:53 |
csharp |
haha |
| 14:53 |
jboyer-isl |
It occurs to me that we verified that change didn't correct the problem, but perhaps we didn't verify that it didn't break anything that worked before. |
| 14:53 |
Dyrcona |
gmcharlt: I belated added something to the roadmap for 2.10. I didn't think it was worthy at first, but changed my mind. |
| 14:54 |
csharp |
@blame [someone] for [quote random] |
| 14:54 |
pinesol_green |
csharp: miker stole bshum's tux doll! for Quote #9: "<sylvar> Late-night boredom. Some folks write a replacement Minix kernel, some people set fire to stuff." (added by gmcharlt at 08:32 AM, May 17, 2011) |
| 14:54 |
gmcharlt |
Dyrcona: thanks! |
| 14:54 |
Dyrcona |
MVLC in general doesn't have anything at this time. |
| 14:54 |
csharp |
sylvar++ # always makes me laugh |
| 14:55 |
* Dyrcona |
knows sylvar from way back...conferences for that other ILS. |
| 15:01 |
kmlussier |
The roadmap is looking fairly featureful. Nice! |
| 15:08 |
kmlussier |
bug 1481441 seems to mirror another bug that had a lot of discussion from mmorgan, phasefx and me. But I can't track it down to verify if it really is a duplicate or not. |
| 15:08 |
pinesol_green |
Launchpad bug 1481441 in Evergreen "action.hold_request_permit_test fail_parts can be confusing to end users" [Undecided,New] https://launchpad.net/bugs/1481441 |
| 15:25 |
mmorgan |
kmlussier has an impressive memory! lp 1319980 ? |
| 15:25 |
pinesol_green |
Launchpad bug 1319980 in Evergreen "misleading hold placement failure message" [Undecided,New] https://launchpad.net/bugs/1319980 |
| 15:26 |
kmlussier |
mmorgan: That's the one! Looks like most of the discussion happened in IRC, not on the bug. |
| 15:28 |
mmorgan |
Yeah, it actually started out as an Equinox support ticket |
| 15:29 |
dbwells |
csharp: Just read the backlog including the conclusion to your recent acq saga. Classic. :) Definitely been there once or twice. |
| 15:31 |
* dbwells |
feels better after thinking somehow, someway, he's the one who broke it |
| 15:39 |
csharp |
dbwells: I knew it was either something I did and didn't remember or something an end user did and wasn't saying ;-) |
| 15:41 |
phasefx |
out of sight, out of mind. QA tests have been failing for a while. Suspect it's the environment and not EG code. Need to resubscribe pinesol to the RSS feed |
| 15:43 |
kmlussier |
yikes |
| 16:14 |
berick |
dbwells: i'm done w/ bug 1468422 for now. i left the authproxy for you if you want it. |
| 16:14 |
pinesol_green |
Launchpad bug 1468422 in Evergreen "Improve Password Management and Authentication" [Undecided,New] https://launchpad.net/bugs/1468422 |
| 16:15 |
berick |
should be a simple change, but I like the idea of someone else using the code. |
| 16:16 |
berick |
to gauge its murkiness ratio |
| 16:20 |
dbwells |
berick: Thanks. You're right, it should be very simple (and remove some of the ugliness from AuthProxy to boot). I appreciate your efforts to handle the hard bits, and I'll definitely make it a priority. |
| 16:20 |
berick |
dbwells++ |
| 16:38 |
mmorgan |
Lovely moonrise tonight! Though I hate that it happens at 4:30 :-( |
| 17:06 |
phasefx |
a lot better this time: http://testing.evergreen-ils.org/~live/ |
| 17:10 |
|
mmorgan left #evergreen |
| 17:11 |
kmlussier |
phasefx++ |
| 17:42 |
Bmagic |
anyone played with running more than one instance of Evergreen on the same postgres cluster? divided by database and dbuser? |
| 17:43 |
kmlussier |
Nope |
| 17:43 |
* kmlussier |
wraps up work for the week. |
| 17:44 |
Bmagic |
kmlussier: have a good thank goodnessgiving |
| 17:44 |
kmlussier |
Have a nice Thanksgiving to those who celebrate it and a nice week to everyone else! |
| 17:44 |
kmlussier |
Bmagic: Thanks! :) |
| 17:51 |
miker |
Bmagic: yes, and it works fine. drawback is that you can't tune pg per evergreen instanve |
| 17:59 |
Bmagic |
miker: ty |
| 18:05 |
|
jlitrell joined #evergreen |
| 18:13 |
rangi |
oh, I should post this here too |
| 18:13 |
rangi |
http://search.cpan.org/~srdjan/WebService-ILS-0.01/ |
| 18:14 |
rangi |
we are doing some work with a bunch of the different econtent vendors for koha, but trying to cpan all the common bits so useful for other projects like evergreen too |
| 20:19 |
|
hopkinsju joined #evergreen |
| 20:20 |
|
Bmagic joined #evergreen |
