*** rynik has joined #gnuenterprise *** sjc has joined #gnuenterprise Hi, is gacvs using the config files in /etc/gnue or in ~/gnue/etc? ajmitch: Is there any problem that must be addressed when having both the debs and the devel-cvs install? *** btami has joined #gnuenterprise rynik: ~/gnue/etc for g*cvs (installed with setup-cvs.py), /etc/gnue for gnue-* (installed from packages) btw good morning :) and you can use .deb and svn install parallel btami: Thank you. *** reinhard has joined #gnuenterprise good morning all btami: the problems you noticed the day before yesterday regarding uppercase field names (and probably also gnue-invoice) should be fixed now, if you have time please test. *** kilo has joined #gnuenterprise do we actually support pictures with gnue? good morning good morning kilo reinhard: images? you mean pictures? do we actually support pictures with gnue? so yes I guess i mean pictures ;-) images graphical data :) you want to display them? both display them in a form and print in a report to display them in a form -> gnue-invoice Head.gfd as of report... dunno reinhard: both of your fix is OK, thx btami: thanks for checking the (unfinished) universal report filter will supports images kilo: Head.gfd contains a static image, right? yep I was thinking about images loaded from a database it's supported too in wx iirc or maybe a filename in the db and image loaded from that file but no sample out there? will look myself then, thanks filename in db and image loaded from file is possible other way i dont know kilo: you know off hand how to do the gfd then? btami has a VERY GOOD example...
Char:y="13" block="blkUGYFEL" field="fldVaros"/> Char:y="3" block="blkUGYFEL" field="fldVaros" fit="auto"/> this is my old image test form thank you very much! np I start to woder what "ugyfel" means :) wonder ugyfel=customer :) ügyfél it is and varos=city :))) sometimes i'm using my customer entry form as a base for other testcases I figured that :) *** lekma has joined #gnuenterprise hi hi lekma how goes? *** rynik has quit IRC fine i'm home in amsterdam for the week end :) it's been six months since i was home reinhard: is the todo in 0.4.1 still actual?? ie will the 0.5 release provide some auth mechanism? honestly the 0.5 vs. 0.6 is not yet set in stone we have two big todos - authentication/security and administration/multithreading hi which will be 0.5 and which will be 0.6 is not yet finally decided hi ajmitch *** dimas has joined #gnuenterprise ok hello all hi dimas *** SachaS has joined #gnuenterprise *** mnemoc has quit IRC hello btami *** mnemoc has joined #gnuenterprise FWIW pictures work nicely with gtk2 UI, too *** aries_mindworks has joined #gnuenterprise hi hi aries btami you were right, accounts without password are not supported in the appserv reinhard: pictures? * dimas is reading in the backlog.. *** lekma has quit IRC bye *** aries_mindworks has left #gnuenterprise bbl *** btami has quit IRC *** tiredbones has joined #gnuenterprise tiredbones: did you find out what happened with those permissions? ajmitch: I'm confused. In my archive file I have have forms, nav, and report debs but no common. *** dcmwai has quit IRC ajmitch: Also, all my debs in with ***ubuntu1_all.deb except designer. That ends with gnue-designer_0.5.6-1_all.deb. that's because all the others were modified for ubuntu ajmitch: Should I update my debs? designer didn't need to be (iirc) go ahead, but it probably won't make much difference :) hoary is final, so there'll be no updates since the release *** holycow has quit IRC ajmitch: Do you have any idea why no common? *** holycow has joined #gnuenterprise because your cache was probably cleaned at some point? dpkg -l gnue-common it ought to be 0.5.14-1 installed ajmitch: ok, I have that release. ajmitch: thanks for help. so what currently is broken? * ajmitch checked the deb from the ubuntu mirrors, it has the right permissions for the directory ajmitch: Since I change the permissions on drivers thing look to be ok. Just to let people know,the info in "GNUe Common: Developer's Introduction" from page 1 to 16 seems to be good stuff.If James Thompson is around, I want you to know you did a good job in this doc. Now on to using the GParser. Mr. Thompson, you can send the check to @#$%. tiredbones: FYI James Thompson == jamest reinhard: do not prevent him to send a check to the real guy, not just irc entity :) s/check/money *** sjc has quit IRC *** kilo has quit IRC *** Amorphous has joined #gnuenterprise *** jamest has joined #gnuenterprise reinhard: i think the api docs should generate now yep, thanks a lot already saw it really odd issue really as the 3rd time thru the script showed nothing would it be possible to send the error messages of epydoc to gnue-dev@gnu.org ? some parts don't get generated because epydoc has problems importing those files but the cron job listed above it in crontab was missing a username ouch but I know I get daily update website emails thus i thought it was running ok sure, we can change that as to forms any reason one would want (in a trigger) to clear a detail block in a m/d form without clearing the master? reinhard: when you say you already saw what jamest did, where are you looking? tiredbones: http://www.gnuenterprise.org/developers/docs.php all those "API docs" sections they are the best and most current docs we have I think reinhard: via a trigger? (now that they get generated again, thanks to jamest) jamest: yes there is a block.clear available in trigger namespace which is actually a paradoxon like block.commit and block.rollback is because you can only commit and rollback on connection level, not on block (table) level (and clear implies a rollback) i'm pretty sure at one time you could commit at block level as I have hidden blocks that I manipulate via triggers then would commit for quite some time (IIRC *before* johannes and me started messing with common) block.commit called form.commit i'm sure you're right the only reason I could think of for a detail clear is if you were wanting to manipulate a hidden detail block? kinda. maybe. Yeah, it's a stretch that I can't think of a single use for :) ok ) :) so i'm cool if it goes FWIW many of the stuff we have to change in GFBlock relates to a problem we have with appserver with the server side procedures imagine you enter some stuff in your form then press a button to call a server side method to make all current values available to the method, we have to *post* the data you entered into the form to the backend but not yet *commit* it because the user hasn't hit commit yet true but as all databases only support commit on connection level a block level commit of another block would silently (and wrongly) also commit the other data that distinction between post and commit was not there at all before in gnue i moved that email to info@gnuenterprise.org the cron job log? as I didn't care to mess with (at this time) the fact that gnue-dev and gnu.org is probably subscriber only ah ok who gets info@gnuenterprise.org? (I think I don't) info: jamest jcater derek reinhard oh ok thanks *** SachaS has quit IRC *** jcater has joined #gnuenterprise *** dcmwai has joined #gnuenterprise *** jcater has quit IRC *** titopbs has joined #gnuenterprise *** titopbs has quit IRC *** titopbs has joined #gnuenterprise *** btami has joined #gnuenterprise http://www.gnuenterprise.org/cgi-bin/viewcvs.cgi/gnue/trunk/ doesn't work Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/viewcvs/viewcvs.py", line 3235, in main request.run_viewcvs() File "/usr/lib/python2.3/site-packages/viewcvs/viewcvs.py", line 360, in run_viewcvs self.view_func(self) File "/usr/lib/python2.3/site-packages/viewcvs/viewcvs.py", line 1351, in view_directory file_data = request.repos.listdir(request.path_parts, options) File "/usr/lib/python2.3/site-packages/viewcvs/vclib/svn/__init__.py", line 369, in listdir if entry.kind == core.svn_node_dir: TypeError: Expected a pointer *** dcmwai has quit IRC btami: ok give me a bit try now *** holycow has quit IRC it's ok now, thx *** sjc has joined #gnuenterprise *** jcater has joined #gnuenterprise bbl *** btami has quit IRC bbl (maybe) *** reinhard has quit IRC *** wendall911 has joined #gnuenterprise hmmm in postgresql it's possible to create an index using functions an example would be something like create index foo on table (upper(field)) in cases like this gnue's introspection code pukes as it expects every index to reference a field and this index wouldn't so I'm wondering if an index does reference fields would it be acceptable to just ignore that index IOW: in gnue's eyes it wouldn't exist I think so oh you do? why, yes yes, I do groovy I thought so as well then it's settled yeppers *** kilo_ has joined #gnuenterprise *** jcater has quit IRC *** reinhard has joined #gnuenterprise *** someon has joined #gnuenterprise Dumb question... has anyone worked out a way to either user GNUe funtionality to re-direct an inbound email to an email address or to "consume' an email service, updating an entry from an email? yes What does it do? Redirect, or consume? i've written a procmail rule that calls a python script that parses the mail and sets some data in appserver consume Cool... I'm thinking along the lines of DCL, with email going to dcl@gnue.org where the subject begins with the DCL ticket number... any update from the preson that had the problem would end up in the diary field, and the person assigned would get notified of an update. erm.. s/preson/person someon: that would be pretty sweet someon: too bad headers don't support stuff like that Headers don't support stuff like what? SUBJECT: RE: DCL019283 .... So update DCL Ticket #019283 someon: oh, would be cool if there was an rfc that supported additional data sent through email headers someon: subjects aren't always dependable very cool idea though Yeah, I know subject isn't always dependable, but right now, I'm doing outbound email from my personal (work) account, with the tracking numbers... most people just hit REPLY, and so I get RE: CHG0004938 - Need something installed So then my direct email get out to the clients, and they just send random emails with requests, instead of going through the correct channels (very bad, since I'm one of 4 on a team, and I'm not necessarily in the office) Software we are using can be configured to do something similar, but it's a big big job to do it. And I'd like to get off of that software anyway. wendall911: do you know if RFC822 X- headers get included in a reply? eg. if you set header X-DCL:019283 , does the same header appear in the reply? someon: I think it depends on the mail client. I have been planning on researching that myself. It would be very cool if it appeared. someon: then it could be transparent and retain the information even if the subject was changed Most people don't mess with the subject, and you could even have a bounce set up (if subject is not a found DCL Tracking #, then send email back advising that the DCL # must be at the beginning of the subject) someon: I am applying the concept to threading for mailing lists. Threading gets lost alot with changed subjects. Even though it shouldn't happen, it sometimes does. It would be fairly reliable if x-headers are retained on reply someon: however, that would eliminate the option of posting new information to the server for a bug that you just copy/pasted the bug # into the subject Also, who knows what would happen to an X- header on forwarding an email... eg. from your maillist, I find something interesting to a friend that is not on the maillist. If the friend replies to the maillist, it would follow threading correctly on subject, but not if the X- header got dropped NNTP has the ARTICLE header which tracks threading... :q *** jamest has left #gnuenterprise yeah, nntp is best for lists, but not the perfect option by far I was more meaning the header that they have... most mail programs know to pick it up when replying to news, but ??? when replying to mail. *** mnemoc_ has joined #gnuenterprise *** menomc has joined #gnuenterprise *** kilo_ has quit IRC *** mnemoc has quit IRC *** someon has quit IRC *** titopbs has quit IRC *** wendall911 has quit IRC night all *** reinhard has quit IRC *** sjc has quit IRC *** chrismo has joined #gnuenterprise *** dcmwai has joined #gnuenterprise *** chrismo has quit IRC *** jcater has joined #gnuenterprise