| # | Time | Nick | Message |
|---|
| # | 02:35:06 | natschil has joined #evergreen |
| # | 03:04:15 | Manderson has quit IRC |
| # | 03:05:57 | Manderson has joined #evergreen |
| # | 05:55:34 | natschil has quit IRC |
| # | 05:56:08 | natschil has joined #evergreen |
| # | 08:21:42 | Ghidorah has joined #evergreen |
| # | 08:47:04 | sfortin has joined #evergreen |
| # | 08:57:04 | jeff___ has joined #evergreen |
| # | 09:00:14 | akilsdonk has joined #evergreen |
| # | 09:08:04 | Callender has quit IRC |
| # | 09:13:38 | kmlussier has joined #evergreen |
| # | 09:17:30 | Callender has joined #evergreen |
| # | 09:22:19 | saltycraig has joined #evergreen |
| # | 09:26:59 | bgoble has joined #evergreen |
| # | 09:31:52 | tspindler has joined #evergreen |
| # | 09:39:27 | dbs has joined #evergreen |
| # | 09:46:31 | jeff___ is now known as jeff |
| # | 09:46:35 | jeff has joined #evergreen |
| # | 09:52:42 | dbs | bshum++ # although I noticed the README does reference some outdated distros and not ubuntu-lucid and pushed a fix for that |
| # | 09:54:24 | Ghidorah | How does one reset the admin password in Evergreen 2.0? |
| # | 09:55:09 | phasefx | Ghidorah: http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#unable_to_login_through_the_web_interface_or_staff_client_after_a_successful_install_try_dan_scott_s_tip_for_resetting_your_password |
| # | 09:55:31 | phasefx | Ghidorah: or http://tinyurl.com/3aoqcf3 |
| # | 09:55:37 | Ghidorah | Thank you sir |
| # | 09:56:05 | dbs | Ghidorah: even better |
| # | 09:56:38 | dbs | as the opensrf user, Open-ILS/src/support-scripts/eg_db_config.pl --admin-password new_password |
| # | 09:56:43 | eeevil | bshum / dbs: off to a meeting, but I'll be looking at the 2.1 upgrade script this morning, and cutting 2.0.9 unless there are more outstanding issues to wait on |
| # | 09:56:58 | phasefx | dbs++ |
| # | 09:58:59 | bshum | dbs: It also just occurred to me that the bug was filed under Evergreen, but as it pertains to OpenSRF should have been made in the OpenSRF LP area. |
| # | 09:59:09 | bshum | Technically. |
| # | 09:59:22 | dbs | bshum: yes, but it doesn't matter enough to bother switching it over |
| # | 09:59:52 | tsbere | phasefx: Any thoughts on the two macros created in this branch? http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=shortlog;h=refs/heads/magic_macros |
| # | 10:00:46 | dbs | eeevil: for 2.0.9, we probably want to finalize adding (at a minimum) -P to the aptitude command and ideally a clear warning message before removing postgresql 8 bits and possibly databases |
| # | 10:16:58 | parsr has joined #evergreen |
| # | 10:24:48 | parsr | Upgrading 2.0.6 > 2.0.8 -- pg upgrade scripts, get this error: "Error: No existing local cluster is suitable as a default target. Please see man pg_wrapper(1) how to specify one." We're using single DB server, so assume I can ignore, correct? |
| # | 10:25:51 | eeevil | dbs: righto ... and there's one outstanding fix forthcoming from senator, so I'll table it for this morning |
| # | 10:26:31 | dbs | eeevil: oh, actually, I think the postgresql database removal thing is only in 2.1 |
| # | 10:28:48 | phasefx | tsbere: I likes. I'll give them a spin shortly and sign-off, though maybe we should get one more +1 from someone for the way you're using YAOUS |
| # | 10:34:06 | bshum | parsr: I haven't seen that error before, but a cursory google search on that says to me that your upgrade scripts aren't finding their way to your PG database somehow. Maybe check to make sure it's running on the right ports, etc.? |
| # | 10:36:59 | tsbere | phasefx: Not quite done, I want to add a commit to add a few initial YAOUS for use. Like "header_text", "footer_text", "notice_text" and similar. (hence it not being a working branch or having a launchpad entry yet) |
| # | 10:37:17 | phasefx | tsbere: roger that |
| # | 10:37:49 | tsbere | But yea, having someone else provide views on the use of YAOUS isn't a bad idea |
| # | 10:38:44 | phasefx | we might just want to move the storage of receipt templates to something like YAOUS in the first place |
| # | 10:39:07 | tsbere | No, I can see issues there |
| # | 10:39:16 | phasefx | though I can see the use for machine-specific customizations |
| # | 10:39:46 | tsbere | We have libraries where one workstation has no receipt printer access and thus has everything they print rigged for laser printer use, but the workstation right next to it has a receipt printer and is thus rigged for using it. |
| # | 10:40:26 | dbs | So we need YAWS? |
| # | 10:40:51 | tsbere | Receipt templates are already stored on the workstation. So....no. |
| # | 10:40:56 | phasefx | tsbere: maybe more in the vein of stock templates; instead of being hard-coded in the data.js, they come from YAOUS, but local changes still trump |
| # | 10:41:33 | dbs | tsbere: I meant workstation settings stored centrally, So maybe yes |
| # | 10:42:01 | tsbere | phasefx: That could work....if we had a decent multi-line OU setting editing box. I think right now we have a single-liner for pretty much everything, so not all that fun to edit receipt templates with. |
| # | 10:43:01 | senator | eeevil: https://bugs.launchpad.net/evergreen/+bug/831317 |
| # | 10:43:02 | phasefx had imagined at one point that staff client settings would meld from different sources (org, user, workstation), but never made a generic infrastructure for it |
| # | 10:43:25 | tsbere | dbs: So you are thinking a way to store workstation settings in the DB instead of at the workstation (compared to per user settings that the DB already supports)? |
| # | 10:43:43 | dbs | tsbere: yes, that's what I was suggesting |
| # | 10:43:57 | dbs | because a user moves for WS to WS. but printers generally dont. |
| # | 10:43:58 | phasefx | (org, user, workstation->server, workstation->file system) |
| # | 10:44:20 | tspindler has quit IRC |
| # | 10:44:28 | tsbere isn't fully sure why you would want in-db storage of settings that only ever apply to a single computer when the computer can store them already |
| # | 10:44:42 | dbs | tsbere: security? |
| # | 10:44:54 | dbs | a hell of a lot easier to audit what people are storing? |
| # | 10:45:08 | dbs | a hell of a lot easier to fix globally? |
| # | 10:45:16 | phasefx | and share settings |
| # | 10:45:43 | dbs | you may not still be fully sure, but hopefully that puts a little gas in the "sureness" tank |
| # | 10:45:46 | eeevil | senator: thankee sai |
| # | 10:45:50 | parsr | bshum: thanks for earlier typo correction. Re: ports, you're onto something too. On dev, we're running pg on port 5454 (instead of default) so that I could run putty tunnels on both production and dev at same time from my desktop. Ok so I retry with "-h localhost:5454" as part of the upgrade scripts? Thx... |
| # | 10:46:01 | dbs | that said, I'm not going to be doing any work on it any time soon |
| # | 10:46:15 | tsbere | If they are workstation specific (compared to OU level) then the only two reasons *I* can come up with are "settings are automatically restored when you replace the workstation but keep the name" and "if you are in the habit of using the same name for multiple machines (insanity) then the settings stay in sync" |
| # | 10:46:21 | bshum | parsr: Maybe "-h localhost -p 5454" (-p I think is for ports) |
| # | 10:46:22 | phasefx thinks there are folks now that do complicated things with pushing per-machine settings when they deploy staff clients |
| # | 10:46:38 | phasefx | like pre-registering workstations |
| # | 10:46:56 | phasefx | though a workstation-server settingw ouldn't help with that :) |
| # | 10:48:00 | tsbere | Having the ability to say "if the workstation is still using the default then use this other setting instead" might not be bad....if manually picking the "default" didn't make the backend prefs system say you didn't have a local choice selected. |
| # | 10:48:41 | dbs | maybe it's more fun asking people to copy & paste you templates they have configured locally on their particular workstation when they need help fixing things up |
| # | 10:49:32 | tsbere | Hah. Like I could find the right template in the DB without remote controlling their computer anyway. |
| # | 10:50:29 | phasefx | could also experiment with server-side rendering of templates in a neat little sandbox |
| # | 10:51:15 | dbs | I guess it's a terrible idea then |
| # | 10:51:16 | phasefx | though I still fear latency with checkout receipts |
| # | 10:51:19 | dbs goes away to do work |
| # | 10:52:35 | tsbere | dbs: I had to write the "default the workstation name to the local computer name" code to keep us from having 9 or more workstations registered as "SHORTCODE-" in any given library. Your mileage may vary on usefulness of workstation names in debugging. |
| # | 10:53:02 | dbs is working |
| # | 11:02:29 | sal_ has joined #evergreen |
| # | 11:03:27 | parsr | bshum: thanks again. worked; only now I get errors for 206>207 db upgrade: "relation "authority_record_deleted_idx" already exists." followed by lots of "ERROR: current transaction is aborted, commands ignored until end of transaction block" |
| # | 11:04:00 | bshum | parsr: Oh the fun of figuring out why upgrade scripts hate us so much :) |
| # | 11:05:54 | bshum | Guessing that the index already exists. I've seen drop if exist commands in other upgrade SQL, but not sure what the consequences of doing so are. |
| # | 11:06:07 | bshum | I'll have to defer to others in the channel about those sorts of upgrade script issues. |
| # | 11:06:53 | parsr | bshum: thanks for looking.. |
| # | 11:09:57 | parsr | FWIW: errors here: http://goo.gl/y4EJr |
| # | 11:13:37 | bshum | parsr: So it looks like line 10 is your problem. |
| # | 11:13:48 | bshum | parsr: Well, where it starts anyways |
| # | 11:15:25 | bshum | Two choices I can think of, either putting a "DROP INDEX IF EXISTS authority_record_deleted_idx;" before line 10. Or commenting out line 10 with two dashes -- (and assuming that the index you already have is fine?) |
| # | 11:16:25 | bshum | But we don't use authority records, so you'll probably want a second opinion on all of that. |
| # | 11:16:29 | bshum | (yet) |
| # | 11:19:41 | tspindler has joined #evergreen |
| # | 11:25:32 | drdata_esi has joined #evergreen |
| # | 12:06:29 | yboston has joined #evergreen |
| # | 12:07:32 | AaronZ-PLS has quit IRC |
| # | 12:12:57 | kmlussier has quit IRC |
| # | 12:13:29 | kmlussier has joined #evergreen |
| # | 12:13:43 | _bott_ has left #evergreen |
| # | 12:22:38 | blongwel has joined #evergreen |
| # | 12:27:08 | Ghidorah has quit IRC |
| # | 12:31:58 | parsr has quit IRC |
| # | 12:58:20 | jeffdavis has joined #evergreen |
| # | 12:59:27 | sal_ | berick: (or anyone else interested) since you seem to be attached to (testing?) chargeable loans (and dyrcona isn't here), do you know where I can find the ITEM_RENTAL_FEE_REQUIRED.override and ITEM_DEPOSIT_FEE_REQUIRED.override group permissions for SIP group? They're not showing up in my dropdown. |
| # | 13:00:36 | eeevil | sal_: you'll likely need to add them via the permission list interface |
| # | 13:00:52 | _bott_ has joined #evergreen |
| # | 13:00:56 | eeevil | then they'll be available (after reloading the interface for group management) |
| # | 13:11:22 | jeffdavis | gmcharlt: you were asking last week about sitka's patron deletion thing... |
| # | 13:11:36 | dbs has quit IRC |
| # | 13:11:37 | jeffdavis | I think jamesrf pointed you at the repo for that, do you need anything else? |
| # | 13:12:23 | gmcharlt | jeffdavis: no, though I do have a question - any plans to submit a core feature for EG based on it? |
| # | 13:12:47 | edoceo has joined #evergreen |
| # | 13:13:53 | jeffdavis | that's something I'd like to do eventually, but it's not a high priority here since the current setup works for us |
| # | 13:14:12 | gmcharlt | right, thanks |
| # | 13:41:36 | asimon has joined #evergreen |
| # | 13:43:14 | asimon | I'd like to delete a large subset of patrons from our system. When I try to delete them, nothing happens, which I assume is because of triggers. Does anyone have a set of SQL commands that will do what I want? |
| # | 13:44:04 | gmcharlt | asimon: do the patrons have any circ transactions associated with them yet, or just addresses, barcodes, etc.? |
| # | 13:47:40 | asimon has quit IRC |
| # | 13:51:59 | parsr has joined #evergreen |
| # | 13:56:20 | kcollier has joined #evergreen |
| # | 13:58:04 | parsr | bshum: Regarding 206>207 PG upgrade script, commenting out line 10 seemed to work for me. Followed that up with 207>208 upgrade and no errors reported in log. Thanks for your feedback! |
| # | 13:58:20 | bshum | parsr: Cheers! Glad it worked out alright. |
| # | 13:58:47 | bshum | parsr: As a note, not sure if upgraded systems are affected by the recent 2.0.8 issues, but you should check out the resolutions made for upcoming 2.0.9. |
| # | 14:07:52 | parsr | bshum: thanks. looks ok for me so far re the current 6 bugs targeted for 2.0.9. These last "lazy" outdoor weekends have made it challenging to come in for the minor upgrade so always nice if you can "time it right" following releases. |
| # | 14:10:40 | bshum | parsr: Fair enough :) |
| # | 14:22:44 | saltycraig has quit IRC |
| # | 14:22:55 | kmlussier has quit IRC |
| # | 14:23:10 | kmlussier has joined #evergreen |
| # | 14:23:57 | Darlene has joined #evergreen |
| # | 14:33:51 | kcollier | Time to start the Documentation Interest Group meeting for August / September. |
| # | 14:34:06 | kcollier | Agenda is here: http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20110822-agenda |
| # | 14:34:36 | kcollier | Do we have a volunteer to take minutes? |
| # | 14:34:41 | asimon has joined #evergreen |
| # | 14:34:52 | kcollier | And meanwhile, let's start with introductions. |
| # | 14:35:11 | kcollier is Karen Collier, Kent County Public Library |
| # | 14:35:17 | sfortin is Sally Fortin, Equinox Software |
| # | 14:35:55 | akilsdonk | is Angela Kilsdonk, also Equinox Software |
| # | 14:36:42 | asimon | gmcharlt: Some of the patrons have test transactions, but 99% of them do not. I want to save some patrons, so TRUNCATE CASCADE will not work. |
| # | 14:37:38 | bshum is Ben Shum, Bibliomation (lurking) |
| # | 14:37:48 | sborger has joined #evergreen |
| # | 14:37:52 | raynerj has joined #evergreen |
| # | 14:38:15 | yboston is Yamil Suarez, Berklee College of Music |
| # | 14:38:24 | kcollier | Anyone else here for today's meeting? |
| # | 14:38:44 | sborger | *sborger is Shauna Borger with Evergreen Indiana |
| # | 14:39:18 | kcollier | Feel free to introduce yourself at any point if we have latecomers. |
| # | 14:39:19 | sfortin | kcollier: i can take minutes if you'd like |
| # | 14:39:20 | raynerj | raynerj is June Rayner from eiNetwork |
| # | 14:39:34 | kcollier | Thank you. sfortin++ |
| # | 14:40:22 | KN2W has joined #evergreen |
| # | 14:40:34 | kcollier | Okay, let's start with updates from content coordinators. Which of our content coordinators are here today? |
| # | 14:41:49 | raynerj | June and Roni are here for System Admin |
| # | 14:41:50 | yboston | DIG release coordinator in the house |
| # | 14:42:27 | kcollier | Okay, who wants to start? Anything to report since the last meeting? |
| # | 14:43:01 | yboston | I can start |
| # | 14:43:08 | kcollier | Thanks |
| # | 14:43:15 | yboston | 1) Under the goal to have single source of installations instructions: I looked over a very promising ASCII doc conversion work done by dbs, though I have not given him feedback yet. |
| # | 14:43:30 | yboston | I experimented with installing the EG server from the README, and informally reported missing information in the README, which dbs updated |
| # | 14:43:40 | yboston | I need to do more work on this goal to keep up with dbs's contributions |
| # | 14:43:45 | yboston | dbs++ |
| # | 14:43:55 | yboston | 2) bumped up EG version on official docs for the EG 2.0.8 release |
| # | 14:44:06 | yboston | still need to finish bumping up the new OSRF release later today/tomorrow |
| # | 14:44:17 | kmlussier_ has joined #evergreen |
| # | 14:44:27 | yboston | 3) Successfully tested out with having DIG volunteers June & Roni push documentation additions to my documentation Git repository. My time spent trying to learn Git is starting to pay off :) |
| # | 14:44:36 | yboston | that is all for me |
| # | 14:44:43 | b_bonner_ has joined #evergreen |
| # | 14:44:53 | kcollier | Great! Thank you. |
| # | 14:45:06 | kcollier | June? Roni? |
| # | 14:45:10 | kcollier | Anything to report? |
| # | 14:45:44 | raynerj | Yes, we worked with Ymil on a test push - working out the workflow. Thanks Yamil |
| # | 14:46:18 | raynerj | I'm next going work on documentation for adding data sources. There was an email about this last week while I was on vacation |
| # | 14:46:41 | kmlussier has quit IRC |
| # | 14:46:42 | kmlussier_ is now known as kmlussier |
| # | 14:47:16 | raynerj | Are there any other priorities for documentation? |
| # | 14:48:04 | kcollier | That's a very good question. Does anyone have any initial thoughts on that? |
| # | 14:49:19 | kcollier | Or maybe we can save that one for New Business so people have some time to think about it? |
| # | 14:49:55 | kcollier | raynerj: did you have anything else to report at this point? |
| # | 14:50:11 | raynerj | No, that's it for me. |
| # | 14:50:18 | kcollier | Thank you. :) |
| # | 14:50:22 | asimon has quit IRC |
| # | 14:50:43 | kcollier | Anyone else... coordinator or non-coordinator with anything to report at this point? |
| # | 14:52:01 | yboston | Btw, when would it be a good time to mention a thought to the group during the meeting? |
| # | 14:53:23 | kcollier | The agenda is pretty flexible. If it's something discussion-wise that could get lengthy it could go in new or old business depending on whether it's come up before or not. |
| # | 14:54:26 | kcollier | And from the silence it sounds like we're ready to move on to old business. Do we have any? |
| # | 14:55:19 | sal_ | eeevil: thanks, that did it (and I can now "rent" items via SIP) |
| # | 14:55:50 | yboston | Quick question: is there a test 2.1 server that DIG members can use to create new/update documentation? |
| # | 14:56:02 | yboston | (public server) |
| # | 14:56:41 | kcollier | Good question. Does anyone know of one available? |
| # | 14:57:40 | yboston | I suspect that lack of access to a server running a 2.0 or greater version of EG and with sample data might be partially slowing down our progress |
| # | 14:58:15 | mrpeters-isl has quit IRC |
| # | 14:58:25 | mrpeters-isl has joined #evergreen |
| # | 14:58:32 | kcollier | It looks like there's one running 2.1 RC1 and another running 2.0.7. http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers |
| # | 14:58:59 | yboston | thanks |
| # | 14:59:17 | kcollier | no problem |
| # | 14:59:35 | kcollier | Is there any more old business? |
| # | 15:00:11 | kcollier | How about any new business? |
| # | 15:01:18 | sfortin has new business |
| # | 15:01:32 | Manderson | ls |
| # | 15:01:50 | kcollier | Go ahead, sfortin. |
| # | 15:02:37 | bgoble has quit IRC |
| # | 15:03:21 | sfortin | i first wanted to mention that we have a new trainer at ESI, Angela Kilsdonk, who will be writing documentation for the community also. she's also volunteered to work on stylesheets for DIG. |
| # | 15:03:41 | sfortin | i think she's already introduced herself to the mailing list, but she is here today also |
| # | 15:04:23 | sfortin | second, i've been working to make the documentation that we write more readily accessible to the community and available in more formats and wanted to share that work with DIG |
| # | 15:04:39 | sfortin | Per a request from the community, we will be making our documentation available in asciidoc files that can be downloaded from our website. We don't have that piece in place yet, but we are working on it. |
| # | 15:04:55 | sfortin | We will also be making documentation available in HTML on our website. |
| # | 15:05:15 | sfortin | Two new pieces of documentation are now available: "conjoined items" and "authority control sets." Both of these features will be available in 2.1. |
| # | 15:05:36 | sfortin | The documentation is available here: |
| # | 15:05:49 | sfortin | http://www.esilibrary.com/esi/docs/ |
| # | 15:06:05 | sfortin | You can also access it by pointing your browser to esilibrary.com, and clicking the Services tab, and then clicking either the "Training" tab or the "Software Development" tab and clicking on the "documentation" link. |
| # | 15:06:32 | sfortin | This is still a work in progress, but we hope that this process will make it easier both for those in DIG and for those who might use Evergreen or simply be interested in Evergreen to access the documentation that we write. |
| # | 15:06:47 | kcollier | That's great news. Thank you. sfortin++ |
| # | 15:07:23 | sfortin | I hope it's useful. If anyone has would like to submit feedback, please feel free to contact me |
| # | 15:07:37 | sfortin | That's all I have, kcollier |
| # | 15:07:45 | kcollier | Thanks. :) |
| # | 15:08:33 | Darlene has quit IRC |
| # | 15:08:39 | parsr has quit IRC |
| # | 15:09:03 | kcollier | June raised the question of what priorities that group has set to be working on at the moment. Is that an issue we'd like to start to address today (meaning does anyone have anything they want to say about it now)? |
| # | 15:09:10 | parsr has joined #evergreen |
| # | 15:09:39 | yboston | Here is a quick thought, I would consider giving some priority to the areas where EG 2.1 has very different functionality behavior than 2.0 or 1.6 |
| # | 15:10:05 | kcollier | That's a very good point. |
| # | 15:10:13 | yboston | or perhaps new functionality not found in the other releases |
| # | 15:10:32 | raynerj | yes, good point |
| # | 15:10:34 | phasefx | is there anything DIG itself needs (as opposed the documentation) that might deserve some priority? |
| # | 15:11:04 | kcollier | Another good question. |
| # | 15:11:50 | kcollier | Any thoughts? Should we raise these questions on the mailing list so those not in attendance today can contribute? |
| # | 15:12:11 | yboston | I was wondering too, I want also want ideas of what we can try to improve our documentation output. For example I wondered if having a virtual machine version of 2.1 loaded with test data |
| # | 15:13:10 | yboston | would help |
| # | 15:13:27 | kcollier | A virtual machine with test data is an interesting idea. Does anyone know if the test server linked to earlier has any test data loaded? |
| # | 15:14:04 | phasefx | a "reference" image of Evergreen that matched examples in the documentation would be an awesome thing to distribute with the documentation |
| # | 15:14:39 | yboston | kcollier: the 2.1 RC1 seems to have some test marc records |
| # | 15:15:18 | kmlussier has quit IRC |
| # | 15:15:18 | tspindler has quit IRC |
| # | 15:15:35 | phasefx | http://evergreen-ils.org/dokuwiki/doku.php?id=advocacy:demonstration_data |
| # | 15:15:42 | Joe1010988 has joined #evergreen |
| # | 15:17:34 | yboston | thanks |
| # | 15:18:19 | kcollier | Cool. Any more discussion on this topic? |
| # | 15:18:57 | kcollier | Any more new business? |
| # | 15:19:20 | kcollier | Questions, comments, etc? |
| # | 15:20:18 | kcollier | If not, then let's consider ourselves done for today. Our next meeting is slated for October 3, same time and place. |
| # | 15:20:24 | yboston | Perhaps, we can restate phasefx's question on the mailing list to get more feedback, in case we can find some issues we can address |
| # | 15:20:33 | yboston | in the near future |
| # | 15:20:45 | kcollier | Sounds good to me. |
| # | 15:20:55 | kcollier | Thank you everyone for your time and contributions. |
| # | 15:21:05 | sfortin | kcollier++ |
| # | 15:21:08 | kcollier | Enjoy the rest of your day. |
| # | 15:21:56 | raynerj | kcollier++ |
| # | 15:22:22 | yboston | kcollier++ |
| # | 15:22:36 | akilsdonk | kcollier++ |
| # | 15:24:01 | Joe1010988 | Sorry if I'm interrupting anything, but I'm hoping that someone's willing to share their expertise. Do any of you know how to purge patrons from a PostgreSQL? We're running Evergreen 2.0 and even with the psql DELETE command all that happens is the `deleted` flag being set. Is there a way to actually delete the rows? |
| # | 15:24:35 | Joe1010988 | *postgreSQL database. Evidently multitasking doesn't lend itself to good grammar. |
| # | 15:27:37 | dbs has joined #evergreen |
| # | 15:28:03 | phasefx | Joe1010988: there's a stored procedure for obliterating patron data, though burned husks of data are left behind |
| # | 15:28:55 | phasefx | Joe1010988: actor.usr_purge_data |
| # | 15:29:25 | kcollier has quit IRC |
| # | 15:29:41 | Joe1010988 | phasefx: How do I access this procedure? |
| # | 15:30:19 | Joe1010988 | phasefx: is it a process within postgres or from the evergreen client console? |
| # | 15:31:01 | phasefx | Joe1010988: both.. there's a client UI for it (under Other, when you pull up a patron), or you can call the procedure from psql |
| # | 15:32:20 | jeff | Joe1010988: also, relevant to your query -- why are you deleting the users? are you resetting the data in a test/training database, are you cleaning up after a migration attempt, or something else? |
| # | 15:33:31 | Joe1010988 | phasefx: if I call it from within psql, will it purge all rows in the actor.usr table (and all hard links) or is it possible to tell it to only purge users with an ID greater than, say, 10? |
| # | 15:33:38 | sborger has quit IRC |
| # | 15:34:23 | Joe1010988 | Jeff: our librarians are just starting out and ran a migration attempt. While it worked they then wanted to change what data fell into which fields so now I'm trying to figure out how to delete the imported rows while leaving their own personal accounts in place. |
| # | 15:38:43 | Joe1010988 | Or, possibly more possible and since the `deleted` flags are already set on the bad rows: does actor.usr_purge_data delete only flagged accounts? |
| # | 15:39:08 | parsr has quit IRC |
| # | 15:40:29 | edoceo has quit IRC |
| # | 15:43:53 | b_bonner_ has quit IRC |
| # | 15:44:58 | KN2W has quit IRC |
| # | 15:52:57 | natschil has quit IRC |
| # | 15:55:40 | phasefx | Joe1010988: the procedure takes two arguments, the id of the user to delete, and a secondary user for receiving things that probably shouldn't be deleted, like reports |
| # | 15:56:02 | phasefx | Joe1010988: though with SQL, you can feed that procedure more than 1 user at a time |
| # | 15:56:44 | sal_ has quit IRC |
| # | 15:59:15 | Joe1010988 | phasefx: so I could execute something along the lines of "evergreen=# actor.usr_purge_data(SELECT id FROM actor.usr WHERE deleted=1);"? Sorry for the incessant questions, I haven't been able to dig up any documentation on the actor.usr_purge_data function thus far. |
| # | 16:01:48 | phasefx | Joe1010988: you may be better off just overlaying/replacing the data; how many users are we talking? |
| # | 16:02:11 | Joe1010988 | Or given the two-parameter header: "actor.usr_purge_data(SELECT id FROM actor.usr WHERE deleted=1, 1);" to delete all flagged accounts and apply un-deletable items to the admin account? |
| # | 16:02:42 | phasefx | select actor.usr_purge_data(id,1) from actor.usr where deleted = 't'; |
| # | 16:02:54 | eeevil | Joe1010988: select actor.usr_purge_data(id,1) from actor.usr where deleted; -- but I'd urge you to confirm that all deleted=true rows really should go away |
| # | 16:03:08 | eeevil | through close inspection |
| # | 16:13:00 | Joe1010988 | phasefx: around 900 accounts were in their test import. They just imported the student accounts as a test during a tutorial, no operations or rentals have been applied to those accounts so, as far as I can see, nothing's propagated outside actor schema's usr, usr_address, card, and usr_setting tables. I've backed up the entire database already so I guess we'll see what happens. Thanks for getting me started in the right direc |
| # | 16:14:28 | Joe1010988 | and just to split that up, thanks to jeff and eeevil for your advice as well! |
| # | 16:17:56 | sfortin has quit IRC |
| # | 16:30:17 | Joe1010988 has quit IRC |
| # | 17:00:15 | akilsdonk has quit IRC |
| # | 17:08:09 | blongwel | Is there a way to delete older offline sessions within the staff client (version 2.1)? |
| # | 17:09:31 | phasefx | you can do it from the file system. We should probably make an interface or menu option for purging old archived transaction logs |
| # | 17:10:10 | bshum | Hmm, there's no easy way to exclude a specific subset of libraries from an asset.stat_cat setup at consortium level is there? :S |
| # | 17:10:13 | phasefx | actually, two different things I'm thinking of.. you have the archived files on the local workstation, but you're probably talking about old sessions on the server listed in the offline admin interface? |
| # | 17:11:48 | blongwel | phasefx: Yes to the old sessions in offline transaction management. Some sites use for bookmobile transactions. |
| # | 17:13:01 | phasefx | I'm not sure what to do there |
| # | 17:13:26 | phasefx | long term, rather than delete them, should probably have the interface only show the 10 most recent completed sessions |
| # | 17:14:15 | phasefx | grabbing 0606 |
| # | 17:14:52 | gmcharlt | only 60 more to go |
| # | 17:15:09 | bshum | gmcharlt++ :) |
| # | 17:15:33 | blongwel | phasefx: that would help with the congestion at least |
| # | 17:23:19 | dbs has quit IRC |
| # | 17:25:19 | raynerj has left #evergreen |
| # | 17:31:31 | dbs has joined #evergreen |
| # | 17:40:52 | yboston has quit IRC |
| # | 17:47:00 | edoceo has joined #evergreen |
| # | 17:53:08 | edoceo has quit IRC |
| # | 18:14:47 | csharp | just a suggestion about the example opensrf_core.xml: replace "password" (which is only a placeholder anyway) with something sed-able - just when someone gets the itch ;-) |
| # | 18:15:46 | tsbere | csharp: For OpenSRF, Evergreen, or both? ;) |
| # | 18:15:54 | csharp | tsbere: both! |
| # | 18:16:32 | tsbere | (and to be really sedable, should probably be some set of things like "rpubpass", "rpripass", "opubpass", and "opripass" for the router and opensrf public and private passwords) |
| # | 18:16:35 | dbs | so, four different sed-able things? |
| # | 18:16:41 | dbs | right, what tsbere said |
| # | 18:17:23 | csharp | I see - I guess I just use a single password for all four, so that's why I'm thinking that way |
| # | 18:17:49 | csharp doesn't see a good reason to make it more complicated than that ;-) |
| # | 18:19:12 | tsbere | well, with my method there, your regex is slightly more complicated. Still sedable all to one. /[or]p(ub|ri)pass/ or similar (can never remember when to backslash some of the pieces) |
| # | 18:20:07 | csharp | I guess if someone hacks far enough down to get to my OpenSRF/Router password, it probably won't matter if I chose different ones for each network/password |
| # | 18:20:11 | csharp | tsbere: true |
| # | 18:20:45 | tsbere used pwgen to generate 4 passwords |
| # | 18:21:39 | tsbere | As a side bonus, if I want to ensure something is never using the "private" stuff I just don't tell that server the private passwords |
| # | 18:21:48 | csharp | tsbere: nice tip - I've never used that before |
| # | 18:22:23 | tsbere | With 4 sedable passwords a really simple shell script could be written to register the four accounts *and* install the passwords |
| # | 18:22:35 | tsbere | With all 4 passwords pulled from pwgen |
| # | 18:22:57 | csharp chuckled at this recently: http://xkcd.com/936/ |
| # | 18:23:28 | tsbere | Actually, if I recall, only need two sedable strings. One for public, one for private. Routers and Opensrfs use different XML tags. |
| # | 18:24:01 | tsbere | Hmmm |
| # | 18:24:33 | tsbere | Might a better solution be to put a <!--Private--> or <!--Public--> comment on the same line as the password? Then you can sed in a new password without knowing the current value. |
| # | 18:24:49 | csharp | tsbere: nice idea |
| # | 18:40:47 | edoceo has joined #evergreen |
| # | 18:45:30 | dbs | as long as the XML comment nodes don't introduce subtle errors into the various config-parsing tools in C, Perl, Python, Java |
| # | 18:45:50 | tsbere | dbs: Given that the stock config files contain comment nodes I don't think we will have an issue |
| # | 18:46:04 | dbs | tsbere: I speak from experience with opensrf.xml |
| # | 18:46:24 | tsbere wonders what issues exist, then |
| # | 18:46:52 | tsbere | So long as our comments don't contain -- as part of the comment I don't think there would be an issue |
| # | 18:46:53 | dbs | I believe we've taught the core parsers to filter out XML comment nodes, but it would be wise to double-check |
| # | 18:47:00 | dbs | whatever |
| # | 18:47:09 | tsbere has had issues with XML and comments with embedded -- |
| # | 18:47:19 | dbs | right. standard issue |
| # | 18:47:40 | dbs is sure tsbere is right, wonders why he bothers talking at all |
| # | 18:49:53 | tsbere | dbs: I am curious as to what issues may or may not exist with all the comments in the example files. I understand that sometimes parsers have issues, but I find it hard to believe the ones we have do when we fill the examples with comments. Then again, weirder things have happened. |
| # | 18:50:22 | tsbere only thought about using comments as he was staring at some in opensrf_core.xml to begin with |
| # | 18:53:05 | dbs | there's one: http://svn.open-ils.org/trac/OpenSRF/changeset/2054/trunk/src/python/opensrf.py |
| # | 18:54:24 | dbs | another: http://www.open-ils.org/irc_logs/openils-evergreen/2009-07/%23openils-evergreen.08-Wed-2009.log |
| # | 18:55:13 | dbs | anything that iterates over the nodes in an XML document and doesn't check to ensure that it's not dealing with an XML comment node, basically |
| # | 18:57:17 | tsbere | Come to think of it, I seem to recall dealing with parsers that treat the whitespace between nodes as nodes for iteration as well. :( |
| # | 19:03:11 | tsbere is trying to figure out what has gone wrong since he restarted things friday to cause random system failures |
| # | 19:06:34 | tsbere | And great....the system crashed and nothing will start again. |
| # | 19:06:53 | tsbere dislikes when this kind of thing happens at random on a production system |
| # | 19:21:21 | tsbere | One log file ate up the entire disk... |
| # | 19:27:09 | blongwel has quit IRC |
| # | 20:17:37 | hopkinsju_ has joined #evergreen |
| # | 20:19:32 | fredericdem has joined #evergreen |
| # | 20:19:43 | phasefx__ has joined #evergreen |
| # | 20:22:29 | phasefx has quit IRC |
| # | 20:22:29 | dkyle has quit IRC |
| # | 20:22:32 | fredericd has quit IRC |
| # | 20:22:32 | hopkinsju has quit IRC |
| # | 20:23:19 | dkyle has joined #evergreen |
| # | 20:43:13 | Manderson | So, I am seeing this when trying to run eg_db_config.pl: http://pastebin.com/FdHBs2aD |
| # | 20:43:56 | Manderson | I think I might have missed something...or something got uninstalled. Anyone have any ideas what it might be? |
| # | 20:47:04 | dbs | Manderson: you're running with postgresql 9.0. Hit Enter |
| # | 20:47:51 | dbs | Evergreen 2.0.x didn't officially support 9.0 when it was first released, but now many sites are running 9.0 |
| # | 20:48:11 | dbs | eeevil: probably good to backport the 2.1 9.0 FTS config to 2.0 for 2.0.9 for that purpose |
| # | 20:48:16 | Manderson | version says 8.4.8 |
| # | 20:49:00 | Manderson | I gather it's just a general warning? |
| # | 21:07:59 | dbs | mmm |
| # | 21:08:15 | dbs | that seems weird |
| # | 21:09:06 | Manderson | It might be a postgresql dependency that has the newer version... |
| # | 21:09:32 | Manderson | I've been dinking around trying to get Evergreen installed after discovering 2.0.8 was borked. |
| # | 21:10:10 | Manderson | The Makefile.install would uninstall postgresql, so I'd have to go and re-install...kind of a pain in the butt. |
| # | 21:11:08 | dbs | What version of Evergreen are you installing? |
| # | 21:11:33 | dbs | If it's 2.1, then it's looking for PostgreSQL 9.0 |
| # | 21:12:08 | dbs | which is why it wouldn't be happy about 8.4.8 |
| # | 21:15:58 | Manderson | Oh...I think that might be why |
| # | 21:16:08 | Manderson | I am working from git. |
| # | 21:16:10 | Manderson | I checked out master. |
| # | 21:16:45 | Manderson | That's the 2.1 branch, isn' |
| # | 21:16:50 | Manderson | isn't it? |
| # | 21:18:21 | dbs | it's slated to be 2.2, actually, but shares many similarities with 2.1, including a minimum of postgresql 9.0 |
| # | 21:18:53 | Manderson | Well, crap |
| # | 21:18:55 | Manderson | :S |
| # | 21:18:56 | Manderson | thanks |
| # | 21:18:59 | Manderson | :D |
| # | 21:20:58 | dbs | Yeah. Sorry for the pain; that's why the Makefile.install uninstalls PostgreSQL on systems that have 8.x installed, for what it's worth, as 9.0 is required - there is a bug open with some ideas about how to make it more polite (like: warning you first) |
| # | 21:22:13 | Manderson | It's alright...I appreciate it...this is a learning process for me. |
| # | 21:23:32 | dbs | it's a continual learning process for all of us |
| # | 21:23:59 | Manderson | Just checked out the latest from the 2.0 branch...this is already running MUUUCH smoother. |
| # | 21:24:09 | Manderson | thanks |
| # | 21:28:49 | dbs | good! |
| # | 21:28:54 | dbs | 2.0.9 should be just around the corner |
| # | 22:36:36 | phasefx__ is now known as phasefx |
| # | 23:13:17 | edoceo has quit IRC |
| # | 23:25:30 | mrpeters-isl_ has joined #evergreen |
| # | 23:26:18 | mrpeters-isl_ | anyone 'live and kickin and have experience with Slony? |
| # | 23:26:59 | mrpeters-isl_ | not sure why this is trying to create a trigger that already exists -- http://paste.lisp.org/display/124193 |
| # | 23:48:12 | jamesrf has quit IRC |
| # | 23:50:02 | jamesrf has joined #evergreen |
April 10-13