*** dimas has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<dimas> hello johannesV
<johannesV> dimas, joins should work again ...
<dimas> yes, thanks
<dimas> i saw that
<dimas> still having other problem
<johannesV> what kind of pb ?
<dimas> just a moment
*** sjc has joined #gnuenterprise
<dimas> johannesV: it could come from my misproper use of filters but
<dimas> it seems that using filters restore dependancy on setting encoding="non ascii" in site.py
<dimas> what i have now - i loaded gl.gcd from gnue-luca
<johannesV> hmm, you were discussing this with reinhard ?
<dimas> so filters on base_company and gl_year were added
<johannesV> ok, you've added the gld's too ?
<dimas> yes
<dimas> when i last talk with reinhard i had 500.. something protocol error and nothing work
<dimas> now i could pass login dialog
<dimas> forms to classes that filters were applied to works fine, like base_company gl_*
<dimas> forms to other classes do not display any data except created/updated fields
<johannesV> wow, that's crazy ...
<dimas> so queries work - i see number of rows queried
<johannesV> if i've got some time left this morning i can try it using gnue_luca so we do have a similar scenario
<dimas> commit works - i see all data come into db
<johannesV> what happens on adding a new record, and the do a 're-query' ?
<dimas> the same
<johannesV> is the data stored in the backend ?
<dimas> it come into db
<dimas> it retrieved just all entry are empty
<dimas> enties
<dimas> entries
<johannesV> but they are correctly stored in the backend ...  so later retrieval is buggy ?
<dimas> yes, correct in the db, just not displayed
<johannesV> ok, so i'll try to reproduce it here
<johannesV> but it might take some time, as i've got some customers work to do first
<dimas> johannesV: could you advice how to check those data in cache,resultset and in geasList objects easily?
<johannesV> dimas, you could use the debug-levels so you see entry-points of function-calls (including arguments) as well as results
<johannesV> this way you could see where the data is lost
<johannesV> session-manager = level 4, language-interface = level 6
<johannesV> common's datasources = level 4
<johannesV> erm level 3
<johannesV> but you could also do a debug-level=1-9 so you will see everything (but this would be quite a log)
<johannesV> i mean, quite a lot
<ajmitch> derek: yes I'm still here if you're around :)
<dimas> johannesV: yes, quite a lot of logs :)
<johannesV> so i'd say you will use debug-level=3,4,6
<johannesV> so you see what's handled by the backend (common's dbdrivers) and what appserver's doing with that
<dimas> johannesV: could you tell, if i added some module that uses filter to my existing say "db"
<johannesV> what do you mean with 'added some module ....' ?
<dimas> it added filter field to login dialog but how it affected that whole db behaviour
<dimas> other classes
<dimas> that existed before filter
<johannesV> adding a filter to a class does two things: it changes that class by adding another property, and all access to classes having that property are filtered by the current filter-value
<johannesV> other classes (not having such a filter-property) shouldn't be touched in any way ...
<johannesV> but i say "shouldn't" - maybe you've found a bug ...
<dimas>     list = geasList.geasList (self, classdef, self.__connection, recordset,
<dimas>                            [u'gnue_id'] + propertylist, asCond, dsSort, asSort)
<dimas> from this point in geasSession accessing two classes going very differently
<dimas> filter/non-filter classes
<johannesV> in which way ? is there another condition for filtered ones ?
<dimas> so i'd like to see what real data is at that point
<dimas> for filtered it complete request and ready to return data
<dimas> for non-filtered it doing some strange work i could not explain :)
<johannesV> do you have calculated fields in condition or sorting for non-filtered ones ?
<dimas> yes, calculated
<johannesV> ok, so it may have something to do with that, because appserver has to examine conditions than, instead of passing it to the backed
<dimas> it is simple class for person with calculated full name
<johannesV> (at least from the calculated)
<dimas> what if i remove calculated field to test again? class
<dimas> what if i remove calculated field to test again?
<johannesV> would be an option, but you might send me  the gcd for that person class by mail
<dimas> address?
<johannesV> jv at bytewise dot at
*** reinhard has joined #gnuenterprise
<dimas> johannesV: sent
<dimas> hi reinhard
<johannesV> ok, thanks ... will have a look at it asap
<reinhard> good moring all
<dimas> reinhard, johannesV : tested again with fresh appserver,common sources
<dimas> adding filtered classes require proper encoding in site.py otherwise thtows an error before login dialog appears
<dimas> reinhard: base_company class, is it done to keep one company or list of base companies?
<johannesV> dimas, a list of companies (afaik)
<reinhard> list of companies
<dimas> ok
<dimas> reinhard: in base-C.gld in gnue-luca
<dimas>   <class name="company" label="Company">
<dimas>     <property name="code"     pos="100" label="Code"          search="100" />
<dimas>     <property name="name"     pos="200" label="Name"          search="200" />
<dimas>   </class>
<dimas> 
<dimas>   <class name="currency" label="Currency">
<dimas>     <property name="code"      pos="100" label="Code"   search="100" />
<dimas>     <property name="name"      pos="200" label="Name"   search="200" />
<dimas> 
<dimas> Seems like defined filter for currency, filter for currency is not used and not appear in login dialog but property names equal, could it somehow give a confusion?
<dimas> btw, problem with some data not displayed is still exist
<johannesV> no, since the names are: base_company.base_code and base_currency.base_code
<dimas> i loaded base.gcd from gnue-luca with base-ru.gld that's white the same as base-C.gld
<dimas> i could work with base_company, base_currency classes
<johannesV> dimas, do you restart (sighup) appserver after adding records to the filter-classes (base_company/currency) ?
<johannesV> so the new filters are available
<dimas> any other classes (generated and written forms) even base_parameters work as before - commit, retrieve, just did not display
<dimas> yes restarted
<dimas> johannesV: i could switch completely to gnue-luca and test again
<dimas> http://www.gnuenterprise.org/contrib/
<dimas> The requested URL /contrib/ was not found on this server.
<dimas> menu entry - Other Projects on main page
<johannesV> dimas, i haven't got your mail till now ...
<dimas> oops
<dimas> sent again
<johannesV> got it
<johannesV> ok, i'll try it right now ...
<johannesV> i've loaded all gcd's/gld's from gnue_luca as well as your person.gcd
<johannesV> now i call the base_company-class to add new companies
<johannesV> now, i call the gl_year-class to add new fiscal years
<johannesV> (here the company filter should apply already)
<johannesV> now i call the PERSON_person class
<johannesV> great ! i can reproduce the situation
<dimas> huh
<johannesV> after adding a record, commiting, requery it's not available ...
<dimas> yep
<johannesV> although the backend has stored everything fine
<dimas> same here
<dimas> johannesV: test for base_parameters
<dimas> though base_parameters uses filter
<dimas> base_parameters should work
<johannesV> no, there's something completley wired in there ... as the sql (on level 3) should give a result but it doesn't come along to the form ... but adding a new record UPDATEs that not-displayed record ...
<dimas> yes
<johannesV> ok, i've added two records
<johannesV> now, looking into debug-level 4, the result of geasSessionManager.count () (after request) is 2 !
<johannesV> so the records get into appserver
<johannesV> but the load (called by fetch returns None instead of the real content)
<johannesV> maybe we hit another case-problem here
<dimas> is it came from PERSON_Person naming, or what?
* johannesV is still trying ... stand by
<johannesV> great
<johannesV> that's it
<johannesV> if you name it "person_person" in your gcd it's working ...
<johannesV> but you don't need to change it, as appserver must support this
<johannesV> i'm not sure atm wether it's an error in appserver or one in common, but i tend to blame appserver
<johannesV> so this pb has nothing to do with filters then, although i'd like to revise that filtering-topic at some time (like adding filter-values without restarting appserver ....)
<dimas> but the same person.gcd works just fine when loaded alone
<johannesV> you mean without gnue_luca ?
<dimas> yes
<johannesV> hm, that's strange ...
<johannesV> will try
<dimas> where gnue-luca is just something that use filter
<dimas> and also remember that how adding filter back to require encoding setting in site.py (as a workaround)
<johannesV> no, for me using person.gcd without gnue_luca does not work as well
<dimas> hm
*** ajmitch has quit IRC
<johannesV> i'm getting closer and closer ... :)
<johannesV> i've to leave for lunch now ... maybe i can dig into this in the evening (or maybe reinhard finds some time to look at it) -- i think it's because appserver uses 'case' internally and datasources don't. anyway i think appserver's data.cache () is bogus there cause it's case-sensitive
<johannesV> bbl
*** ajmitch has joined #gnuenterprise
<johannesV> the problem is in the RecordSet where x.current ['t0.PERSON_first'] returns None, although x.current.getFieldsAsDict () has a key 't0.PERSON_first'
<johannesV> ah, ok, now i see
<johannesV> Base.RecordSet.getField () does a field.lower () in order to return the value from it's _fields dictionary
<johannesV> but the _fields-dictionary has camelCase keys ... so this can never work well ...
<johannesV> I'd propose again to use a CaselessDict there ... so it's really assured to have no mixed case entries
<johannesV> so it is *not* appserver's fault here ...
<johannesV> ok, but now i'm really off
*** tiredbones has joined #gnuenterprise
<reinhard> dimas: could you please svn up and try again?
<reinhard> I think my last commit should fix the bug
<ajmitch> morning reinhard
<dimas> reinhard: i have tested with r7205
<dimas> is there newer?
<dimas> updating anyway..
<reinhard> 7206 (commit 5 minutes ago)
<dimas> got 7206
<dimas> ok
*** ajmitch_ has joined #gnuenterprise
<dimas> reinhard: thanks, not it works :)
<dimas> reinhard: thanks, now it works :)
*** ajmitch has quit IRC
<reinhard> great
<reinhard> dimas and johannesV: many thanks for debugging
<reinhard> with what you already found out fixing it was a piece of cake :)
<reinhard> although I agree with johannes that I don't see any relation between this bug and the filters...
<reinhard> but sometimes such things are greatly obscured
<dimas> reinhard: that PERSON_Person class worked fine to some point
<reinhard> dimas: also, I do changes to the base dbdriver all the time
<reinhard> so it might be that actually not introducing filters broke it, but updating to a more current svn (when I broke the code meanwhile)
<dimas> in the morning I tested with fresh appserver/common code
<dimas> and recreated db
<dimas> when first i have PERSON_Person loaded
<dimas> then adding gl things
<reinhard> nevermind
<reinhard> now it works, and that's the most important point :)
<dimas> see also my note about encoding
<dimas> it is reproducable even now
<reinhard> what was that again?
<reinhard> dimas: adding filtered classes require proper encoding in site.py otherwise thtows an error before login dialog appears
<reinhard> that?
<dimas> yep
<reinhard> what is "proper encoding" in this case?
<dimas> by default it is ascii
<dimas> and it is ok as gnue initialized needed encoding itself
<dimas> but at some point (for me it is when i add gl.gcd from luca) it is not enough
<dimas> and i'm getting 500.. protocol error
<reinhard> ok
<reinhard> no matter which locale you run appserver and forms, right?
<reinhard> even when you run both with LANG=C LANGUAGE=C?
<dimas> that i could overcome setting encoding="my-local-encoding"
*** ajmitch_ has quit IRC
<dimas> did not try lately with LANG=C
<reinhard> hmm let me test something please
*** ajmitch_ has joined #gnuenterprise
<reinhard> no, cannot reproduce
<reinhard> had a quick thought if it maybe depends on whether you use non-ascii characters in company code or name
<reinhard> but even then I don't get that error
<dimas> ok
<dimas> reinhard: thanks anyway for the fixes :)
<johannesV> i cannot reproduce that encoding thing too
<dimas> was there a commit message for r7206 ?
<johannesV> not yet
<johannesV> ah, here it is ... (commit mail)
<dimas> :)
<dimas> got it too
<reinhard> bbl
<johannesV> btw, dimas, you could shorten your calculated props in person.gcd a bit ...
<johannesV> instead of
<johannesV>  name = ''
<johannesV>       if self.last:    name += self.last + ' '
<johannesV>       if self.first:   name += self.first + ' '
<johannesV>       if self.middle:  name += self.middle + ' '
<johannesV>       return name
<johannesV> you could write:
<johannesV>  return ' '.join ([f for f in [self.last, self.first, self.middle] if f])
<dimas> great, thanks :)
*** lekma has joined #gnuenterprise
<johannesV> i've just added a patch so it makes no difference wether one calls 'gnue-forms appserver://appserver/form/PERSON_Person' or 'gnue-forms appserver://appserver/form/person_PeRsOn'
<lekma> hi all
<johannesV> hi lekma
*** jamest has joined #gnuenterprise
<lekma> johannesV: about abort and message builtin binding
<lekma> i've seen only message being bind
<lekma> as i'm stuck with latest release for the moment i have to try and apply diffs to get it to work
<lekma> and from the svn log i see only message() being bind in builtins, is that correct? (i may be completely wrong)
<johannesV> lekma, no, abort () is bound in logic.language.apdapters.python directly
<johannesV> since abort () is a method of PythonFunction
<johannesV> i need to run now, but i try to bbl
<johannesV> anyway -- you should be able to call both, message () and abort () as builtin
<lekma> ok
*** holycow has quit IRC
*** jcater has joined #gnuenterprise
<reinhard> good morning jcater
<reinhard> FWIW I told you some days ago that I thought I broke primary key support in Oracle
<reinhard> in fact the piece of code I thought I did break was commented out anyway
<reinhard> it's the pk support via oid which had a "return # FIXME this is broken" at the very start
<reinhard> so you *might* still be sure to update svn
<jamest> :)
<jamest> i'm about to ask something that i'd ban me for asking :)
<jamest> anyone know of a python code editor that can come close to the functionality netbeans provides for java
<jcater> http://www.python.org/moin/IntegratedDevelopmentEnvironments
<jcater> just so happens, I was just looking at that page
<jcater> reinhard: will do
<jcater> (maybe)
<jamest> sigh, i must be a google addict, as I never thought to try the python site itself
*** johannesV has quit IRC
<reinhard> jcater: thanks
<reinhard> and please report me any problems or requests for improvement
<reinhard> although I still regard that stuff work in progress, I already finished some things you started and didn't get around to finish, like support for requerying after posting changes to the datasource
*** johannesV has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
<jcater> jamest: google returned that for me early on
*** mnemoc_ has joined #gnuenterprise
<jamest> then i just must be dumb
*** dimas has quit IRC
*** mnemoc has quit IRC
<jcater> jamest: we still love you though
*** wendall911 has joined #gnuenterprise
*** titopbs has quit IRC
*** dcmwai has quit IRC
*** dimas has joined #gnuenterprise
*** edo has joined #gnuenterprise
<edo> Hello, is there anybory?
<dimas> edo: hi
<reinhard> in and out
<edo> Is this the GNUe project channel right?
<edo> First time I use IRC...
<dimas> yes
<edo> Anybody is up to the ERP subprojects?, I wish to be useful if I can
<chillywilly> what's the best way to have a read-only mailing list with mailman? Set it to be moderated?
<wendall911> chillywilly: yep
<wendall911> chillywilly: you can set it so all list administrator mail goes through
<dimas> edo: kilo, btami, reinhard
<reinhard> edo: which would be your primary field of interest?
<chillywilly> why would the list administrator mail not go through?
<edo> reinhard: I'm an Accountant too in Italy, I've gone up to Managing Engineer (I think this is the traslation for), so I'll try to follow the sales at first, but just ask you what have to be done
<edo> reinhard: Because the Supply chain, as a workflow engine would be great to join
<chillywilly> hmmm, that message went straight through
<reinhard> edo: in this case you'd probably want to get into contact with kilo and btami who are working on invoicing and CRM
<reinhard> you will meet them here if you hang around here for some time :)
<reinhard> bbl
<edo> reinhard: Good to know, now here there's a post-it with kilo and btami on it , first step, thanks
<dimas> edo: do you have gnue installed?
<edo> dimas: Yes, I'm running GNUe on Debian testing
*** SachaS has joined #gnuenterprise
<dimas> ok
* edo è stato segnato come "assente".
* edo non è più segnato come "assente". "Andato via" da 17:26, 15/3/2005.
*** edo has quit IRC
*** edo has joined #gnuenterprise
*** edo has left #gnuenterprise
*** bigbrother has joined #gnuenterprise
*** bigbrother has joined #gnuenterprise
*** Ludovi[K] has joined #gnuenterprise
* Ludovi[K] np: Twin Peaks O.S.T. - Into The Night (Vocal By Julee Cruise) [04:44m/160Kbps/44KHz]
* Ludovi[K] np: Twin Peaks O.S.T. - Falling (Vocal By Julee Cruise) [05:21m/160Kbps/44KHz]
* Ludovi[K] np: Twin Peaks O.S.T. - Dance Of The Dream Man (Instrumental) [03:41m/160Kbps/44KHz]
*** Ludovi[K] has quit IRC
*** nickr has joined #gnuenterprise
*** edo has joined #gnuenterprise
*** dimas has joined #gnuenterprise
*** wendall911 has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** bigbrother has joined #gnuenterprise
*** bigbrother has joined #gnuenterprise
*** mnemoc has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** lekma has joined #gnuenterprise
*** ajmitch_ has joined #gnuenterprise
*** edo has left #gnuenterprise
*** edo has joined #gnuenterprise
*** edo has left #gnuenterprise
*** dcmwai_ has quit IRC
*** lekma has quit IRC
*** mnemoc has quit IRC
*** ajmitch_ has quit IRC
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** lekma has joined #gnuenterprise
*** ajmitch_ has joined #gnuenterprise
*** mnemoc has joined #gnuenterprise
*** titopbs has quit IRC
*** lekma has quit IRC
*** ajmitch_ has quit IRC
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** lekma has joined #gnuenterprise
*** ajmitch_ has joined #gnuenterprise
*** dogge has joined #gnuenterprise
*** lekma has quit IRC
*** ajmitch_ has quit IRC
*** johannesV has quit IRC
*** lekma has joined #gnuenterprise
*** ajmitch has joined #gnuenterprise
*** dcmwai has quit IRC
*** kilo has joined #gnuenterprise
*** edo has joined #gnuenterprise
<edo> kilo: Hi, you're following the CRM and invoices right?
<kilo> hi
<kilo> kinda
<edo> I've come here to see if I can be useful
<edo> How can I start up?, I'll try to make modules and follow them to you?
<kilo> you definitly can
<kilo> but i'm sorry, i'm not in a good state for this now, i've been almost shutting down when yo came
<kilo> could we plz talk about it tomorrow during normal daytime or in the evning?
<edo> ok
<kilo> thx, sorry
<kilo> night
*** kilo has left #gnuenterprise
<edo> night
<edo> I'll go too then, I'll wait to see tomorrow
*** edo has left #gnuenterprise
*** titopbs has joined #gnuenterprise
*** SachaS has left #gnuenterprise
*** jamest has left #gnuenterprise
<reinhard> night all
*** reinhard has quit IRC
*** jcater has quit IRC
*** wendall911 has quit IRC
*** sjc has quit IRC
*** titopbs has quit IRC
*** dimas has quit IRC
*** jamest has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** lekma has quit IRC
*** tiredbones has quit IRC
*** dogge_ has joined #gnuenterprise
*** dogge has quit IRC
*** titopbs has joined #gnuenterprise
*** jamest has quit IRC
*** jcater has quit IRC