Time |
Nick |
Message |
01:36 |
|
Mark__T joined #evergreen |
04:22 |
|
gmcharlt joined #evergreen |
04:38 |
|
gmcharlt joined #evergreen |
05:04 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
05:49 |
|
bmills joined #evergreen |
08:01 |
|
krvmga joined #evergreen |
08:02 |
|
rjackson_isl joined #evergreen |
08:08 |
|
ericar joined #evergreen |
08:11 |
|
mrpeters joined #evergreen |
08:35 |
|
Dyrcona joined #evergreen |
08:38 |
|
mixo joined #evergreen |
08:38 |
mixo |
hellow |
08:43 |
mixo |
I've imported evergreen in ampty evergreen database with commands "pg_dump -Fc -a evergreen > evergreen.dump" from old database to new with "pg_restore --disable-triggers -d evergreen evergreen.dump" |
08:43 |
mixo |
what is downside of this method |
08:45 |
|
Shae joined #evergreen |
08:47 |
Stompro |
mixo, I believe that you also need to set the schema search path once you restored the data... let me find info. |
08:51 |
Stompro |
mixo, see http://goo.gl/pp45hH, line 16 needs to be re-run once you have restored since that just sets a database setting, it isn't part of the schema. |
08:52 |
mixo |
thank you |
08:52 |
Stompro |
I haven't done a restore yet, so I don't have any other tips. I think we should have a chapter in the documentation, I'll add it to the todo list. |
08:53 |
Stompro |
I mean, I think a chapter for backups and restores should be added to the docs, not that I think there is one now. |
08:55 |
Dyrcona |
I do similar restores "all the time" an resetting the path is about the only gotcha. |
08:55 |
Dyrcona |
s/an/and/ |
08:56 |
Dyrcona |
You will sometimes see errors in the restore if your versions of postgres are different. |
08:56 |
Dyrcona |
What I typically see going from 9.1 to 9.3 are about 27 messages about not being able to lock resources, but they are harmless. |
08:57 |
|
akilsdonk joined #evergreen |
08:59 |
tsbere |
For note: Resetting the path is only a gotcha if you aren't doing an *entire server* restore. We do single database restores so it is an issue. |
09:05 |
mixo |
after restor data in the database is not searchable |
09:08 |
mixo |
there are errors in postgresql logs about duplicate key and about relation from database of old version |
09:08 |
mixo |
but rest of data is imported |
09:09 |
Dyrcona |
mixo: Are you restoring on top of the existing evergreen database? |
09:10 |
mixo |
yes, I restore only data on top of existing empty database of a new version |
09:11 |
Dyrcona |
mixo: Are you running the dump and restore commands you posted above against the same postgresql server? |
09:12 |
mixo |
no |
09:13 |
mixo |
new database and evergreen installation are in another server |
09:13 |
Dyrcona |
Duplicate key errors point to invalid data in the original data. |
09:13 |
mixo |
old version of postgresql was 9.2 |
09:13 |
mixo |
ne 9.4 |
09:14 |
Dyrcona |
Possibly data that pre-exists adding of constraints. |
09:14 |
mixo |
no dublicate data errors occure only on default values |
09:14 |
Stompro |
mixo, did you already run eg_db_config on the new server? |
09:14 |
|
maryj joined #evergreen |
09:14 |
mixo |
aof evergreen installation |
09:16 |
Dyrcona |
mixo: When I do dumps and restores, I don't run eg_db_config before doing the restore. |
09:16 |
mixo |
yes, when i were installing new version of evergreen and its database |
09:16 |
Dyrcona |
mixo: I restore the whole database, schema and all. |
09:17 |
Stompro |
mixo, yah, you need to start with a completely empty database and restore into that. Your restore is trying to duplicate info that the eg_db_config --create-database --create-schema already created. |
09:18 |
Stompro |
Are you trying to upgrade evergreen versions at the same time also? |
09:21 |
mixo |
two years ago I've updated evergreen but I sink I did some mistakes. evergreen works, but when I try update database there are some columns missing in a few tables |
09:22 |
mixo |
because of this I deside to do such desigion |
09:25 |
Stompro |
mixo, it won't work like that. Once you restore, before you start up evergreen, you need to go through the schema upgrade process to upgrade to the version you are at. And you will need to deal with the missing columns also. |
09:26 |
Stompro |
mixo, you will need to find which updates you missed and get those issues fixed. |
09:27 |
Stompro |
mixo, do you have a support contract with anyone? |
09:27 |
mixo |
no |
09:28 |
Bmagic |
jeff: yeah, I believe I have found some |
09:29 |
mixo |
Ok, thank you for suggestions. Old evergreen works and I have time to find this mistake |
09:30 |
Stompro |
You can try searching the schema updates dir for the columns that are missing, to see which updates might have been missed. And then you can try to apply those updates. Open-ILS/src/sql/Pg/upgrade |
09:32 |
Dyrcona |
Stompro: mixo's problem was loading into a created/schema-fied database. |
09:32 |
Dyrcona |
I don't think mixo was actually missing any updates once I realized that. |
09:33 |
Dyrcona |
People should be more patient.... |
09:35 |
Stompro |
Dyrcona, I was just going off of his comment about "two years ago I updated evergreen but I think I did some mistakes..." I read that to mean he has already tried the traditionaly route, and was trying this restore over new version method. |
09:37 |
Stompro |
His IP was from Georgia, the country. That is pretty cool. |
09:38 |
Dyrcona |
Yeah. mixo has been around before. |
09:54 |
Stompro |
I have a memory of someone sharing a link to an example of an html A/T notice template, but I cannot seem to find it. Does anyone know of such an example? |
10:09 |
Dyrcona |
hmm. Pub date sorting doesn't sort by what I thought it sorted by. |
10:10 |
Dyrcona |
I'm surprised no one has complained to me about it. |
10:19 |
Stompro |
There is a bug for that.. lp 1470957 is that the issue you are talking about? Or something else. |
10:19 |
pinesol_green |
Launchpad bug 1470957 in Evergreen 2.8 "Items are incorrectly sorting when using the Sort By Publication date feature" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1470957 |
10:25 |
Dyrcona |
Stompro: I was looking into that bug when I made that remark. |
10:25 |
Dyrcona |
It sorts by date1, which isn't visible in the result summary. |
10:26 |
Dyrcona |
So, I've got records sorting 2015, 2014, 2013, 2014, as so on, going by the pub date in the 264. |
10:26 |
Dyrcona |
'Cause the date1 for the 2013 record is 2014. |
10:31 |
Dyrcona |
That seems to violate the principle of least surprise. |
10:33 |
bshum |
Oh mixo is from Georgia? I thought they were the ones from Mexico. Oops. |
10:33 |
jeff |
Dyrcona: MARC does not subscribe to the princible of least surprise. |
10:34 |
jeff |
OR the principle. |
10:34 |
jeff |
a princible is what you melt down your principles in. |
10:34 |
Dyrcona |
jeff: There is a pub date that is visible to the user that could be used for sorting. Evergreen [sic] makes the choice to sort on date1. |
10:38 |
bshum |
Dyrcona: Maybe in the README, this line could be altered slightly: To install Postgres server packages, use the make target postgres-server-<OSTYPE>. |
10:38 |
jeff |
yeah. iirc and without looking, evergreen is sorting based on one of the record attributes that is extracted at ingest time. i don't think that the value displayed to the user is one of those attributes, because it's being extracted from the marcxml at display time. |
10:38 |
bshum |
To be like "to install Postgres server packages and related perl dependencies" |
10:39 |
bshum |
In the old days, we used to use more specific language like "standalone database" steps or something. And some remnants of that remain, but I guess clarification doesn't hurt. |
10:39 |
jeff |
so, the two values being different may be for reasons of MARC, but I agree that we should be consistent with regard to what is sorted on and what is displayed. |
10:39 |
Dyrcona |
bshum: I think it may be useful to add a section describing what packages need installation on a standalone db server. |
10:39 |
bshum |
Dyrcona: We used to list all the packages separately, but given that they're all in the makefile, I think we stopped listing any that didn't require hand installation outside of the target. |
10:40 |
Dyrcona |
jeff: There's also no reason that the visible pud date could not be indexed an used for sorting, either, but I'm not volunteering just yet. :) |
10:41 |
Dyrcona |
s/pud/pub/ heh. |
10:51 |
|
jwoodard_tablet joined #evergreen |
10:53 |
* jeff |
nods |
11:03 |
Dyrcona |
Stompro: You have working repo access, now, don't you? |
11:03 |
Dyrcona |
Stompro: I'm asking if you want to add an actual sign-off on dd3e7e4b4f85a48642d5aa296d0a5c7d7dffaa8e |
11:03 |
Dyrcona |
commit dd3e7e4b4f85a48642d5aa296d0a5c7d7dffaa8e |
11:04 |
Dyrcona |
Oh, doesn't work from working, does it..... |
11:04 |
Dyrcona |
Stompro: In comment #4 of lp 1361266 you said you consented to signing off. |
11:04 |
pinesol_green |
Launchpad bug 1361266 in Evergreen 2.8 "Patron self-registration form accepts date of birth in wrong format" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1361266 |
11:05 |
Stompro |
I do, I was just lazy during the last bug fixing day and hadn't started doing that yet. I will go and add a sign off branch. |
11:05 |
jeff |
yeah, git hashes in working aren't handled by pinesol_green at present. |
11:06 |
Dyrcona |
Stompro: Cool, if you could add a sign off and share the branch, I'll merge that ASAP. :) |
11:06 |
jeff |
it might be something we could enable -- especially if we can enable parsing of commit hash without ALSO announcing commits (because that would be overkill) |
11:06 |
Dyrcona |
Yeah, that would be overkill for working. |
11:07 |
* Dyrcona |
listens to NSFW music while @ W. |
11:07 |
|
krvmga joined #evergreen |
11:24 |
mrpeters |
my dog doesnt seem to mind NSFW music at work :P |
11:25 |
Dyrcona |
:) |
11:28 |
miker |
berick: I'm in a maze of twisty passages, all alike ... looking for whether the full JS fieldmapper API from dojo was ported to angular. in particular, fieldmapper.clone() |
11:29 |
Dyrcona |
miker is eaten by a Grue. |
11:29 |
Dyrcona |
;) |
11:29 |
Stompro |
Dyrcona, signoff branch added to lp 1361266 |
11:30 |
pinesol_green |
Launchpad bug 1361266 in Evergreen 2.8 "Patron self-registration form accepts date of birth in wrong format" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1361266 |
11:30 |
Dyrcona |
Stompro++ |
11:30 |
* Dyrcona |
is in the land of Vandelay at the moment. |
11:30 |
miker |
Dyrcona: it's dark in here... |
11:30 |
Dyrcona |
miker: Try light torch. |
11:30 |
dbs |
Dyrcona++ |
11:31 |
miker |
turn north |
11:31 |
miker |
pick up spleen |
11:33 |
jeff |
GET LAMP |
11:33 |
dbs |
jeff++ |
11:39 |
jeff |
245 0 0 ‡aGet lamp ‡h[videorecording] / ‡ca film by Jason Scott. |
11:39 |
Dyrcona |
jeff++ |
11:40 |
jeff |
260 . ‡aUnited States : ‡bBovine Ignition Systems ‡cc2010. |
11:41 |
jeff |
500 ‡aDisc 2. Special features: music video by MC Frontalot, "It is pitch dark;" dvd-rom section with games, photos; commentary tracks. |
11:41 |
jeff |
[said music video having been shot in Jason's basement] |
11:41 |
Stompro |
When the hold targeter is run, will it choose a closer/better target, even if the current target is still a match? Or does it stick with a targeted copy until that copy gets captured or it's status changes? |
11:43 |
jeff |
NOT AUTHORITATIVE: until time of capture, nothing that i'm aware of prevents ahr.current_copy from being replaced with a "better" current_copy during targeting. |
11:44 |
* Dyrcona |
agrees with jeff. |
11:47 |
Stompro |
jeff, Dyrcona thanks, I just wanted to make sure. With soft stalling, it seems to me that if a better copy gets checked in, one that has a closer proximity than the targeted copy, then after a day that copy would get targeted. So even though it wasn't captured oportunistically, it would fill the hold the next day if possible. |
11:48 |
pinesol_green |
[evergreen|Bill Erickson] LP#1472380 Display all Vandelay authority matches - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=17082b6> |
11:48 |
Dyrcona |
It could happen without stalling, too, depending on checkin modifiers. |
11:49 |
* miker |
adds service.Clone |
11:51 |
|
bmills joined #evergreen |
11:54 |
pinesol_green |
[evergreen|Michael Peters] LP#1361266 Patron self-registration form accepts date of birth in wrong format - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=48b7fab> |
12:01 |
|
HomebrewCocaine joined #evergreen |
12:02 |
HomebrewCocaine |
Good morning everyone |
12:03 |
HomebrewCocaine |
I have a few questions about Evergreen if anyone is available |
12:04 |
jeff |
ask away! many can answer! |
12:05 |
dbs |
o.O |
12:05 |
dbs |
.oO what a nick |
12:06 |
HomebrewCocaine |
Fantastic. I was curious, if this software was able to be used to also catalog artifacts and antiquities. I am a Freemason who is in charge of our Lodge's library and along with it, the Photos, Records, and Artifacts that also come along with it. My goal is to find a system that allows me to not only be able to loan books to the many people who have an interest in the craft from our Lodge, but to also inventory what we do have |
12:06 |
HomebrewCocaine |
for historical documents that may not be specifically book related. |
12:07 |
HomebrewCocaine |
dbs, My daily vocation is as a Sysadmin. I used to brew beer in my spare time, and I have ADHD. Ritalin and Cocaine have a HIGHLY similar chemical makeup. Hence. HomebrewCocaine :D |
12:08 |
|
sandbergja joined #evergreen |
12:10 |
|
jwoodard_tablet joined #evergreen |
12:10 |
dbs |
HomebrewCocaine: Evergreen probably isn't the best software for that purpose, unless you or someone in your org is familiar with the MARC21 format |
12:12 |
* dbs |
tries to remember the software that is somewhat like Greenstone, also developed in New Zealand, but not Koha |
12:12 |
HomebrewCocaine |
dbs, As a primarily library software though, if I was to find something else to manage the Photos and Records, is it okay with books that may not have gone into wide circulation? For example, we have hand bound books that were written 100+ years ago in our collection that were probably not worked through a publisher. |
12:12 |
|
jihpringle joined #evergreen |
12:13 |
HomebrewCocaine |
But we would still want to be able to loan to the long standing members. (They are a tad bit more delicate with them than the younger guys) |
12:14 |
dbs |
HomebrewCocaine: sure, you can describe everything (old books, photos, etc) |
12:15 |
HomebrewCocaine |
dbs, Fantastic. I did fine one other piece of software that would probably work for the Artifact archival process |
12:15 |
HomebrewCocaine |
find** |
12:16 |
dbs |
But whoever is describing it has to do things like 245 $a Title of item $b Subtitle / 100 $a Author name / 007 vd cvaiz |
12:16 |
HomebrewCocaine |
It will most likely be me handling any of the older books |
12:16 |
dbs |
And Evergreen is a big chunk of software with a lot of moving parts |
12:16 |
HomebrewCocaine |
And documenting it |
12:17 |
HomebrewCocaine |
And crying |
12:17 |
HomebrewCocaine |
Lots of crying |
12:17 |
dbs |
hah |
12:17 |
HomebrewCocaine |
Again, I work in IT. I know the drill :) |
12:17 |
maryj |
HomebrewCocaine: Do you have an estimate of how many items that you have in your Lodge's library? |
12:17 |
dbs |
koha (http://koha-community.org) is an easier-to-install alternative that wasn't strictly bound to MARC, at least once upon a time, that might be a good place to start |
12:18 |
maryj |
dbs++ |
12:18 |
HomebrewCocaine |
maryj, At least 400 items. There are likely more that will be found as time goes on. |
12:19 |
HomebrewCocaine |
And it is possible that once we start archiving, that the other groups that meet in our building (Other lodges and apendant bodies) will try to get in on our library system to get their stuff inventoried. |
12:19 |
HomebrewCocaine |
We have about 12-13 other groups with at least as much stuff as we have. |
12:22 |
jeff |
poor patron. hit by two different SIP issues. |
12:23 |
phasefx |
dbs: re: greenstone, was it kete? |
12:24 |
maryj |
Homebreocaine: An open source archives platform - Archivematica https://www.archivematica.org/en/ - is more intense than what you seem to be looking for and that system does not allow for circulation (see example implementation: http://jewishmuseum.ca/archives/) |
12:24 |
maryj |
I would go with dbs ' suggestion for Koha as well. It would give you some flexibliity for your collection and the possibility of other lodges joining. |
12:25 |
HomebrewCocaine |
Thank you all so much! |
12:28 |
jeff |
alas, é continues to be a pain |
12:29 |
jeff |
is 245 $a English Title = $b Not English Title common cataloging practice? |
12:34 |
jeff |
okay, looks at least close to being an ISBD "parallel title" |
12:36 |
dbs |
phasefx++ |
12:36 |
dbs |
kete it was |
12:40 |
* jeff |
is once again reminded how frustrating it is that neither marc nor isbd seem to acknowledge each other in any way, shape, or form. :P |
12:41 |
jeff |
at least, not in the places i look. :P |
12:50 |
Dyrcona |
MARC at least acknowledges ISBD with an indicator here and there. |
12:50 |
Dyrcona |
As far as punctuation is concerned. |
12:50 |
* Dyrcona |
realizes jeff's opine was deeper than that. |
12:51 |
jeff |
taking more cataloging classes might help, but might also just properly equip me to argue with someone who took another cataloging class. ;-) |
12:52 |
|
jwoodard_tablet joined #evergreen |
12:53 |
Dyrcona |
@dunno |
12:53 |
pinesol_green |
Dyrcona: No, you're a puzzleheaded kraken! |
12:53 |
Dyrcona |
meh. i think we should switch to free text and natural language parsers. :) |
12:54 |
* jeff |
thinks bad things about MARC and SIP2 while looking around for a PDF of a standard which has fields that remind him a lot of SIP2 |
12:55 |
jeff |
probably would be easier to find if i remembered the name of the pdf or even the name of the standard. :P |
12:56 |
jeff |
ooh, just like that -- remembered the name of one of the fields. |
12:56 |
jeff |
"inventory control number" turned up only a single pdf in spotlight :-) |
12:57 |
Dyrcona |
jeff: Have you tried Z39.83 rev. 2 part 1? |
12:58 |
* Dyrcona |
pronounces it "zed." |
12:58 |
dbs |
AS IT SHOULD BE! |
12:58 |
|
jwoodard_tablet joined #evergreen |
12:58 |
dbs |
Dyrcona++ |
12:58 |
Dyrcona |
dbs++ |
13:09 |
|
rlefaive joined #evergreen |
13:15 |
|
yboston joined #evergreen |
13:29 |
pgardella1 |
When looking at osrfsys.log, is there a way to trace a single process through the log? Does the 3477 identify that process number in this string? [INFO:3477:CStoreEditor.pm:139:1441373638338410] |
13:31 |
|
bmills joined #evergreen |
13:32 |
|
bmills1 joined #evergreen |
13:33 |
jeff |
depending on what you are trying to do, you'll find the trace value 1441373638338410 more useful. |
13:33 |
Dyrcona |
What jeff said.... |
13:33 |
pgardella1 |
jeff++ |
13:34 |
pgardella1 |
Good to know. I'm trying to debug why password resets are not being sent. So I'm trying to dig through the logs to find only the stuff that deals with that request. |
13:43 |
pgardella1 |
I'm using helpers.get_org_setting(user.home_ou, 'org.bounced_emails') in the A/T template. Does user.home_ou get fleshed out in the flesh_user method of Actor.pm? |
13:43 |
jeff |
correcting myself... that's an "xid", not a "trace", if we're trying to be exact. |
13:43 |
pgardella1 |
xid being transaction id? |
13:44 |
Dyrcona |
pgardella1: It depends. If the $home_ou parameter is true, then it will be. If false, then it won't. |
13:45 |
jeff |
originally defined as ``a transaction string that's passed around via the jabber message and inserted into each logged message to relate activity accross different processes'' |
13:45 |
pgardella1 |
Dyrcona: OK. But that's the code that is called? |
13:45 |
pgardella1 |
jeff++ |
13:46 |
Dyrcona |
pgardella1: I don't know where your usr.home_ou is coming from, so I can't say if it is fleshed or not. |
13:47 |
pgardella1 |
Dyrcona: I don't know where it's coming from either :) That's my question. |
13:48 |
Dyrcona |
pgardella1: Chances are that it is, but without looking at the context around the code you've posted, I can't say for sure. |
13:48 |
tsbere |
pgardella1: The environment of the event def will define what is fleshed out |
13:48 |
jeff |
and in the original example of INFO:3477:CStoreEditor.pm:139:1441373638338410, INFO is the log level, 3477 is the process ID, and 139 is the line number of CStoreEditor.pm where the logging call is being made. |
13:48 |
* jeff |
is being verbose without being directly helpful to the problem at hand |
13:49 |
tsbere |
pgardella1: If there is any environment entry for the def that includes home_ou then that becomes an object and the template needs to refer to home_ou.id instead |
13:49 |
Dyrcona |
Another about xids: They change when an OpenSRF call is made. |
13:49 |
Dyrcona |
If the call you're tracing makes another call, that second call gets its own xid. |
13:49 |
* jeff |
nods |
13:50 |
Dyrcona |
Yeah, what tsbere said. |
13:50 |
Dyrcona |
;) |
13:50 |
pgardella1 |
Dyrcona++ |
13:50 |
Dyrcona |
tsbere++ |
13:50 |
pgardella1 |
jeff+ |
13:50 |
pgardella1 |
jeff++ |
13:51 |
pgardella1 |
tsbere++ |
13:53 |
pgardella1 |
tsbere: Ah! OK. So the [%- user = target.usr -%] is the environment entry? |
13:53 |
tsbere |
pgardella1: No. |
13:53 |
* tsbere |
opens the interface he wants quick |
13:54 |
pgardella1 |
Sigh. I'll get this one of these days. |
13:54 |
tsbere |
pgardella1: When you click on the *name* (instead of double-click on the *row*) you get "Event Environment", "Event Paramters", and "Test" tabs |
13:55 |
tsbere |
pgardella1: The environment entries there control what is "fleshed" off of the base object |
13:55 |
pgardella1 |
OK. |
13:55 |
tsbere |
pgardella1: So "usr" means "flesh usr". "usr.profile" would be "flesh usr, then flesh profile on usr" |
13:56 |
tsbere |
pgardella1: If you have "usr.home_ou" or deeper them home_ou is fleshed off of usr. If you just have "usr" but no "usr.home_ou" then home_ou will remain an id only. |
13:58 |
tsbere |
pgardella1: An another example of things, if you have "usr.home_ou.billing_address" then you don't need another entry for "usr.home_ou" as the "deeper" one will cause those above it to be fleshed anyway |
13:59 |
pgardella1 |
tsbere++ |
14:00 |
pgardella1 |
tsbere: OK. So it has both usr and usr.home_ou in the Environment |
14:00 |
tsbere |
pgardella1: Well, the usr one isn't needed, but isn't hurting anything. That does mean you need the .id when using home_ou though. |
14:00 |
tsbere |
(at least for the helpers.get_org_setting function) |
14:02 |
pgardella1 |
tsbere: Does the [%- user = target.usr -%] in the template change the scope of the variable user? Meaning should I use usr.home_ou.id in the helpers.get_org_setting instead of user.home_ou.id? |
14:03 |
tsbere |
pgardella1: that is just variable, making it so you can type user instead of target.usr. Thus user.home_ou.id would be what you want, or target.usr.home_ou.id if you want the long way. |
14:07 |
pgardella1 |
tsbere: Using user.home_ou.id results in an error: Trigger template lib: undef error - Can't use string ("") as an ARRAY ref while "strict refs". |
14:07 |
pgardella1 |
which is very similar to the problem I was getting with the user.home_ou (resulting in a null) |
14:07 |
pgardella1 |
that seems like it points to a problem with the user |
14:08 |
tsbere |
pgardella1: Perhaps there is more than one problem with the template. |
14:08 |
* tsbere |
can't see the template to tell ;) |
14:08 |
pgardella1 |
:) |
14:12 |
Dyrcona |
Fire alarm. Back later, maybe. |
14:21 |
pgardella1 |
tsbere: sigh. I went back to the default password.reset_request template which didn't work three days ago, when I changed it to use the helper.get_org_settings to try to fix it. Now it works. |
14:21 |
pgardella1 |
tsbere++ |
14:37 |
* tsbere |
returns from the fire alarm Dyrcona mentioned |
14:47 |
|
Dyrcona joined #evergreen |
14:57 |
|
jwoodard_tablet joined #evergreen |
15:12 |
jeff |
pgardella1: perhaps the problem was never with your template, and was something else that you've since fixed in this process, but you also broke the template during that troubleshooting process. :-) |
15:13 |
Dyrcona |
yeah, that happens..... |
15:19 |
pgardella1 |
jeff: Very likely. I set a bunch of settings "just to be safe". |
15:26 |
rjackson_isl |
added LP 1492434 which should be a wish list most likely... |
15:26 |
pinesol_green |
Launchpad bug 1492434 in Evergreen "Add balanced_owed macro to checkout receipt" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1492434 |
16:18 |
|
serflog joined #evergreen |
16:18 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
16:40 |
Stompro |
I'm trying to understand what the point of sorting by approx, then pprox, then aprox is for the traditional best-hold selection sort order? What does using 3 proximity sorts get you? approx should contain everything from pprox + adjustments, so why use both? |
16:41 |
tsbere |
Stompro: Not all the prox checks do so comparing to the same things |
16:43 |
tsbere |
We have the proximity to the copy circ lib first, then the proximity to the checkin library. Thus it will go home first, but if the home system doesn't need it then it will try the checkin system next. |
16:49 |
Stompro |
Are you talking about approx? That takes into account copy circ lib? Does the term Adjusted in approx and aprox have anything to do with the org unit proximity ajustments? |
16:54 |
tsbere |
I don't recall which is which. I just know how we are configured. |
17:08 |
|
TaraC joined #evergreen |
17:08 |
|
bmills joined #evergreen |
17:15 |
|
yboston_ joined #evergreen |
17:37 |
|
jwoodard_tablet joined #evergreen |
19:05 |
|
jwoodard_tablet joined #evergreen |
19:23 |
|
bmills joined #evergreen |
20:15 |
kmlussier |
bshum: https://goo.gl/photos/HmQubXU7ZoJ8hvBk6 |
20:19 |
miker |
kmlussier: that cat has problems... |
20:19 |
kmlussier |
miker: He's been through a lot of wear and tear over the years. |
20:20 |
miker |
:) |
20:46 |
|
bmills joined #evergreen |
20:48 |
|
b_bonner left #evergreen |
22:00 |
|
jwoodard_tablet joined #evergreen |
23:34 |
|
pgardella joined #evergreen |