Time Nick Message
11:52 owen kados: would you say this bug has been fixed by your recent changes? http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1030
11:35 kados heh
11:35 owen It's got no style :(
11:34 kados yep, chris did it last night
11:34 owen Did Bugzilla get upgraded?
09:27 pierrick OK, I understand, thank you paul
09:26 paul I've added aqbasket in 2.2, to add some DB consistency
09:26 paul I must add that in koha 1.x, aqbasket did not exist & all basket-related lines were duplicated in aqorder
09:25 paul ask katipans ;-)
09:25 pierrick why on earth isn't aqorder called aqbasketline or aqbasket_item? ;-)
09:24 paul yep
09:24 pierrick so one basket has several order lines
09:24 paul it's the "order line"
09:24 paul 1 order is for 1 biblio, right.
09:23 pierrick an aqorder can contain only one biblio?
09:22 paul so the table can't be dropped I think
09:22 paul 1 aqbasket can contain X aqorders. and some infos in aqbasket are only here.
09:22 paul pierrick: why ?
09:21 pierrick can someone explain to me the database model on acquisitions? I don't understand the necessity of aqbasket :-/
09:18 kados or am I sending it to the wrong person? :-)
09:18 kados tumer: yes ... see the private message i sent you?
09:17 tumer kados: are you here
09:06 thd kados: I have not really looked properly at the issue for the eval usage. I can just borrow some code from you modification of bulkmarcimport.pl which does at least work although the structure is different because only MARC data is being added in that case.
09:03 thd paul: that is a migration script that I have been modifying for one of Liblime's customers
09:03 kados paul: just a MARC::Record script that adds holdings data to a batch of MARC records
09:02 paul what is afognak2koha.pl ?
09:01 thd kados: I have had a syntax error from your eval usage in afognak2koha.pl
09:00 thd tumer: I sent you them message for the MARC 21 bibliographic framework
08:49 owen I saw my doctor using a Windows tablet PC running an IE-based web app. I wondered what it was and whether it was cross-browser compatible
08:42 slef tumer: ah, the "you may only use a hammer, no matter what tool is needed" approach
08:42 kados nice
08:42 slef I've got a new server which should help test that... just need to bring it online :-/
08:41 tumer I have to keep on windows cause the university platfor is Windows
08:41 kados slef++
08:41 slef even quicker if we ever get koha.deb
08:41 kados it would save money in licenses and would be more stable
08:41 kados IMO you could very quickly learn some linux skills and convert to linux for your Koha servers
08:40 tumer but unfortunately so popular
08:40 kados so unstable a platform
08:40 tumer kados: it could be!
08:39 tumer kados:yes
08:39 kados i wonder if that's the problem
08:39 kados tumer: you're running on windows, right?
08:39 kados wow
08:39 tumer kados: creating more than 4 sorts slowed down update times and created problems with me.
08:38 kados tumer: could you post your discovery to koha-zebra?
08:38 kados tumer: really!
08:38 tumer kados: I am playing a lot with zebra. Performance issues etc.
08:38 kados tumer: ahh, yes, we can get by without modifying the behaviour of ->encoding() by using as_xml() and new_from_xml(UTF-8)
08:37 kados tumer: which?
08:37 tumer kados: we have bigger issues I believe:)
08:36 kados tumer: that would be ideal :-)
08:36 kados tumer: we could fix MARC::Record so that ->encoding() also fixes encoding
08:35 tumer kados: case dismissed:)
08:35 kados tumer: (though I agree that my expectation of ->encoding() would be to also change the records, but in fact, all it does is change the leader)
08:35 kados tumer: the above code fixes both the leader and the encoding
08:34 kados tumer: a better way is to actually re-encode the records as I posted above
08:34 kados tumer: you are not converting the encoding
08:34 kados tumer: all you are doing with ->encoding('UTF-8') is updating the leader
08:34 kados tumer: (yes it is scary)
08:33 tumer kados: I already looked MARC:charset it is a 350M big file and scary :)
08:32 tumer kados:exactly right. But pre 3.0 data is iso8859. updating database we change everything to utf8. Call MARCgetbiblio you have a record with utf8 data and wrong leader. I was merely trying to correct that problem. Before we do anything else we have to run ->encoding('UTF-8') on all records and update and create zebra etc.
08:30 kados tumer: (I've not had a close look yet, but hope to later this week)
08:30 kados tumer: (if you can figure out how MARC::Charset works perhaps you could add them? :-))
08:29 kados tumer: but if we are missing mappings in MARC::Charset, we will have to update it
08:29 thd tumer: i guess I miss something about what it means to presort two fields over presorting one field created from the two fields
08:29 kados tumer: so internally, everything is utf-8
08:29 kados tumer: my idea is to make sure that Koha converts from 'MARC8' to UTF8 _before_ a record enters the collection
08:28 tumer kados: and only 'UTF-8'
08:27 kados tumer: (at least in rel_2_2 where I have been experimenting with this idea)
08:27 kados tumer: it is also used in the tempaltes
08:27 kados tumer: which can store 'UTF-8'
08:27 tumer thd:I presort on 2 fields and call 2 fields sorted
08:27 kados tumer: called 'TemplateEncoding'
08:27 kados tumer: if you haven't done so already
08:27 kados tumer: you will need to create a new systempreference
08:27 tumer kados: I'll look into this
08:26 thd tumer: how do tow values to sort from at query time have an advantage on that?
08:25 tumer thd: I tried that but a 25 digit long letter or number slows zebra sorting veeeery much
08:24 kados in the other case (where just ->encoding() is used), the leader is lying about the encoding which can be very bad
08:24 kados in that case, $newrecord has proper leader AND encoding
08:24 thd tumer: You need two subfield for the sort but maybe even forming a single value in advance from those two in yet another subfield to use for sorting at query time will be much faster for queries.
08:24 tumer kados: I'seen that
08:24 kados my $newrecord = MARC::Record->new_from_xml($xml, C4::Context->preference('TemplateEncoding'),C4::Context->preference('marcflavour'));
08:23 kados my $xml = $record->as_xml;
08:23 kados tumer: sorry, my paste above is incorrect
08:22 kados tumer: this will change the leader position _AND_ encode the record correctly
08:22 tumer thd: thats why I'll add 2 more fieds to bibioitems to hold these vaues
08:21 kados tumer: my $record=MARC::Record->new_from_xml($xml,C4::Context->preference('TemplateEncoding'),C4::Context->preference('marcflavour'));
08:21 kados tumer: my $xml = MARChtml2xml(\@tags,\@subfields,\@values,\@indicator,\@ind_tag);
08:21 thd tumer: Do the CPU intensive work in a batch process whenever and store a value so that there is much less work to do at query time.
08:21 tumer kados:The new M:F:X requýres this or it assumes MARC-8 even if the record we created is UTF-8
08:21 kados tumer: however, a better way is to do this:
08:20 tumer kados: this one makes sure that the leader of marc record is changed to saying that it is UTF-8. Necessary when moving from 2_2 to 3
08:20 kados tumer: but in fact, all that does is change leader position 9
08:20 thd tumer: The index number number or rather sort number need not be numeric but simply has incorporated all the padding calculations into it.
08:20 kados I agree 100% if you suggest that MARC::Record _should_ be converting the charset
08:19 kados + $record->encoding('UTF-8');
08:19 kados +sensitive to this
08:19 kados + #Change MARC Leader to UTF-8 incase user did not set it.New M::F::XML is
08:19 kados and in Biblio.pm:
08:19 kados + $record->encoding('UTF-8');
08:19 kados tumer: the commits I'm speaking of:
08:19 kados yikes
08:18 tumer Some 2 legged bug tried to squash me. Turned over with the car. I'am OK
08:18 thd tumer: my recommendation for all such performance issues is that you create yet another subfield to store a numeric index number so that the calculation has already been done.
08:18 kados are you ok?
08:18 kados oh no!
08:18 tumer which one. I had a big car accident and in a bit of shock:(
08:18 kados tumer: unfortunately, MARC::Record does not change the actual encoding of the record when you specify ->encoding()
08:17 kados tumer: a comment about your recent commit to HEAD
08:16 tumer thd: I'll commit something and see what you think
08:15 thd tumer: the fine detail of what has precedence when it matters can only be seen by a detailed examination of each of the various classification schedules.
08:14 tumer thd:If we do too much padding zebra slows down on updates
08:14 kados tumer: I will do this
08:14 kados tumer: ok, so we need to tell the maintainers to update M::F::X
08:14 thd tumer: yes much padding required for the best proximate sort.
08:14 tumer kados:LOC web sýte has the chars defined. Like the one I just used
08:13 kados tumer: i also found some native alaskan chars it doesn't handle
08:12 tumer thd:no problem if you pad with 0's and sort textually
08:12 kados tumer: we must investigate whether they can update it
08:12 kados tumer: the mapping is provided by LOC
08:12 thd tumer: Also the classification hierarchy is not strictly numeric after the letter class.
08:12 tumer kados:yes
08:11 kados tumer: are those MARC-8 encoded turkish chars?
08:11 thd tumer: one thing s that the classification number can have elements past the decimal point after the letter class which can cause problems with sorting. Even letters are sometimes present in the classification part before the cutter.
08:11 tumer kados: do you know that this new M:F:X does not convert all the letters to UTF-8. at least 2 turkish chars.
08:07 tumer thd: what other subtler issues with LC?
08:07 kados hi paul
08:06 thd tumer: I have suggested 942 $j and $k with suggestions about usage for your purpose.
08:06 paul (hello kados)
08:06 tumer thd: yes thats what I wanted. Waiting for your e-mail tgarip@neu.edu.tr
08:05 kados w00t!
08:05 pierrick chris upgraded Bugzilla to 2.20.1 :-)
08:04 kados morning pierrick
08:04 thd hello kados
08:04 pierrick hi kados
08:04 thd INSERT INTO `marc_subfield_structure` VALUES ('942', 'l', 'Classification subclass (DDC after decimal or LCC number after letters', 'Classification subclass', 0, 0, 'biblioitems.subclass', 9, '', '', '', NULL, 0, '', '', '');
08:04 thd INSERT INTO `marc_subfield_structure` VALUES ('942', 'k', 'Classification base (DDC to decimal or LCC letter class padded after single letter classes with trailing 0', 'Classification base', 0, 0, 'biblioitems.dewey', 9, '', '', '', NULL, 0, '', '', '');
08:04 thd INSERT INTO `marc_subfield_structure` VALUES ('942', 'j', 'Location (call number prefix code)', 'Location (call number prefix code)', 0, 0, 'biblioitems.classification', 9, '', '', '', NULL, 0, '', '', '');
08:04 thd INSERT INTO `marc_subfield_structure` VALUES ('942', 'c', 'Item type', 'Item type', 0, 1, 'biblioitems.itemtype', 9, 'itemtypes', '', '', NULL, 0, '', '', '');
08:04 thd INSERT INTO `marc_subfield_structure` VALUES ('942', 'a', 'Institution code [OBSOLETE]', 'Institution code [OBSOLETE]', 0, 0, '', 9, '', '', '', NULL, -5, '', '', '');
08:04 thd INSERT INTO `marc_tag_structure` VALUES ('942', 'ADDED ENTRY ELEMENTS (KOHA)', 'ADDED ENTRY ELEMENTS (KOHA)', 0, 0, '', '');
08:04 thd -- Current primary biblioitems Field/Subfields
08:04 kados hi thd
08:04 tumer hi kados
08:04 kados hi tumer
08:03 thd here comes some SQL with comments ...
08:03 tumer thd:new to IRC I think
08:03 thd what is the cause of your connection loss?
08:03 thd tumer why is that?
08:02 tumer I keep losing connection
08:02 thd tumer yes this is good ...
08:02 tumer thd:OK
08:01 thd tumer: well that seems to show that $a and $b are obsolete. I believe that they had once been defined for NPL and then that was changed. I think what you want though is what I put in 942.
08:00 tumer thd: well it seems you have used a and b and left c & d intact
07:59 thd tumer sorry I guess that was a little too much for IRC it does not look bad in VIM with an non text wrapping view.
07:58 thd INSERT INTO `marc_subfield_structure` VALUES ('090', 'd', 'Koha biblioitemnumber', 'Koha biblioitemnumber', 0, 0, 'biblioitems.biblioitemnumber', -1, NULL, NULL, '', NULL, -5, '', '', '');
07:58 thd INSERT INTO `marc_subfield_structure` VALUES ('090', 'c', 'Koha biblionumber', 'Koha biblionumber', 0, 0, 'biblio.biblionumber', -1, NULL, NULL, '', NULL, -5, '', '', '');
07:58 thd INSERT INTO `marc_subfield_structure` VALUES ('090', 'b', 'Koha Dewey Subclass [OBSOLETE]', 'Koha Dewey Subclass [OBSOLETE]', 0, 0, NULL, 0, NULL, NULL, '', NULL, -5, '', '', '');
07:58 thd INSERT INTO `marc_subfield_structure` VALUES ('090', 'a', 'Item type [OBSOLETE]', 'Item type [OBSOLETE]', 0, 0, NULL, -1, NULL, NULL, '', NULL, -5, '', '', '');
07:58 thd INSERT INTO `marc_tag_structure` VALUES ('090', 'SYSTEM CONTROL NUMBERS (KOHA)', 'SYSTEM CONTROL NUMBERS (KOHA)', 1, 0, '', '');
07:58 thd -- Current Record ID Field/Subfields
07:58 thd -- INSERT INTO marc_subfield_structure VALUES ('090', 'd', 'Koha biblioitemnumber (NR)', 'Koha biblioitemnumber (NR)', 0, 0, 'biblioitems.biblioitemnumber', -1, NULL, NULL, '', NULL, '', NULL, NULL);
07:58 thd -- INSERT INTO marc_subfield_structure VALUES ('090', 'c', 'Koha biblionumber (NR)', 'Koha biblionumber (NR)', 0, 0, 'biblio.biblionumber', -1, NULL, NULL, '', NULL, '', NULL, NULL);
07:58 thd -- INSERT INTO marc_subfield_structure VALUES ('090', 'b', 'Koha Dewey Subclass (NR)', 'Koha Dewey Subclass (NR)', 0, 0, NULL, -1, NULL, NULL, '', NULL, '', NULL, NULL);
07:57 thd -- INSERT INTO marc_subfield_structure VALUES ('090', 'a', 'Koha Itemtype (NR)', 'Koha Itemtype (NR)', 0, 0, NULL, -1, NULL, NULL, '', NULL, '', NULL, NULL);
07:57 thd -- INSERT INTO `marc_tag_structure` VALUES ('090', 'KOHA DATA', 'KOHA DATA', 1, 0, '', '');
07:57 thd -- Original Record ID Field/Subfields
07:57 thd tumer my default bibliographic framework currently has the following default values for 090.
07:56 tumer thd:thanks
07:55 thd tumer: yes I am looking now.
07:55 thd tumer I have created a comprehensive bibliographic framework for MARC 21 which is not yet in CVS. I could email it to you before I am liable to commit it.
07:55 tumer thd: all I am asking is we put it in at a place in the framework as default and let the user change it if they know what they are doing
07:54 tumer OK sorry not hard coded.:(
07:54 thd tumer: it is only set by the setting of the bibliographic framework which I had just been discussing with paul
07:53 tumer paul: it is hard coded I thought!
07:52 thd tumer,: yes, blame NPL for not thinking ahead. It could easily be changed because it is not hard coded so do not hard code 090. However I have not selected a better place but merely recommended converting standard 090 usage to 09o with the letter 'o' as a temporary measure.
07:52 paul it's in 090 by default.
07:52 paul tumer: biblionumber can be anywhere.
07:52 tumer thd:Are we to change biblionumber to somewhere else at 3.0?
07:50 tumer thd: but we already have biblionumber in there
07:50 thd tumer: 090 is a poor choice for Koha to use altogether because that is used by many libraries as the place to store LC call numbers in the world's largest library union catalogues.
07:46 tumer thd:yes. anddo they have to be pre-programmed or left to the library to decide?
07:45 thd tumer: you are looking for a good place to store those values which may or may not be 090 $a $b. Is that your question?
07:44 tumer thd: I have the script doing it on my system. Currently I am using 090$a and 090$b to hold these values. But to commit it I need some advice
07:44 thd tumer: there are some subtler issues about LC classification sorting but let me address the question that you just asked.
07:42 tumer thd:yes I am doing that
07:42 thd s/yu/you/
07:42 thd tumer: yu are trying to sort LC call numbers by dividing the leading letter class from the numeric and later parts of the classification both of which may start together in 050 $a?
07:39 thd paul: I want to be certain that UNIMARC keeps up with recent improvements for MARC 21.
07:39 paul :)
07:38 thd paul: ok, I will plan something for your benefit then if you have no plan :)
07:37 thd paul: :)
07:37 paul no, I plan to do nothing.
07:37 thd paul: so you are planning to commit some frameworks with some more fields and subfields than the existing frameworks but less than what I PT has?
07:35 paul (+ I made nothing yet to use your improvements on framework structure)
07:34 paul thd: it's not planned
07:34 thd paul: Will you be committing the IPT frameworks or an even more complete version?
07:33 thd paul: With a little extra work to support any adding subfields as needed at the time of record editing the default subfields present can be extremely small.
07:30 thd paul: I also went back to more minimising than what you had seen.
07:30 thd paul: The design I developed with kados to support complete frameworks allowed preservation of any data that started in the record while providing just a carefully chosen set of subfields to be used for editing if it was not already present in the record.
07:29 tumer paul:For LC indexing I have to parse the classification into 2 parts. Alphabetic and numeric. (LC way of indexin) then use these 2 fields on LC sorts. If we leave this to each library we may have problems(or do we?)
07:26 paul while I have some that are complete, but too much for half of the libraries I bet.
07:26 paul the framework in cvs rel_2_2, default, for unimarc is incomplete.
07:26 thd ?
07:26 thd paul: what recent work is it that is that is less than 95% complete.
07:25 thd tumer: i will answer you in one moment.
07:24 paul tumer: ???
07:24 tumer paul: it has to be decided in general like the biblionumber so that if a library wants to use LC indexing 2 more fields that I'll add to biblioitems will have to reside
07:24 thd paul: I sent a copy to hdl. I had not wanted to commit it until I had finished a few last things and verified ever little element again.
07:23 paul thd: a little bit, although not completly
07:22 paul tumer: no, I think you can use whatever you want (technically). If it's a marc21 question, then thd is a better source
07:22 thd paul: have you seen the work that I prepared for kados where we had extended the hidden parameter to allow support for very comprehensive frameworks without bringing the record editor to a halt generating an excessively large form?
07:21 tumer paul: As a framework expert can you suggest me 2 subfields to use internally for koha for LC indexing. like 090$c biblionumber?
07:19 paul Institut Protestant de Théologie (one of my clients)
07:19 thd paul: what is IPT?
07:19 paul I don't think i'll change anything to the CVS framework for instance.
07:19 paul the one in CVS is a small & efficient one, although 100 & other coded fields are not here.
07:18 paul while the framework used by EMN is small & efficient, but incomplete.
07:18 paul for example, the framework used by IPT is really complete.
07:18 paul in fact, I have many frameworks, some that are small & interesting for libraries that don't want too much MARC, some are complete, but a little bit too much for some libraries.
07:17 thd paul: so it is less than 95% done?
07:17 paul I was a little bit too quick when saying it's 95% done.
07:17 thd paul: Did you understand my question?
07:16 paul i'm back thd
07:10 Sylvinh1 bijour
07:09 thd paul: If you are back again, I will ask again. What UNIMARC framework work have you done recently? You had refereed to something yesterday that was 95% done.
07:03 ToinS salut sylvinho
07:02 paul l'espion marseillais.
07:02 paul hello Sylvinh1 !
05:22 thd ?
05:22 thd paul: so the question I had for you is what work were you referring to yesterday for recent UNIMARC framework corrections that you had mentioned were 95% done.
05:18 thd maybe he will see the logs later
05:17 thd :)
05:17 paul thd : tumer is disconnected
05:17 thd tumer: Also Spanish language material is becoming increasingly important throughout the US despite the false hostility towards immigrants expressed in the US Congress recently.
05:14 thd tumer: I am in New York City where ASCII only would not be taken seriously by most any library. The English only mono culture that infects large parts of the US is pleasantly absent in New York.
05:12 thd tumer: characters past the ASCII range are of importance even in fairly monolingual English records in the US because the standard forms of proper names may use characters past the ASCII range.
05:10 thd tumer: I have communicated to kados about systems which attempt to guess what starting encoding is actually used before conversion and then test as to whether the proposition about the possible encoding is true to overcome cases where the starting encoding is uncertain despite the setting of the record specifying a particular encoding.
05:07 thd tumer: the real problem is that people have records in their system where the leader specified encoding does not match the actual record content in a different encoding.
05:05 thd paul: yes tumer the leader character encoding setting must reflect the character change and some fixes that kados applied for that purpose have sometimes broken.
05:04 paul thd: I think tumer means that the leader MUST reflect the fact that the biblio is in utf-8
05:03 thd tumer: what I meant was that the 'a' and every other character in the leader is ASCII
05:03 tumer The new MFX tries to convert everything to MARC-8. HAve Phone. Out!
05:02 tumer The leader position 10 has to say "a" if the MARC record contains any UTF-8 otherwise breaks. This does not happen with old MFX cause it does not care just passes anything it has as it is
05:02 thd tumer: the leader would never have multibyte characters.
05:01 thd tumer: why doe s the leader need to be UTF-8 when it contains only ASCII values by definition?
04:59 paul tumer: you're right = the updatedatabase tool will have to take care of this.
04:57 tumer In 2.2 when moving to 2.4 or 3.0 we have to make sure that all existing MARC records are UTF-8. Not only the chars but the leader as well otherwise everything breaks down
04:55 tumer Another problem we have to realise is that the new M:F:X is very sensitive , tries to be clever.
04:53 tumer This new M::F::XML does not convert some of the Turkish chars from MARC-8 to UTF-8 so its out for me. I still have to rely on char_decode untill there is a fix
04:52 paul most libraries I think, although very rarely for english ppl
04:51 paul I suggest you wait until joshua is back from it's bed to decide wether you commit or not.
04:51 tumer Who else uses above ascii?
04:51 tumer I are the person (MARC21)
04:50 tumer I have corrected them but dont want to commit it unless someone else tries it as well
04:49 tumer Well I think the char_decode has got some wrong coding in 2.2 thats why some german characters do not get converted.
04:49 paul (kados could confirm)
04:48 tumer are you using char_decode still
04:48 tumer By the way sorry I missed bug-squash I almost got squashed by a two legged bug
04:47 paul throw it, although i'm not sure i'll be the best person to answer.
04:47 tumer have time?
04:47 tumer Hi paul I have questions regarding 2.4 and UTF8
04:47 paul hello tumer
04:46 paul yes.
04:46 tumer Hi is paul around?
04:03 hdl :D
04:01 thd s/the/they/
04:01 thd hdl: language ought to be about conveying meaning where words are accepted for their meaning in whatever context the might possibly be applied. Yet in practise human capacity for language is too limited so we become confused by anything outside a customary pattern because determining possible meaning takes too long to process for our little brains :)
03:53 thd hdl: your expectation was very reasonable about the usage of 'will' and yet if native users never imagine the word in that manner despite its possible application I could not think of what you had meant :)
03:51 hdl And I thought will would denote also kind of commitment conotation.
03:51 thd hdl: I know and English and French are much too tricky. I can certainly see how anyone might think that will would apply and yet I was baffled by the usage :)
03:50 hdl thd: sorry. English is only my second language. ;)
03:49 thd hdl:'request' or 'need' would have been understandable for me in English for that context.
03:47 hdl thd : will stands for request or need compliance.
03:47 thd paul: please let me know when you are off phone.
03:47 thd paul: I have a question for you about your recent work on the UNIMARC framework.
03:46 thd hdl: ok I will ask paul directly, I do not understand your usage of will just now.
03:44 hdl ask paul directly. :) (I think it is a work out of clients will and normalization will)
03:42 thd hdl: paul had made reference to work being done to correct the UNIMARC framework. Work that was 95% done. Can you clarify for me what work that is?
03:40 hdl thd: yes ?
03:40 thd hdl: That clarifies my confusion for acquisitions from yesterday. I have one more question.
03:38 thd hdl: and you support and maintain it somewhat in its current partly working state? I guess that I assumed serials management was an exception that would also work for simple acquisitions without using a budget.
03:37 hdl thd: yes. And normal acquisition is required for serials management.
03:36 thd hdl: yet enough of it does work for your libraries that they use it to provide some service instead of simply using acquisitions simple?
03:34 hdl thd: you won. ;) (They cannot manage it properly with the actual system.) They know We know. As I said, Work work and work again on Acquisition module.
03:32 thd hdl: how do your libraries track receipt of partial shipments without committing the partial receipt of the order? I should have said that rather than deducted from the original order.
03:30 thd hdl: Your libraries are not troubled when a distributor sends only a partial shipment as is the usual case in my experience where some titles still remain to be sent.
03:29 thd hdl: so it seems that you have some scheme for working around some difficulties
03:28 thd hdl: I do not remember all the problems with the acquisitions that I encountered as I had become satisfied with the answer chris gave about it having been broken for years and his clients were not yet using 2.X.
03:28 hdl thd: item receptions must not be deducted but compared to order IMHO.
03:27 hdl thd: what wouldnot be normal were if many receptions of One order was forgotten with keeping the latest reception.
03:26 hdl It is normal not to be deducted from order.
03:25 hdl thd: I admit there are some real needs and some hard work awaiting us on taht module.
03:25 thd hdl: During receipt of the order the quantities were not deducted from the original order.
03:24 thd hdl: I found that an order once completed could not be found because the invoice number was never saved in the SQL tables or something like that.
03:22 thd hdl: Also, I found that I could not complete receiving an order.
03:21 thd hdl: I found that some pages for placing an order had been disconnected from the templates.
03:21 hdl thd: I know they had some template for their clients that wouldnot break things.
03:20 hdl (hcl stands for chlorydric Acid. :) )
03:19 thd hcl: chris had explained to me at the time that normal acquisitions had been broken since 2.X.
03:19 hdl pls detail.
03:18 osmoze hello
03:18 thd hdl: yes, when I tested for 2.2.3 I found some aspects of budget based acquisitions not working in the default intranet English templates.
03:18 hdl But some ppl found it useful.
03:18 hdl I know some limits to acquisition management.
03:17 hdl I am only one year old in Koha project. But yes I now some.
03:16 thd hdl: do you have libraries tracking funds and payments to place and receive orders within Koha during the past two years?
03:16 hdl Is that because you think it doesnot work ?
03:16 paul (still on phone)
03:16 hdl you said confused.
03:16 hdl yes thd. I had read it.
03:15 thd hdl: I am the one confused by paul's statement yesterday :)
03:14 hdl hi osmoze.
03:14 hdl confused ?
03:13 thd paul hdl: I was confused by what was said yesterday about normal (budget based) acquisitions being used by your libraries for the past two years.
02:55 russ hi hdl
02:55 hdl hi russ and chris.
02:55 pierrick OK, thank you :-)
02:55 russ the upgrade i mean
02:54 russ he'll do it
02:54 pierrick OK, if he wants, I can work on the upgrade, but I need a MySQL dump :-)
02:53 russ :-)
02:53 pierrick hi chris :-)
02:53 russ he'll have a look
02:53 pierrick bugzilla 2.14.2 is 4 years old, has bugs and is not supported anymore
02:53 russ (he is sitting right next to me at the moment)
02:52 pierrick (because I would really like an upgrade to Bugzilla 2.20.x)
02:52 russ chris
02:52 pierrick ?
02:52 pierrick russ, who manages bugs.koha.org, I mean software upgrades and so on
02:52 russ hi pierrick
02:52 pierrick hi russ
02:50 russ no worries
02:50 russ for the first talk
02:50 paul (although on phone)
02:50 russ have you got a speaker sorted for the first day?
02:50 paul yep
02:50 russ paul you there?
02:34 russ chris and i are working together on his presntation at the moment
02:33 russ cool
02:33 paul we have a room with 15 chairs, should be OK even if we are 16
02:32 paul almost everybody has a laptop with wifi.
02:32 paul so... everybody coming to Marseille has it's own laptop.
02:32 paul hello russ
02:31 russ hi everyone
02:19 pierrick Je pense bientôt faire une proposition de nouvelle page d'accueil pour le nouveau wiki. La page actuelle est trop chargée
02:19 pierrick OK
02:19 paul bon, je viens de modifier la page d'accueil de l'ancien.
02:18 paul ouaip, mais comme on l'utilise...
02:18 pierrick paul, à ma connaissance, Joshua n'a pas officialisé le nouveau wiki
02:17 paul pierrick: qqn a modifié l'ancien wiki hier( www.koha.org/wiki)
02:15 paul c'était ma vie ;-)
02:15 paul reste juste à faire un chèque de 8250¤ pour le solde de TVA de 2005...
02:14 paul déclarations 2042+ 2035A+ 2035B+ Formation Professionnelle+ TVA+Taxe pro
02:14 paul vive la paperasse à la française !!!
02:13 paul hello hdl
02:13 pierrick bonjour hdl
02:13 paul exact !
02:13 hdl bonjour le monde
02:13 pierrick paul, oui, mais ses horaires sont parfois surprenant
02:13 pierrick paul, bonjour
02:13 paul pierrick: bonjour
02:12 paul pierrick: peut être que joshua dort un peu quand même ;-)
01:58 pierrick kados?
01:55 pierrick chris, are you around?
01:16 mason .
19:56 thd kados: are you back later yet?
15:40 chris righto
15:40 kados chris: pierrick's got a whole list of questions for you :-)
15:40 chris cool
15:40 kados chris: we had a nice bugsquash mtg
15:40 kados morning chris
15:32 chris morning
14:03 kados we could integrate at some point
14:03 kados I bet there's a free currency package out there
14:03 kados probably yes
14:03 owen Should that be combined with a local currency preference?
14:02 kados paul will probably want us to wait until 3.0 for that change
14:01 owen I think a syspref is a fine idea.
14:01 kados heh
14:01 owen I've asked that before, but since no one has ever jumped on it I've been fixing them piecemeal.
14:00 kados any thoughts?
14:00 kados and use that instead of a hardcoded value
14:00 kados owen: I'm wondering if we shouldn't have a syspref specifying number of decimal places
14:00 owen Yes?
14:00 kados owen: noticed your recent commit related to decimal place
13:19 kados thd: yes
13:18 thd-away kados: are you around?