| 01:12 |
|
mnsri joined #evergreen |
| 02:42 |
|
shresh joined #evergreen |
| 03:33 |
|
RBecker joined #evergreen |
| 06:01 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:01 |
|
artunit_ joined #evergreen |
| 07:03 |
|
Callender joined #evergreen |
| 08:00 |
|
eeevil joined #evergreen |
| 11:31 |
pinesol_green |
Launchpad bug 1379824 in Evergreen "Make PermaCrud.js disconnect() actually disconnect" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1379824 |
| 11:33 |
yboston |
dbwells: nice! |
| 11:34 |
bshum |
Calling 0894 |
| 11:37 |
yboston |
dbwells: is there anything I can help with? do you need me to test the commit and sign it off? |
| 11:38 |
pinesol_green |
[evergreen|Chris Sharp] LP#1374551: Create index on money.billing.voider to speed user merge. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44bca3b> |
| 11:38 |
pinesol_green |
[evergreen|Ben Shum] LP#1374551: Stamping upgrade script for new index on money.billing.voider - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=896dea5> |
| 11:38 |
dbwells |
yboston: testing and signoffs are always appreciated! |
| 11:50 |
bshum |
Hmm, California. |
| 11:55 |
|
ldwhalen joined #evergreen |
| 12:02 |
|
nhilton joined #evergreen |
| 13:35 |
bshum |
bmills: I just pushed the selfcheck timeout fix to the repos. Hopefully you can make use of that fix sometime. :) |
| 13:37 |
bmills |
bshum: thanks! |
| 13:38 |
bmills |
bshum++ |
| 13:39 |
bshum |
mmorgan++ # thanks for testing! |
| 13:39 |
bshum |
jboyer-isl++ # think check on the JavaScript. |
| 13:53 |
|
RBecker joined #evergreen |
| 14:07 |
mmorgan |
bshum++ # thanks for fixing :) |
| 14:09 |
|
RBecker joined #evergreen |
| 17:22 |
Bmagic |
bmills: I'm not going to be much help as our system is not currently using authority. I hope there is someone here with more expierence with the DB authority.normalize_heading. You could bring it to the email list and get more response. |
| 17:23 |
bmills |
Bmagic: thanks! |
| 17:42 |
|
bmills1 joined #evergreen |
| 17:43 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:44 |
|
nhilton_ joined #evergreen |
| 17:54 |
bbqben |
jihpringle: bring leftovers to the office next week? |
| 17:55 |
jihpringle |
bbqben: I wish, I'm going to family friends for dinner so I won't have leftovers :( |
| 20:07 |
bshum |
My experience thus far is primarily Debian/Ubuntu. |
| 20:08 |
atlas__ |
I figured I should have started with one of those since they are listed first in the instruction order |
| 20:08 |
atlas__ |
so when I try to start all the opensrf services I just get 'authentication failed' and its because ejabberd seems to be borked |
| 20:09 |
bshum |
atlas__: Fedora is one of the targets, but nobody actively uses Fedora in production for Evergreen (as far as I know) |
| 20:10 |
bshum |
I think it's mainly there cause there's a few Fedora enthusiasts among the developers :) |
| 20:10 |
bshum |
It's entirely possible that something needs more love with Fedora 20. Just a quick glance at the instructions for OpenSRF seem to me that they were written with Fedora 17+ in mind (which might also mean that they haven't been fully tested yet with 20) |
| 20:10 |
atlas__ |
what do people run in production |
| 20:11 |
bshum |
Yeah, the Fedora build slave at testing.evergreen-ils.org is only Fedora 18. |
| 20:11 |
bshum |
atlas__: Go for Debian or Ubuntu. |
| 20:11 |
bshum |
Presently, Debian Wheezy (7.0) or Ubuntu 12.04 server would be my best recommendations. |
| 20:12 |
bshum |
Ubuntu 14.04 support is still... being worked out. |
| 20:12 |
atlas__ |
any reason to do one over the other? i've got more experience with ubuntu, but yeah 14.04 would be a lot better |
| 20:13 |
atlas__ |
I'd rather Fedora (clearly!). But if Debian is what most use in production I could probably figure it out. |
| 20:13 |
bshum |
atlas__: I consider it to be a personal preference. I use Ubuntu 12.04 for our systems. |
| 22:31 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/714694 like dollar signs, etc. |
| 22:31 |
pinesol_green |
Launchpad bug 714694 in OpenSRF "Passwords cannot contain certain special characters" (affected: 1, heat: 6) [Medium,Won't fix] |
| 22:31 |
atlas__ |
ba dum tish |
| 22:31 |
bshum |
You'll want to try something a little simpler for testing :) |
| 22:32 |
atlas__ |
can I just re-run these register commands to get new ejabbderctl passwords |
| 22:33 |
bshum |
I was just looking up how to change the passwords |
| 22:33 |
atlas__ |
thank you thank you |
| 22:33 |
bshum |
ejabberdctl man page, whee |
| 22:34 |
bshum |
So maybe something like |
| 22:34 |
bshum |
sudo ejabberdctl change-password opensrf private.localhost password |
| 22:34 |
bshum |
Repeat for all four users |
| 22:34 |
bshum |
But basically "ejabberdctl change-password <user> <hostname> <password>" |
| 22:35 |
bshum |
And then make sure you change up your opensrf_core.xml passwords to match it |
| 22:35 |
bshum |
And .srfsh.xml too |
| 22:35 |
bshum |
For purposes of getting going, I'd do something alphanumeric. |
| 22:35 |
bshum |
Or if it's purely a test system... *cough, cough* "password" is probably fine :) |
| 22:37 |
bshum |
Maybe we ought to consider putting a note on that in the OpenSRF README on how people should avoid certain special characters that are known to break things. |
| 22:37 |
* bshum |
adds reminder for his future self. |
| 22:40 |
|
atlas__ joined #evergreen |
| 22:43 |
|
buzzy joined #evergreen |
| 03:11 |
|
jventuro joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:41 |
|
sseng_ joined #evergreen |
| 07:06 |
|
Sato joined #evergreen |
| 07:32 |
|
rjackson-isl joined #evergreen |
| 09:48 |
|
sarabee joined #evergreen |
| 09:48 |
dbs |
Oh, I know Sid. |
| 09:49 |
dbs |
I'm still decrementing ubuntu because this problem has existed for a couple of years. |
| 09:51 |
csharp |
well, to be pedantic, the LTS releases sync with debian testing, so this is likely a problem that would exist in jessie too |
| 09:52 |
csharp |
unless it doesn't pass muster with Debian testers, that is |
| 10:01 |
|
RoganH joined #evergreen |
| 10:15 |
kmlussier |
Web client testing is also a good way to remember old bugs that I forgot to file in LP. |
| 10:42 |
|
ningalls joined #evergreen |
| 10:48 |
kmlussier |
I'm looking at the self-check docs at http://docs.evergreen-ils.org/2.7/_self_checkout.html#_configuring_self_check_behavior. For "Patron Login Timeout," it says not currently supported. Is that still true? |
| 10:48 |
bshum |
kmlussier: Right |
| 10:49 |
kmlussier |
Oh, wait. I see the bug report. |
| 10:49 |
bshum |
kmlussier: So there's a bug ticket for that and I wrote new code during the hackaway |
| 10:51 |
bshum |
I haven't decided if it's a "new feature" or a "bug fix" though. |
| 10:53 |
kmlussier |
I would think bug fix since there is an existing setting that doesn't work. |
| 10:53 |
* mmorgan |
agrees that it's a bug fix |
| 10:53 |
bshum |
Oh fun then. |
| 10:54 |
bshum |
Well if anyone feels brave to try :) |
| 10:54 |
bshum |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1306814-selfcheck-timeout |
| 10:54 |
bshum |
That's where I put the initial code I was poking at |
| 10:54 |
bshum |
I have to test it with an actual library setting configured. |
| 10:57 |
bshum |
I updated the bug report with a link to the code |
| 10:57 |
bshum |
And assigned targets as a bug fix. |
| 10:57 |
csharp |
heh - so it multiplies the patron timeout value by 1000? |
| 10:57 |
bshum |
Right, cause I think the setting is assigned as seconds |
| 10:57 |
bshum |
But the value is like milliseconds |
| 11:01 |
kmlussier |
bshum: But some of that was based on your custom 001 record attribute, right? |
| 11:01 |
bshum |
kmlussier: Correct, for us, abnormally large entries in our uncontrolled values table was causing slowdown, among other things. |
| 11:01 |
* kmlussier |
is looking at search performance on a system that doesn't have custom record attributes. |
| 11:01 |
bshum |
I'm finishing testing eeevil's fixes for that. |
| 11:02 |
bshum |
Define "slow" |
| 11:02 |
bshum |
Like have you guys turned on the debug timing and grabbed numbers on how things are? |
| 11:03 |
kmlussier |
This is a system where they timed searches on 2.5 and then timed then again after uprading the same system to 2.6. We're seeing numbers where the search took 3 seconds on 2.5 and is now taking 12-14 seconds. A big difference. |
| 11:03 |
kmlussier |
bshum: No, we haven't. |
| 11:04 |
|
DPearl joined #evergreen |
| 11:38 |
dbwells |
kmlussier: We didn't experience anything like the slowdowns shown in your chart. (great chart btw!) We also have a "normal" uncontrolled_record_attr_value table size (2551 rows). |
| 11:39 |
kmlussier |
dbwells: The credit for the great chart goes to tspindler. :) |
| 11:47 |
bshum |
csharp: Vacuuming the table didn't do anything for us, the new code helped :) |
| 11:50 |
Bmagic |
Im testing 2.7, right off the bat I don't see the secondary permission group UI in the staff client. Was there something I forgot to setup? |
| 11:51 |
kmlussier |
Bmagic: It should just display in the patron editor. And you need permission to see it. |
| 11:52 |
Bmagic |
kmlussier: huh, no magic trick? I am using an account with global everything |
| 11:54 |
bshum |
Hmm, it's working for me |
| 11:55 |
|
bkuhn joined #evergreen |
| 11:55 |
Bmagic |
I preformed an upgrade on an existing directory full of 2.6.1 code |
| 11:56 |
Bmagic |
aka /openils |
| 11:56 |
bshum |
Bmagic: That I don't know, all I know is that a clean install test server I was looking at seems fine. |
| 11:59 |
|
nhilton joined #evergreen |
| 11:59 |
|
ningalls joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:09 |
berick |
gmcharlt: were you able to make any headway w/ your nginx for websockets test? |
| 12:10 |
berick |
one of the OPW candidates cannot access webby... wondering if it's a port issue |
| 12:10 |
Bmagic |
bshum: I got it figured out, yay! |
| 12:10 |
gmcharlt |
berick: wouldn't surprise if it were; I expect to have tuits for that tomorrow |
| 12:10 |
kmlussier |
berick: We had a similar issue with another OPW candidate. We narrowed it down to the ports issue. |
| 16:11 |
bshum |
See, this bug.... |
| 16:11 |
bshum |
https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 16:11 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Undecided,New] |
| 16:11 |
berick |
Bmagic: node, bower, etc. are only used for dependency retrieval and unit tests. it's not needed for running the browser client. |
| 16:12 |
bshum |
Bmagic: http://evergreen-ils.org/~bshum/OpenSRF-README.html#_optional_websockets_installation_instructions |
| 16:12 |
bshum |
That's a generated copy of the integrated steps |
| 16:12 |
Bmagic |
!! |
| 16:38 |
|
buzzy joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 17:24 |
|
buzzy joined #evergreen |
| 17:49 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
bshum |
But gmcharlt, the quest_for_knowledge is over! |
| 17:51 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605ececad7850f2a7276b64a697b6b5c9ae31 |
| 17:51 |
pinesol_green |
[evergreen|Dan Wells] LP#1290496: The quest for knowledge is over - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=988605e> |
| 03:09 |
|
vanya joined #evergreen |
| 03:40 |
|
vanya joined #evergreen |
| 03:42 |
vanya |
I made some changes in the code while fixing a bug. Then I ran make and make install again to see if the modified code works. However, my apache crashed due to that. Can anyone tell me where I'm going wrong? |
| 05:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:32 |
|
kedmundson joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 07:52 |
|
reach joined #evergreen |
| 09:47 |
|
kmlussier joined #evergreen |
| 10:11 |
|
yboston joined #evergreen |
| 10:28 |
|
Dyrcona joined #evergreen |
| 10:34 |
vanya |
Hello everyone. After I make changes in the code, I wanted to test it out. |
| 10:35 |
vanya |
I had downloaded the staff client and the server from the link given. |
| 10:37 |
vanya |
When I make the server again , the changes are not reflected on the client. I was wondering if someone could tell me how to build the client according to my changes. |
| 10:39 |
tsbere |
vanya: You may need to re-install the client if you aren't using automatic updates |
| 10:39 |
tsbere |
(especially if it is client-side code you are changing) |
| 10:42 |
|
mdriscoll1 joined #evergreen |
| 10:59 |
tsbere |
kmlussier: Heh, I was looking for that, then got distracted |
| 11:18 |
mmorgan |
Can someone confirm that the CIRC_OVERRIDE_DUE_DATE permission CANNOT be configured to prevent editing due dates on items owned by other org units? |
| 11:27 |
tsbere |
mmorgan: As I believe it is based on the library the circ is happening at, and not the item in any way, shape, or form, I think I can confirm that. |
| 11:30 |
mmorgan |
that's what my testing has shown. I was hoping that the depth of the permission might pertain to ownership, but that does not appear to be the case. |
| 11:32 |
tsbere |
mmorgan: Note that preventing the due date from being overridden would help with "you can't make it due later" but who is going to complain about someone trying to get an item to come back *sooner*? :P |
| 11:33 |
tsbere |
(outside of the person checking the item out, anyway) |
| 12:02 |
|
akilsdonk_ joined #evergreen |
| 15:02 |
kmlussier |
And welcome! |
| 15:03 |
jeff |
Yes, welcome! |
| 15:03 |
Dyrcona |
#info Jason Stephenson, MVLC |
| 15:03 |
jeff |
#topic Action items from last meeting |
| 15:03 |
jeff |
#info kmlussier and others to make time to test the latest branch (negative balances). |
| 15:03 |
jeff |
kmlussier: anything to report? |
| 15:04 |
|
mrpeters joined #evergreen |
| 15:04 |
kmlussier |
Yes, I've done more testing and reported my most recent feedback to the bug. |
| 15:04 |
kmlussier |
I thought I saw a new branch floating around during the hack-a-way. Is that something that's ready for testing? |
| 15:04 |
jeff |
excellent. related: |
| 15:04 |
jeff |
#info dbwells to work on display ideas for negative balance branch |
| 15:05 |
|
mnsri joined #evergreen |
| 15:05 |
dbwells |
It's blossomed into a few different branches. |
| 15:05 |
jeff |
(this may answer kmlussier's question, if not -- feel free to chime in regardless of the current bullet item) |
| 15:06 |
jeff |
dbwells: testing and eyeballs being needed, as always? |
| 15:06 |
dbwells |
The extra fine bug was actually related to a separate code branch for "new overdues for returned lost" stuff |
| 15:06 |
DPearl |
#info DPearl = Dan Pearl, C/W MARS |
| 15:06 |
dbwells |
That is it's own branch, courtesy of berick and eeevil |
| 15:08 |
dbwells |
Put me down as an action item to do just that. |
| 15:08 |
jeff |
dbwells++ thanks |
| 15:08 |
berick |
dbwells++ |
| 15:08 |
kmlussier |
I'll test anything dbwells puts out there. :) |
| 15:08 |
bshum |
dbwells++ |
| 15:08 |
kmlussier |
dbwells++ |
| 15:08 |
bshum |
kmlussier++ # testing too :) |
| 15:08 |
jeff |
#action dbwells to update Conditional Negative Balances bug 1198465 with links to new branches, etc. |
| 15:08 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 62) [Wishlist,Confirmed] https://launchpad.net/bugs/1198465 |
| 15:09 |
jeff |
kmlussier++ dbwells++ berick++ Dyrcona++ and probably more :-) |
| 15:09 |
jeff |
#info jeff and csharp to test websockets work by the end of this week. |
| 15:09 |
jeff |
That happened and/or didn't happen, but what did happen was (iirc): |
| 15:09 |
jeff |
#info gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th) |
| 15:10 |
bshum |
That did occur I think |
| 15:10 |
bshum |
Or at least, there's an OpenSRF 2.4 alpha around :) |
| 15:10 |
* jeff |
nods |
| 15:15 |
bshum |
There's a few things we have to put in there I think |
| 15:15 |
bshum |
And I need to revisit the updates I made to the main README for websocket steps. |
| 15:15 |
jeff |
bshum: currently, due to websockets and other things, Evergreen 2.7 does require OpenSRF 2.4 alpha, correct? Downloads page seems to confirm... |
| 15:15 |
bshum |
Generally speaking, yes. |
| 15:15 |
bshum |
I never tested it with anything less. |
| 15:15 |
bshum |
I think that's correct though. |
| 15:16 |
bshum |
It doesn't require websockets |
| 15:16 |
jeff |
bshum: anything specific that you/gmcharlt could use help/signoff with toward the goal of OpenSRF 2.4 making it to release? |
| 15:16 |
bshum |
But I think there were other changes. |
| 15:16 |
bshum |
Bug with branch is https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 15:18 |
bshum |
Now that Dyrcona mentions it, the only reason to use OpenSRF 2.4 with Evergreen 2.7 is if you wanted websockets to play with the web based staff client. I think. |
| 15:18 |
ldw |
#info ldw is Liam Whalen Sitka |
| 15:18 |
jeff |
#topic Release info - Evergreen |
| 15:18 |
bshum |
I didn't personally test OpenSRF 2.3 stable with Evergreen 2.7 though to make sure that XUL stuff and catalog is still happy. |
| 15:18 |
jeff |
Evergreen 2.7 is released! Everyone's upgraded by now, right? |
| 15:18 |
* jeff |
ducks |
| 15:18 |
bshum |
If anyone wants to volunteer to try that, maybe that's worth it. |
| 15:18 |
bshum |
But really, getting 2.4 out the door is better anyways :D |
| 15:19 |
bshum |
jeff: Actually......! |
| 15:19 |
jeff |
#info Testing of Evergreen 2.7 with OpenSRF 2.3 would be appreciated -- pass feedback to bshum |
| 15:19 |
Dyrcona |
jeff: We're on 2.7alpha give or take a few later fixes. |
| 15:19 |
bshum |
We were going to upgrade to 2.7 a few days after I cut 2.7.0, but we were delayed a bit. We plan our upgrade to 2.7 this upcoming Saturday. |
| 15:19 |
jeff |
excellent. |
| 15:21 |
jeff |
#info bshum to push things to rel_2_7 in preparation for scheduled 2.7.1 maintenance release |
| 15:21 |
bshum |
If anyone else has any bug fixes with code that they want to see in 2.7.1, please feel free to target or put a pullrequest up. |
| 15:21 |
jeff |
#info bshum pulling updated translations for tpac (and other areas) into 2.7.1 |
| 15:22 |
bshum |
And if anyone has time to test and sign-off on them, that'd be great too :) |
| 15:22 |
jeff |
bshum: anything else for Evergreen release info/updates? |
| 15:22 |
bshum |
Nothing for me. I hope to keep 2.7 series happy and stable. |
| 15:22 |
jeff |
#info targeting, testing/signoff of bugs against 2.7.1 appreciated as always |
| 15:22 |
jeff |
bshum++ |
| 15:23 |
kmlussier |
bshum++ |
| 15:23 |
Dyrcona |
bshum++ |
| 15:23 |
jeff |
#topic New Business |
| 17:13 |
|
mdriscoll1 left #evergreen |
| 17:21 |
|
nhilton_ joined #evergreen |
| 17:23 |
|
StephenGWills left #evergreen |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:41 |
|
dreuther_ joined #evergreen |
| 17:47 |
|
dreuther joined #evergreen |
| 17:49 |
|
nhilton joined #evergreen |
| 05:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:55 |
|
eeevil joined #evergreen |
| 07:56 |
|
Callender joined #evergreen |
| 07:56 |
|
phasefx joined #evergreen |
| 15:16 |
csharp |
okay, as the postgres user, do 'psql evergreen' and do 'select * from actor.org_unit;' |
| 15:16 |
csharp |
if you see data there, you created the database correctly |
| 15:19 |
csharp |
vanya: restarting the client after running autogen is a good plan |
| 15:19 |
vanya |
I don't see any specific data- as in- there are entries like "example branch 1" etc. |
| 15:26 |
vanya |
I tried creating the database again, it told me it was being used by 6 other sessions- evergreen, pearllu, tablefunc, xml2, hstore and intarray |
| 15:27 |
vanya |
Is there any particular command I can give to update database? |
| 15:28 |
vanya |
Also, I was wondering if you could tell me what all I need to restart if I make some changes in the code and want to test them? |
| 15:36 |
|
vrani_ joined #evergreen |
| 15:38 |
|
vrani joined #evergreen |
| 15:38 |
csharp |
vanya: seeing the example branches means you did that right - no need to recreate |
| 15:52 |
vanya |
"Successfully updated the organization proximity" |
| 16:06 |
Shilpa_ |
One quick question: I noticed that all the installaztion instructions are for Linux, is it possible to run Evergreen on a mac? |
| 16:08 |
Shilpa_ |
Or can you compile it from source on a mac? |
| 17:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 19:54 |
vanya |
Hello, I'm working on the file menu.js |
| 19:54 |
vanya |
Could anyone tell me what the variables usr_id, opac and bib_id represent? |
| 20:01 |
vanya |
Also, |
| 04:33 |
pinesol_green |
Launchpad bug 978040 in Evergreen "No result found search for patron by database id results in return to wrong interface" (affected: 1, heat: 6) [Low,Confirmed] https://launchpad.net/bugs/978040 |
| 04:40 |
vanya |
I have been trying to run the evergreen client, but when I enter hostname as "localhost", it gives me the status "500: Internal server error", and there is a warning that says "Workstation not yet configured for the specified server" |
| 04:40 |
vanya |
Can someone tell me what I'm doing wrong? |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:49 |
csharp |
vanya: you should be able to see more details about the error in /openils/var/log/osrfsys.log (assuming you haven't changed anything about OpenSRF logging) |
| 07:58 |
|
eeevil joined #evergreen |
| 07:58 |
|
mtate joined #evergreen |
| 14:43 |
kmlussier |
phasefx: Thanks! |
| 14:44 |
phasefx |
you're welcome :) |
| 14:46 |
|
vlewis joined #evergreen |
| 14:55 |
kmlussier |
Something to ponder before I go back to web client testing. This record - https://bark.cwmars.org/eg/opac/record/948727 - is not retrieved in any keyword searches, either in the public catalog or staff client. |
| 14:56 |
kmlussier |
If it were just the public catalog, I would think it was a problem with subfield 9 or OPAC visibility. |
| 14:56 |
kmlussier |
We forced a reingest on the record, and it does have an entry in the metabib keyword table. |
| 14:56 |
kmlussier |
Is there anything else we should be looking at? |
| 14:57 |
|
jboyer-laptaupe joined #evergreen |
| 15:03 |
ldw |
kmlussier: It is not something I am working on currently. Please set it back to unassigned. It is still in my mind though, so I will get back to it. I will reassign myself when I am back on that job. |
| 15:03 |
kmlussier |
ldw: Thanks! |
| 15:52 |
jeff |
hey, that came up in private conversation the other day. |
| 15:52 |
* kmlussier |
googles recursive cte. :) |
| 15:52 |
jeff |
kmlussier++ for saving me from digging up the irc log for that time |
| 15:52 |
kmlussier |
Well, I just did some timed tests. |
| 15:53 |
kmlussier |
I used a 2.7 client on webby and then tried it in a browser. |
| 15:53 |
kmlussier |
The first load is very slow, in both, but it's a bit better in a web browser. |
| 15:53 |
kmlussier |
Then, in both environments, the load time improves. But I consistently found it took 4 seconds to load a patron in the editor in the xul client. It took 6 seconds in the browser. |
| 15:54 |
* kmlussier |
used an actual timer this time, not counting on her fingers. :) |
| 16:03 |
|
Canepa joined #evergreen |
| 16:04 |
kmlussier |
Anywho, I'll just re-state the concern I has back then about moving our libraries to something that is still loading slowly or, in this case, is loading a little more slowly. |
| 16:09 |
|
artunit joined #evergreen |
| 16:10 |
kmlussier |
Since it's Friday, I'll move on to happier performance-related topics. I'm guessing we no longer need the cap for patron search results because a) the user has the ability to select the option of up to 100 results b) we have paging and c) we won't kill the server by retrieving the 100 results that can be displayed on one screen? |
| 16:15 |
|
Canepa joined #evergreen |
| 16:15 |
dbs |
6 seconds? Good lord. |
| 16:16 |
* dbs |
doesn't have much more to contribute right now :( |
| 17:18 |
kmlussier |
Webby must have been updated while it was kicked. Awesome! I'm seeing a lot of fixes. :) |
| 17:20 |
jeff |
heh |
| 17:25 |
|
mmorgan left #evergreen |
| 17:42 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:51 |
tsbere |
jeff: On action.circulation, that can be much *less* useful when you are aging circs.....and as far as I know, "circulated an item" doesn't really show up anywhere else. For good reasons. |
| 18:09 |
|
Canepa joined #evergreen |
| 18:15 |
|
Canepa_ joined #evergreen |
| 04:50 |
|
geoffsams joined #evergreen |
| 05:33 |
|
vanya joined #evergreen |
| 05:46 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:10 |
|
eeevil joined #evergreen |
| 08:10 |
|
mtate joined #evergreen |
| 08:11 |
|
phasefx joined #evergreen |
| 11:04 |
berick |
kmlussier: too many ain't's and ya'll's, I assume ;) |
| 11:05 |
kmlussier |
berick: Ha! Given where I'm from, it's more likely that I wasn't using my r's. |
| 11:07 |
berick |
donde esta el coche? WHERE'S THE CAAAHHH |
| 11:07 |
* kmlussier |
chuckles |
| 11:07 |
kmlussier |
It's funny how much you learn about the existing client when testing the new client. I keep finding things that are missing, just to discover they never existed. |
| 11:08 |
* kmlussier |
should submit those reports anyway just to drive graced crazy. |
| 11:08 |
berick |
heh |
| 11:09 |
|
snigdha26 joined #evergreen |
| 11:34 |
* jeff |
grins |
| 14:18 |
yboston |
the date is fine for now |
| 14:18 |
remingtron |
#link http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28a5085fd645c9470b852c9700661dbe4cbddf18 |
| 14:18 |
pinesol_green |
[evergreen|Remington Steed] Documentation: Upgrade instructions examples - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=28a5085> |
| 14:19 |
yboston |
I have never done an upgrade so I have not been able to help with testing those instructions so far. thanks rsoulliere and remingtron for working on this |
| 14:19 |
rsoulliere |
And here it is in the docs: http://docs.evergreen-ils.org/2.6/_upgrade_the_evergreen_database_schema.html |
| 14:19 |
yboston |
anything else to add or any questions from others? |
| 14:21 |
yboston |
OK, I will move on |
| 14:28 |
yboston |
kmlussier: very true |
| 14:28 |
remingtron |
oooooo, good point |
| 14:28 |
remingtron |
well, let's discuss that on the list |
| 14:29 |
kmlussier |
I know I'll be doing some documentation while testing, but I don't know how far I'll get. |
| 14:29 |
remingtron |
jihpringle volunteered to help with preview web client docs |
| 14:29 |
yboston |
who would like to follow up on the list to get ideas for how to tackle web client docs |
| 14:29 |
yboston |
? |
| 14:43 |
remingtron |
kmlussier: +1 to that! |
| 14:43 |
|
vrani_ joined #evergreen |
| 14:43 |
kmlussier |
stompro: One thing I was thinking is we could maybe tie it closely together with the Evergreen site. I think there is a FAQ plug-in for WordPress (can't recall if we're using it). |
| 14:43 |
yboston |
I agree with kbutler , we might want to rethink the overall organization, but it might require having another docs server set up to test out new re-orgs of the content for us to see, wihtout impacting the main docs server |
| 14:43 |
stompro |
kbutler, I've wondered why there are 3 sections on tpac and several sections on Acquisitions. A reorg would be good. |
| 14:44 |
jihpringle |
+1 to a reorg |
| 14:44 |
kmlussier |
stompro: That's partially due to the Evergreen in Action docs being added without replacing the existing docs. I think if those were more explicitly called out as being "Evergreen in Action" docs, it would make more sense to the user. |
| 14:52 |
remingtron |
yboston: yes |
| 14:52 |
yboston |
#action remingtron will create a wiki page to collect ideas for a docs re-org |
| 14:52 |
remingtron |
I think we should keep discussing snigdha26's ideas on that email thread |
| 14:53 |
yboston |
we talked about setting up a test server to be used for OPW purposes, and a few other experiments |
| 14:53 |
kmlussier |
snigdha26++ Thanks for the ideas! |
| 14:53 |
yboston |
I can assign that task to me and kmlussier ? is that OK? |
| 14:54 |
kmlussier |
Does it need to be assigned? snigdha26 already started the thread. People should feel free to continue offering feedback and ideas, I think. |
| 14:54 |
|
kakes_ joined #evergreen |
| 14:54 |
yboston |
did we want to focus on a couple of the ideas first liek the search changes or testing the addition of a (collapsible) TOC tot he pages? |
| 14:54 |
yboston |
kmlussier: I meant about following up with a docs test server |
| 14:55 |
kmlussier |
Oh, sorry. |
| 14:55 |
* kmlussier |
was confused. |
| 14:55 |
yboston |
BTW, the next meeting, Academics for Evergeen, will start in 5 minutes |
| 15:52 |
kmlussier |
I took yboston off that one since he volunteered for call number sorting |
| 15:52 |
kmlussier |
#action yboston to lead Call Number Sorting group |
| 15:52 |
kmlussier |
yboston: I think the group leaders should create their own wiki pages. |
| 15:52 |
Christineb |
I am available to test, etc... I cannot do code |
| 15:53 |
kmlussier |
Christineb: We're starting with building of specs, so that might be something to help with too. |
| 15:53 |
kakes_ |
lots of the survey respondents indicated they would help with specing and testing |
| 15:53 |
kmlussier |
Did I miss anything? |
| 15:53 |
Christineb |
kmlussier: ok I would like to help where I can |
| 15:54 |
kmlussier |
So the group leaders will be responsible for soliciting volunteers and starting to pull together needs/specs? Does that sound right? |
| 16:01 |
kmlussier |
yboston: Yes. |
| 16:02 |
eeevil |
kmlussier: it certainly could. it would make config simpler, certainly. no template full of xpath, etc |
| 16:02 |
eeevil |
just "here's your fields, put them where you like" |
| 16:02 |
kmlussier |
eeevil: And you have a new branch available for testing, right? |
| 16:03 |
eeevil |
I do. I confirmed that it rebases to master cleanly (as of the hackaway) |
| 16:03 |
eeevil |
sec... |
| 16:03 |
kmlussier |
eeevil: But it sounds like it still needs work? |
| 16:03 |
eeevil |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1251394-metabib-display-fields |
| 16:04 |
kmlussier |
eeevil: I'll try to take some time to look at it once I'm done with web client testing. |
| 16:04 |
kmlussier |
If I ever finish with web client testing, that is. |
| 16:04 |
eeevil |
well, it started before browse, and both display and facet fields could probably benefit from being folded into the same underlying storage |
| 16:05 |
eeevil |
to cut down on duplicate data, at least |
| 16:06 |
eeevil |
kmlussier: note, that branch /only/ provides the backend. the tpac loader (and friends) would need to be taught to pull the data and pass it to the templates |
| 17:07 |
csharp |
jeff++ # hahah |
| 17:15 |
|
sandbergja joined #evergreen |
| 17:19 |
|
mmorgan left #evergreen |
| 17:28 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
|
cherri joined #evergreen |
| 17:39 |
|
jeff_ joined #evergreen |
| 19:53 |
|
ldwhalen joined #evergreen |
| 00:51 |
|
dreuther joined #evergreen |
| 01:03 |
|
dreuther_ joined #evergreen |
| 05:53 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:46 |
|
krvmga joined #evergreen |
| 08:02 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
mtate joined #evergreen |
| 12:50 |
|
jihpringle joined #evergreen |
| 12:53 |
eeevil |
bshum: https://bugs.launchpad.net/evergreen/+bug/1374091 updated |
| 12:53 |
pinesol_green |
Launchpad bug 1374091 in Evergreen master "unapi.bre and slow views" (affected: 1, heat: 6) [Undecided,New] |
| 12:55 |
bshum |
eeevil++ |
| 12:55 |
bshum |
I'll turn on metarecords in our test DB to look at that. We don't have them in production. |
| 12:59 |
eeevil |
bshum: note the change to the view, as well. that was force-pushed |
| 12:59 |
eeevil |
IOW, the first commit is different |
| 13:00 |
bshum |
eeevil: yep, already pushed that new commit to production |
| 16:55 |
jeff |
this agenda item says it'll be the default when 2.8 is released! [kidding! not official fact!] |
| 16:55 |
* jeff |
ducks |
| 16:55 |
RoganH |
Succeed or fail I'd rather learn from it while folks can fall back on the xul client. |
| 16:56 |
kmlussier |
The thing is, until people start using it at a live circ desk, we won't really know what all the bugs are, no matter how well we test it. |
| 16:56 |
bshum |
kmlussier: I'd be reluctant to call webby production ready till we've got more modules done for inter-related workflows. |
| 16:56 |
bshum |
Basic circ, sure. But people need to often do more. |
| 16:57 |
kmlussier |
bshum: Sure, but I can think of many libraries that have workstations that are primarily circ only. |
| 17:08 |
* bshum |
goes back to poking at his house of cards that he calls servers... |
| 17:32 |
jeffdavis |
jeff: FWIW, we still see staff client memory issues with the 2.6 client. |
| 17:34 |
jeffdavis |
I wrote up a survey last week to try and narrow down which usage patterns cause the biggest problems. |
| 17:35 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:48 |
|
wlayton joined #evergreen |
| 18:19 |
|
Canepa_ joined #evergreen |
| 18:35 |
csharp |
jeff: we have some libraries reporting the same thing about freezes/high RAM usage |
| 03:02 |
|
bshum joined #evergreen |
| 03:13 |
|
mtcarlsoz joined #evergreen |
| 04:07 |
|
vanya joined #evergreen |
| 05:24 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:01 |
|
mtate joined #evergreen |
| 08:01 |
|
eeevil joined #evergreen |
| 08:06 |
|
Callender joined #evergreen |
| 16:45 |
bshum |
@later tell eeevil Oops, so I apparently did not notice that we're missing all the coded_value_map entries for changes made in https://bugs.launchpad.net/evergreen/+bug/1374091 |
| 16:45 |
pinesol_green |
bshum: The operation succeeded. |
| 16:45 |
pinesol_green |
Launchpad bug 1374091 in Evergreen master "unapi.bre and slow views" (affected: 1, heat: 6) [Undecided,New] |
| 16:45 |
bshum |
That led to things like... acq loading no longer matching for the link to catalog I think. |
| 16:45 |
* bshum |
ponders the SQL a bit before his next flight. |
| 16:46 |
* bshum |
reverts patch from his production system to test this theory. |
| 16:48 |
bshum |
Looks like it's the coalesce part of the SQL select |
| 16:48 |
bshum |
Whichever is first, m.attr is the only thing shown |
| 16:48 |
bshum |
If I put c.ctype first, then I get only the controlled values in the output |
| 16:48 |
bshum |
I'll update the bug ticket with these findings. |
| 16:51 |
bshum |
I guess that makes sense actually, COALESCE only grabs the first one it finds, else none? |
| 16:52 |
eeevil |
bshum: it gets the first non-null value. One or the other should be null |
| 16:53 |
bshum |
Hmm |
| 16:53 |
bshum |
Doesn't seem to be the case for some reason then. |
| 16:53 |
bshum |
I'm only getting one or the other set. |
| 16:53 |
eeevil |
It was working in my direct-select test |
| 16:54 |
eeevil |
I'll look as soon as I can. Probably tomorrow |
| 16:54 |
bshum |
No worries, it's the weekend. Thanks! |
| 17:01 |
* bshum |
gets on his next plane home from DC to NY. |
| 17:18 |
bshum |
csharp++ # the hackery continues! |
| 17:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:15 |
csharp |
heh |
| 20:55 |
|
vanya joined #evergreen |
| 21:53 |
|
vanya joined #evergreen |
| 02:31 |
|
jeff joined #evergreen |
| 03:56 |
|
vanya joined #evergreen |
| 04:29 |
|
vanya joined #evergreen |
| 05:10 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:27 |
|
artunit joined #evergreen |
| 08:00 |
|
rjackson-isl joined #evergreen |
| 08:00 |
|
phasefx joined #evergreen |
| 14:37 |
jeff |
{hosts, ["localhost", "private.localhost", "public.localhost"]}. |
| 14:37 |
jeff |
vanya: if you remove or comment out one of those (probably the first would be best), ejabberd should start. |
| 14:38 |
kmlussier |
Dyrcona: I thought you fixed some things with the aged circulations but developed the aged holds. But I could be misremembering. |
| 14:39 |
vanya |
jeff : I tried that. Infact, I tried to run it with both the host declarations removed too(just to test). But it still gave the same error. |
| 14:39 |
vanya |
Just a second- I'll try it again. |
| 14:40 |
kmlussier |
vanya: Did you say Ubuntu 14.04? Dyrcona/bshum: Are there still problems with using Evergreen on 14.04? |
| 14:41 |
vanya |
Same error |
| 14:41 |
kmlussier |
vanya: Also, I recommend you use a site like pastebin to paste your output. It's a little cleaner than pasting it in the channel. :) |
| 16:38 |
|
nhilton_ joined #evergreen |
| 16:39 |
jeff |
and if you run into any trouble, ask away -- we try to be a pretty helpful bunch. |
| 16:45 |
|
vanya joined #evergreen |
| 16:48 |
kmlussier |
It would be nice to have a minimum resolution for the web client that we should be checking in testing. |
| 16:49 |
kmlussier |
Does anyone know if there was a minimum resolution that was in mind when it was being designed? |
| 16:52 |
graced |
kmlussier: I believe there was. berick is the one who would have that off the top of his head |
| 16:53 |
kmlussier |
graced: Ah, you're still here. I would have sent you a pm, but I assumed you would be weekend'ing already. :) |
| 16:53 |
graced |
I am often weekending by now... so it was a good bet |
| 17:00 |
kmlussier |
graced: Also, is there a set of supported browsers for the web client? IOW, should I be telling people not to be testing on IE? |
| 17:02 |
graced |
kmlussier: there is some kind of new issue with Firefox that we've found where we can't even get past the login screen. So that's a known issue at this point but should get resolved soon. |
| 17:03 |
graced |
I have the best luck with Chrome. IE is okay but I don't think it will be a supported browser. |
| 17:03 |
kmlussier |
OK. I can log in with Firefox still. Lucky me! :) |
| 17:22 |
vanya |
@dessert jeff |
| 17:22 |
* pinesol_green |
grabs some Krispy Kreme Donuts for jeff |
| 17:38 |
kmlussier |
Good night #evergreen! |
| 17:42 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:43 |
|
berick joined #evergreen |
| 17:48 |
|
vanya joined #evergreen |
| 18:12 |
vanya |
Is anyone there? |
| 18:13 |
vanya |
When I'm trying to test the default OpenSRF services, it gives me the error message: Received no data from server. |
| 18:14 |
vanya |
When I looked it up, I found that many people had reported the same on the mailing lists, but I couldn't find a solution to it. |
| 18:14 |
vanya |
Does anyone have an idea what I should be doing about it? |
| 18:20 |
|
geoffsams joined #evergreen |
| 18:30 |
|
tsbere joined #evergreen |
| 19:41 |
|
vanya joined #evergreen |
| 20:29 |
vanya |
jeff : are you there? |
| 20:36 |
bshum |
vanya: "Received no data from server" is a pretty generic message that things aren't working |
| 20:37 |
bshum |
vanya: Looking at the logs might reveal any specific errors. Perhaps something in /openils/var/log/osrfsys.log |
| 20:37 |
vanya |
bshum : Hi! I figured I'm having a lot of problem because of Ubuntu 14.04 |
| 20:39 |
bshum |
The 2.6 series of Evergreen only operates with Ubuntu 12.04 |
| 20:39 |
bshum |
14.04 is only supported after 2.7 series of Evergreen. |
| 20:39 |
vanya |
Oh! |
| 20:39 |
bshum |
That's something new that we're still working on in the community |
| 20:40 |
bshum |
Is to complete support for 14.04. |
| 20:40 |
bshum |
The current recommendation is to use Ubuntu 12.04, 64-bit server edition for things you wish to test out with OpenSRF/Evergreen. |
| 20:40 |
bshum |
For Ubuntu anyways. |
| 20:40 |
vanya |
In that case, I guess I'll have to find a virtual machine to support 12.04, or just revert back to 12.04 on my system. |
| 20:41 |
bshum |
vanya: It's definitely helpful to use virtual machines when testing things. |
| 20:42 |
vanya |
I'll browse around for a virtual machine then :) |
| 20:42 |
vanya |
Thank you! I was unable to sleep until I got the environment set up. I've been struggling with 14.04 for a while now. |
| 20:47 |
bshum |
vanya: Sure thing, good luck on your next steps. 14.04 has been a little tricky at times :( |
| 05:01 |
|
vanya joined #evergreen |
| 05:03 |
jeff |
ah lovely. self checkout machine triggering emails every 2, then 5 minutes (alternating) about being "disconnected" |
| 05:15 |
jeff |
...and it stops. |
| 05:31 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:05 |
|
cherri joined #evergreen |
| 06:42 |
|
snigdha26 joined #evergreen |
| 06:46 |
|
cherri joined #evergreen |
| 10:13 |
RoganH |
And Hangouts are of course a backup option. |
| 10:14 |
|
jwoodard joined #evergreen |
| 10:14 |
kmlussier |
RoganH: do I have to download something to get ready? |
| 10:16 |
jeff |
recent version of firefox or chrome is all, iirc. |
| 10:17 |
jeff |
kmlussier: i'll send you a link to test. |
| 10:17 |
kmlussier |
Thanks! |
| 10:18 |
jeff |
sent. |
| 10:19 |
kmlussier |
Ugh. Not supported in Firefox. I'll try it in Chrome, but I've had an ongoing problem where I rarely get sound in Chrome that I never had a chance to investigate/fix. |
| 13:47 |
gmcharlt |
much better |
| 13:47 |
kmlussier |
I'll be back in a couple of hours. |
| 13:48 |
RoganH |
Nothing but quality here folks. |
| 13:52 |
pastebot |
"csharp" at 64.57.241.14 pasted "berick: test output from test_client.pl" (50 lines) at http://paste.evergreen-ils.org/14 |
| 13:52 |
csharp |
berick^^ |
| 13:57 |
|
yboston joined #evergreen |
| 13:59 |
csharp |
@praise videoconferencing |
| 16:01 |
phasefx |
maybe related, I can't get the page to work, and suspects it's because I don't have a webcam |
| 16:01 |
jeff |
(thankfully not a stray credential/key/etc) |
| 16:01 |
kmlussier |
phasefx: You might be right. mmorgan doesn't have a webcam either and was never able to get it to work. |
| 16:02 |
* phasefx |
goes and scrounges up one to test |
| 16:02 |
jeff |
huh. i have three laptops, a chromebook, a tablet and an ipod on/near my desk. all of them have a camera. |
| 16:03 |
* mmorgan |
remains in the ranks of the webcam deprived :-( |
| 16:03 |
phasefx |
big brother isn't watching you |
| 17:01 |
|
kmlussier joined #evergreen |
| 17:02 |
kmlussier |
Heading out, but can I put in a request for Google Hangouts for tomorrow? :) |
| 17:04 |
berick |
@later tell kmlussier re: google hangouts.. request noted. |
| 17:04 |
pinesol_green |
berick: The operation succeeded. |
| 17:06 |
|
cherri joined #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:16 |
berick |
one step closer to no more ruby.. http://paste.lisp.org/display/143835 |
| 17:16 |
berick |
direct generation of EDI |
| 17:16 |
|
MrMayor joined #evergreen |
| 14:56 |
tspindler |
collum: I will try that |
| 14:56 |
collum |
http://bit.ly/1rmo0fp |
| 14:57 |
kmlussier |
Maybe because you put the subfield in the MARC data field, you don't need to add it in the field above? |
| 14:59 |
tspindler |
collum: still not working, I'm testing this on the MassLNC community test server |
| 15:01 |
collum |
tspindler: are you getting an error screen, or is it just popping back to the batch edit screen? |
| 15:02 |
collum |
If it pops back to the edit screen, make sure that the proper bucket is still selected. |
| 15:02 |
tspindler |
I get to the screen and it is 1 success, 0 failures but the record is not updated. See http://mlnc4.mvlcstaff.org/eg/opac/record/239 |
| 15:08 |
collum |
You can change the MARC data to the entire field 505 \\$aJ.R.R Tolkien ...., but that sort of defeats the batch purpose. |
| 15:08 |
tspindler |
collum: yeah, i have been just trying to figure out the correct way to used the regex to get a portion of the field |
| 15:09 |
tspindler |
collum: it worked for you on master? |
| 15:10 |
collum |
On a test machine of mine, 2.2.0, but I changed the entire 505, not a portion of it. |
| 15:10 |
tspindler |
collum: I am testing this on master, i can update a whole field fine |
| 15:11 |
collum |
Yep. That's what I did, as well. |
| 15:12 |
collum |
My catalogers mainly use this for author entries. When a death date has to be added. |
| 15:12 |
tspindler |
we haven't used it much so I'm just exploring what can be done instead of going on the database side and doing db updates with sql |
| 17:23 |
berick |
and then i guess it will be time for some extreme fajitas |
| 17:25 |
bshum |
:D |
| 17:48 |
bshum |
@later tell yboston For opensrf, I'm hoping to get this bug merged later to help with the instructions for websockets: https://bugs.launchpad.net/opensrf/+bug/1369169 |
| 17:48 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:48 |
pinesol_green |
bshum: The operation succeeded. |
| 17:48 |
pinesol_green |
Launchpad bug 1369169 in OpenSRF "Add install instructions for websockets to README (and other cleanup)" (affected: 1, heat: 6) [Undecided,New] |
| 17:52 |
|
vanya joined #evergreen |
| 17:58 |
|
snigdha26 joined #evergreen |
| 18:01 |
|
nhilton_ joined #evergreen |
