From richie at vtiger.com Tue Jul 4 04:02:55 2006 From: richie at vtiger.com (Richie) Date: Tue, 04 Jul 2006 04:02:55 -0700 Subject: [Vtigercrm-developers] update bleeding edge svn Message-ID: <10c393477d3.4701894980957041264.-7646275652836694714@@vtiger.com> Hi Matt! Wanted to confirm if we have a script in place for updating the latest code in the vtiger-demo.fosslabs.com site? There have been forum queries if the updates are happening in the first place. Kindly inform. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060704/3631a295/attachment.html From saint at vtiger.com Tue Jul 4 11:40:33 2006 From: saint at vtiger.com (Saint) Date: Wed, 05 Jul 2006 00:10:33 +0530 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings Message-ID: <44AAB621.8080701@vtiger.com> Folks, The following are the new "Settings" icons getting into vtiger 5. *Module * *Icon * Users Roles Privilege Profiles Groups Modules Access Fields Access Module Owners Announcements Custom Fields Picklist Editor Email Templates Mail Merge Tempaltes Notification Schedulers Inventory Notifications Inventory Terms & Conditions Company Details Mail Server Settings Backup Server Settings Proxy Server Settings System Information Invoice Configuration Audit Trail Tax Configuration Currency Settings Migration -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1968 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0024.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1951 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0025.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2197 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0026.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2328 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0027.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2134 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0028.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2319 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0029.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1925 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0030.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2267 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0031.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1883 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0032.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1957 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0033.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2160 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0034.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2175 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0035.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1975 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0036.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2264 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0037.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2370 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0038.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1732 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0039.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2121 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0040.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1972 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0041.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2182 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0042.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2492 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0043.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2546 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0044.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1796 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0045.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2441 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0046.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2451 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0047.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: set-IcoMigration.gif Type: image/gif Size: 2187 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/set-IcoMigration-0001.gif From sergiokessler at gmail.com Tue Jul 4 12:09:33 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 4 Jul 2006 16:09:33 -0300 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings In-Reply-To: <44AAB621.8080701@vtiger.com> References: <44AAB621.8080701@vtiger.com> Message-ID: <49216030607041209h171b32d1w9b6e737e1c65a5a8@mail.gmail.com> wow, beautiful ! /sak On 7/4/06, Saint wrote: > > > Folks, > > The following are the new "Settings" icons getting into vtiger 5. > > > Module > Icon > > Users > > > Roles > > > Privilege Profiles > > > Groups > > > Modules Access > > > Fields Access > > > Module Owners > > > Announcements > > > Custom Fields > > > Picklist Editor > > > Email Templates > > > Mail Merge Tempaltes > > > Notification Schedulers > > > Inventory Notifications > > > Inventory Terms & Conditions > > > Company Details > > > Mail Server Settings > > > Backup Server Settings > > > Proxy Server Settings > > > System Information > > > Invoice Configuration > > > Audit Trail > > > Tax Configuration > > > Currency Settings > > > Migration > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From don at vtiger.com Wed Jul 5 08:59:39 2006 From: don at vtiger.com (don) Date: Wed, 05 Jul 2006 08:59:39 -0700 Subject: [Vtigercrm-developers] vtiger CRM 5.0 Beta2 Released Message-ID: <10c3f6a8177.-9001623588305850621.-4297454805191080021@@vtiger.com> Hi All, We are pleased to announce the release of vtigerCRM 5.0 Beta 2. In this release the main focus is on the quality front and we have fixed most of the major bugs that were in the vtigerCRM 5.0 Beta. We have also incorporated most of the feedbacks/suggestions given by the community over 5.0 Beta. In the UI front, the Settings UI has been totally revamped. This release will depict the developments done after vtiger CRM 5.0 Beta. You can give it a try and let us know your valuable feedbacks and suggestions. The live demo of vtigerCRM 5.0 Beta is available at http://vtiger.com/products/crm/demo_5beta/index.php You can download the vtiger CRM 5.0 Beta2 from the following URL : http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=196218&release_id=429844 You can post your feed backs and suggestions at http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Thanks & Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/59d438e1/attachment.htm From nico.gnauck at googlemail.com Thu Jul 6 10:12:58 2006 From: nico.gnauck at googlemail.com (Nico Gnauck) Date: Thu, 6 Jul 2006 19:12:58 +0200 Subject: [Vtigercrm-developers] Merge with OpenOffice documents Message-ID: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Hello, I'm currently working on a Mail Merge for version 5.0 with Open Office Dokuments based on the rtf Merge for version 4.2.3. You can find the thread and the Merge skripts for Accounts and Contacts in this thread: http://forums.vtiger.com/viewtopic.php?t=7223. If anybody has time to test this, please do so and give me feedback. Thanks, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/776050fd/attachment.html From mmbrich at fosslabs.com Thu Jul 6 10:32:44 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 06 Jul 2006 11:32:44 -0600 Subject: [Vtigercrm-developers] Merge with OpenOffice documents In-Reply-To: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> References: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Message-ID: <1152207165.22922.96.camel@localhost.localdomain> Hi Nico, I haven't had a chance to test yet but I did merge this into my vtiger5 branch in the branches/ directory of the SCM system. I will get it tested as soon as I can, from there the other developers can decide if it should be merged into trunk/. If you find/fix issues in this branch please post the patches here and I will get them merged in. If you have enough issues and would like, I can set you up with commit access to my branch. Thanks for your contribution! Matt On Thu, 2006-07-06 at 19:12 +0200, Nico Gnauck wrote: > Hello, > > I'm currently working on a Mail Merge for version 5.0 with Open Office > Dokuments based on the rtf Merge for version 4.2.3. > You can find the thread and the Merge skripts for Accounts and > Contacts in this thread: > http://forums.vtiger.com/viewtopic.php?t=7223. > If anybody has time to test this, please do so and give me feedback. > > Thanks, Nico > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Thu Jul 6 13:17:20 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Thu, 06 Jul 2006 16:17:20 -0400 Subject: [Vtigercrm-developers] Trac 0.9.6 released Message-ID: Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. From richie at vtiger.com Thu Jul 6 22:22:12 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:22:12 -0700 Subject: [Vtigercrm-developers] trac account Message-ID: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/f616fb9d/attachment.htm From richie at vtiger.com Thu Jul 6 22:25:43 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:25:43 -0700 Subject: [Vtigercrm-developers] update svn-version Message-ID: <10c4772d440.733718465091492167.4729172311574536110@@vtiger.com> Hi! Got this mail in the forums. Can someone do the needful please? Jeff, what do you say? "Hi forum users and especially vtiger admins, im not quite sure, if this is the right place to post, but i think you guys should really consider updating your subversion server to > 1.2.x. For us developers using eclipse it's painstaking to get it to work well, because the svn plugin (subclipse.tigris.org) only supports the old svn servers (< 1.2.0) only if you choose to install a very old version of the plugin (< 0.9.3.0). Unfortunately, this version of the plugin is very buggy, and i can't get it to work properly in my env, especially with eclipse 3.1. It maybe a little selfish to request an update, just because of me not getting my setup to work, but svn has improved so much from 1.1.x to 1.2.x so it might be usefull for everyone. Regards Benjamin" Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/606fa218/attachment.html From richie at vtiger.com Thu Jul 6 22:28:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:28:56 -0700 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com Message-ID: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Hi! Is the vtiger-demo.fosslabs.com updated with the bleeding edge code please? Matt, I guess, we are putting a lot of stress on you alone and it is not fair. Do you think you require some guys from the community to assist you? My main concern is that not any single individual be overloaded. vtiger is team-work and it should be that way. Everyone should prosper. Dedicated volunteers please raise their hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/4782857f/attachment.htm From richie at vtiger.com Thu Jul 6 22:31:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:31:56 -0700 Subject: [Vtigercrm-developers] Trac 0.9.6 released In-Reply-To: References: Message-ID: <10c47788588.1738553798220722432.6769330270375144874@@vtiger.com> Let us get this upgraded then. Jeff, would you take ownership for all the 3rd party upgrades please. I know you are already tracking the 3rd party packages but what I am stating is to take ownership for all upgrades for the s/w used to keep track of vtiger? If you need assistants, give a shout in the mailing list. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/1aaf8fb0/attachment-0001.html From webmaster at vtigerfacile.com Fri Jul 7 06:40:11 2006 From: webmaster at vtigerfacile.com (=?UTF-8?B?QcOvc3Nh?=) Date: Fri, 07 Jul 2006 15:40:11 +0200 Subject: [Vtigercrm-developers] trac account In-Reply-To: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Message-ID: <44AE643B.1040800@vtigerfacile.com> Hi Richie, i have a login for track, but not the right to submit ticket. thanks, A?ssa (very busy !) Richie a ?crit : > Hello! > > I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. > Please cross-check if you have received the relevant mails in the id from which you had made the access > request. > > Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. > > richie at vtiger dot com > > Richie > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Fri Jul 7 20:23:02 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 21:23:02 -0600 Subject: [Vtigercrm-developers] New communications system Message-ID: <1152328983.32174.36.camel@localhost.localdomain> I wrote a new CommSystem module in my 5.0.2-MMBRICH branch. The comm system is a full replacement for the chat system from RC1 and also adds a host of API's to manipulate it from your favorite external system or vtiger module :). Here is a short list of features, any testers or patches to help move it along are appreciated. Features: 1) Full P2P chat 2) Session/Off-line messaging capabilities (ie: if a new message comes in right when you click on a link in the system, when the new page loads you will see the message that appeared as the page was being reloaded). 3) Follows your window focus. If you have multiple tabs open in the CRM, you will only get new messages and status messages in the focused window. All messages are cached when there is no focus on a CRM window. 4) Alert/Event messages. An "MSN like" status box that appears at the bottom of your browser to alert about new emails, voicemails, incoming calls, etc. It has pretty effects to make it slide in and out for alerts :). 5) "User is typing" status messages. 6) Email messages from either periodic checks via JSON or can also be injected via scripts. (Ie: incoming emails to helpdesk at domain.com could be announced to users x,y and z) 7) Simple CommSystem.php and CommSystem.js classes to manipulate the alerts and chat system. CommSystem.js is wrote to follow prototype standards as much as I could get it to. ToDo: 1) Finish the group IM feature. 2) Lots of ugly, needs UI work. 3) Support Portal integration ("Chat with Live Help" links in the portal) 4) Message archives so that old messages can be deleted from the CRM (maybe a monthly cron script to backup and delete the messages from the DB). 5) Asterisk AGI Script and SOAP functions to inject Voicemail or Incoming call alerts 6) Cron scripts to populate email alerts? 7) Fix annoying bugs (Ie: '\n\r' breaks sending messages) 8) Internationalization 9) Test, test, test 10) Jabber connector? Drawbacks to this system: 1) Makes a request to the server every N milliseconds to check for new messages, alerts or status updates. This gets heavy on the server. One way to take load off the server is with the focus tracking mentioned above. Un-focused windows will not make requests back to the server. Another way is to create a decay timer like the one used in the prototype Ajax.PeriodicalUpdater() class. This basically checks the last output status and compares it to the current output status. If they are the same then N = (N*) and if the current output status is diff than the last output status N=(N). 2) The whole system is one large timer loop and global references to the CommSystem.js class have to be created to access the class within the loop. This is a memory usage issue but shouldn't be too noticeable for most. 3) Probably a 70% client side and 30% server side system. Thats a lot of javascript. If you get a chance to check it out, let me know what you think and if you'd like to see something like this in vt5 going forward. Matt From mmbrich at fosslabs.com Fri Jul 7 21:15:14 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 22:15:14 -0600 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com In-Reply-To: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> References: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Message-ID: <1152332114.32174.40.camel@localhost.localdomain> On Thu, 2006-07-06 at 22:28 -0700, Richie wrote: > Hi! > > Is the vtiger-demo.fosslabs.com updated with the bleeding edge code > please? I updated it the day RC1 came out but haven't since then. It is currently not automated. > Matt, I guess, we are putting a lot of stress on you alone and it is not fair. > Do you think you require some guys from the community to assist you? > > My main concern is that not any single individual be overloaded. vtiger is team-work and > it should be that way. Everyone should prosper. The workload isn't too bad yet but any help is more than welcomed! > Dedicated volunteers please raise their hands! Matt From richie at vtiger.com Mon Jul 10 05:36:35 2006 From: richie at vtiger.com (Richie) Date: Mon, 10 Jul 2006 05:36:35 -0700 Subject: [Vtigercrm-developers] move to trac-0.9.6 Message-ID: <10c58706195.1364243099676550119.-2686427800793695304@@vtiger.com> Hi! Anyone game to help us move to trac-0.9.6 so that we can utilize the latest and greatest features? Matt, send me a mail with the access to the machine. Also let me know what steps to follow to upgrade. If no one does it, I will have it done. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/cc4fdd2a/attachment.htm From mmbrich at fosslabs.com Mon Jul 10 14:09:03 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 15:09:03 -0600 Subject: [Vtigercrm-developers] UI help Message-ID: <1152565743.32174.120.camel@localhost.localdomain> In case no one noticed in the past I suck @ UI design so I figured we would see who wants to step up to the plate on this one. Right now I need the following things, if you want to take one just say so that way no one else duplicates your work. 1) De-Duplication system for settings module. I want this to be able to delete/merge/etc records that can be matched based on certain criteria. I'll write the search engine and logic system to merge/de-dup if someone wants to take on the UI :). I was thinking about having this work in steps. Step 1: select search criteria. Step 2: display duplicate results that are candidates for merge/delete, un-select records from the list via checkbox. Step 3: Select fields to merge or other action to take (delete). Step 4: Execute actions. There was a bounty on this in the forums. If that pans out you'll get a chunk, let me know what you think is fair for your time/effort. 2) Geolocation/Action tracking for email campaigns. This will be a simple popup window that should show a list of the commands from that email (ie: open, followed link, unsubscribed, etc) in one html tab and then the google map to show the actual locations those commands were executed at in another tab. Most likely I will just push one XML descriptor up to google maps to display the country/state/town the email was opened in, but I want to be able to push multiple XML descriptors to google in cases where more than one location is tracked. These extra descriptors can be used to mark possible forwards for that email. Along with this feature we'll need a simple settings area to input your google maps key. 3) Default email unsubscription page. This is a simple page that is visited when a user clicks on the 'unsubscribe' link in emails. The page should have a nice header, a hello message or something, give the user a choice to unsubscribe from that campaign or from all lists in the CRM and then display a success or failure message depending on the result from the CRM's attempt to remove them. If the unsubscribe fails the page should display the company info from the DB so that the user can write in or call to have their information removed. 4) Workflow module? I thought I saw a post that the vtiger crew was going to take this on. If thats the case then this one is void and we don't need to worry about it. Otherwise, go check out the bounty, let me know what you think is a fair cut for your work, then submit me your ideas. If the bounty pans out you'll get a cut of course. 5) Communications system. This is built and ready enough for beta. I need a p2p chat window, group chat window, right hand 'slider' (to show who is online, etc) and we should probably do something with the alert slider as well, it's very plain. The fun part about the chat windows is that none of them are built with HTML so you'll have to do most of the design in CSS. You can also look into the scriptaculous Builder() function for more info on how I create the chat windows, there is flexibility in how you can design them so you're not necessarily restricted to css only. Also could use a chat window for the customer portal if you're up to it :). 6) Direct Mail Designer. This is still on the drawing board but it would be super cool. The idea is to have a list of templates in the "Direct Mail" campaigns that could be merged with the campaign records. Sounds familiar right? Well it would build off of the current merge system by allowing .rtf and .odt files to be merge templates but would also make use of a 'packaging' standard. Basically this packaging (a tarball or zip file) would have a templatename.xml file that would have things like params and thumbnail images and other useful information for merging, etc. This has the ability to have services packaged around it (like we could define an API for designers to make their designs available for pre-set prices and also printing companies to actually do the printing.) Lots of possibilities, if you decide this one is interesting, email me on or off list and we can start a discussion about how this could work. This is candidate for a forge project so if there is enough interest I might just open one. All of this stuff is being created in my branch. I'll give you access to my sandbox area on vtiger-demo.fosslabs.com so you can track stuff and help out. I have every intention of doing these myself if no one takes them, but I can say that I have no skill in UI design whatsoever :). Matt From mmbrich at fosslabs.com Mon Jul 10 20:58:53 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 21:58:53 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590333.16985.2.camel@localhost.localdomain> This is an example screen of what I would like to do for managing campaign actions. If there is a way to tell the campaign type, even when using a diff language or changing the picklist, then I wouldn't have to show every single action. Opinions? Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-24.png Type: image/png Size: 66134 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/86b7c2be/Screenshot-24-0001.png From mmbrich at fosslabs.com Mon Jul 10 21:02:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 22:02:49 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590570.16985.4.camel@localhost.localdomain> Here is a screenie of the current comm system if anyone wants to give suggestions. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-25.png Type: image/png Size: 77505 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/854ed82e/Screenshot-25-0001.png From dgrant at accuratetechnologies.com Tue Jul 11 11:12:38 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 11 Jul 2006 14:12:38 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG From jtk at yahoo.com Tue Jul 11 14:12:32 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Tue, 11 Jul 2006 17:12:32 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone From sergiokessler at gmail.com Tue Jul 11 15:37:23 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 11 Jul 2006 19:37:23 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> dennis, On 7/11/06, Dennis Grant wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak From mmbrich at fosslabs.com Tue Jul 11 18:58:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 19:58:10 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <1152669490.16985.122.camel@localhost.localdomain> > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt From mmbrich at fosslabs.com Tue Jul 11 21:06:12 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:06:12 -0600 Subject: [Vtigercrm-developers] 5.x webmail changes Message-ID: <1152677172.16985.144.camel@localhost.localdomain> I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt From mmbrich at fosslabs.com Tue Jul 11 21:20:56 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:20:56 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152590570.16985.4.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> Message-ID: <1152678056.16985.149.camel@localhost.localdomain> I'm going to keep posting these hoping that someone will finally get fed up with the ugly and help out ;). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-26.png Type: image/png Size: 90999 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/Screenshot-26-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-27.png Type: image/png Size: 67631 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/Screenshot-27-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-28.png Type: image/png Size: 90831 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/Screenshot-28-0001.png From saint at vtiger.com Tue Jul 11 23:09:35 2006 From: saint at vtiger.com (Saint) Date: Wed, 12 Jul 2006 11:39:35 +0530 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152678056.16985.149.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> Message-ID: <44B4921F.8020402@vtiger.com> Matt.. I am aware that, the campaigns module is fairly attended in the UI front. I am in the middle of other works. So give me a few more days.. I will hop in and check it out :-) -Saint Matthew Brichacek wrote: > I'm going to keep posting these hoping that someone will finally get fed > up with the ugly and help out ;). > > Matt > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90999 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 67631 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90831 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0005.png From dgrant at accuratetechnologies.com Wed Jul 12 06:41:28 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 12 Jul 2006 09:41:28 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) { bar; } vice if ($foo) { bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG From sergiokessler at gmail.com Wed Jul 12 06:48:28 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Wed, 12 Jul 2006 10:48:28 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From jtk at yahoo.com Wed Jul 12 07:06:57 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Wed, 12 Jul 2006 10:06:57 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). From mmbrich at fosslabs.com Wed Jul 12 08:16:41 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:16:41 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <1152717401.16985.280.camel@localhost.localdomain> On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt From mmbrich at fosslabs.com Wed Jul 12 08:48:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:48:52 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <1152719332.16985.289.camel@localhost.localdomain> I have started doing the query part as I run into them in my branch. I'm also moving the query strings out of functions like get_leads() and putting it in get_related_leads_query() instead. This way the query can be used for other things.. like for example if you want mostly the same output of get_leads() but without the HTML that manged to find its way out of the presentation layer and into the data layer... don't get me started on that. Anyways, with the HUGE db query strings that are used in the system, breaking them into separate short lines is a great suggestion for manageability and if it makes merges easier it's like getting your cake and eating it too :). Matt On Wed, 2006-07-12 at 10:06 -0400, Jeff Kowalczyk wrote: > Dennis Grant wrote: > > Actually, I think with VTiger you are going to see a lot of private > > forks, because individual businesses have their own needs and wants that > > are supersets of core VTiger functionality that simply don't apply to > > other businesses. > > This is one of the reasons why I care about making the source more > merge-friendly (particularly short, vertically formatted SQL statement > string lines). > > If we can get the codebase to the point where branching and merging is a > manageable burden, customization branches have a fighting chance to be > maintained in the repository. Or use a distributed repository such as > bazaar-ng can be used (bzr has a trac backend now). > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 10:16:13 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 11:16:13 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <44B4921F.8020402@vtiger.com> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> <44B4921F.8020402@vtiger.com> Message-ID: <1152724573.16985.290.camel@localhost.localdomain> Gracias, in the mean time I will keep working on the back-end and breaking stuff. Matt On Wed, 2006-07-12 at 11:39 +0530, Saint wrote: > Matt.. > > I am aware that, the campaigns module is fairly attended in the UI > front.I am in the middle of other works. So give me a few more days.. > I will hop in and check it out :-) > > -Saint > > > > > Matthew Brichacek wrote: > > I'm going to keep posting these hoping that someone will finally get fed > > up with the ugly and help out ;). > > > > Matt > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > ____________________________________________________________________ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 20:39:08 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 21:39:08 -0600 Subject: [Vtigercrm-developers] vtiger.fosslabs.com maint Message-ID: <1152761948.16985.311.camel@localhost.localdomain> I am going to shut the vtiger.fosslabs.com machine down this weekend for hardware upgrades. When I bring it back up I plan to snapshot and upgrade SVN. Expect the access to the system to be spotty over the weekend. I am tentatively scheduled to do the work on Saturday evening @ 11PM MST but that may change depending on other upgrades being done at the same time. Matt From richie at vtiger.com Thu Jul 13 01:43:03 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:43:03 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670da880.830325448603459473.-9072372394275150906@@vtiger.com> Hi DG! Your comments are well taken. These will be in place at the earliest. I know that this will be a quick fix but instructions have been sent across to have the code properly commented from now on for any future development/bug fixes. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/488cba6b/attachment.htm From richie at vtiger.com Thu Jul 13 01:44:36 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:44:36 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670f131a.7768422503650913231.-7005067799642887197@@vtiger.com> I am game for it . Any takers? What is the procedure and how do we guarantee that there are no breakages? Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f2aae45a/attachment.html From richie at vtiger.com Thu Jul 13 01:46:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:46:05 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <10c67107064.-1678188602298141788.6045287401021222103@@vtiger.com> I second /sak. Contribute your code and we will have it in the 4.2.x branch and then have it subsequently ported to the 5.x too. We could have done it much earlier but it is far too late to get any contributions into 5.x at this stage. As far as possible, keep your changes in separate files so that they can be function invoked from the core code. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- dennis, On 7/11/06, Dennis Grant <dgrant at accuratetechnologies.com> wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/8bd60cb5/attachment.htm From richie at vtiger.com Thu Jul 13 01:49:51 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:49:51 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <10c6713e13e.2152742122979094039.4943172801070965118@@vtiger.com> I agree with Matt. We have just started to work on a API-basis. The APIs will be difficult to use initially no doubt. I expect the APIs to be APIs like by 5.2 only as it is a huge change in mindset. Moreover, whatever APIs we have now, have to be properly documented and made much more usable. Matt has pointed out quite a few lacunaes and I do assure you that we do intend to fix them. Guidance and direction on the implementation toward achieving the same are welcome. To all System Integrators, yes, I do understand your pain. But, please understand getting rid of legacy code is much easier said than done. As of now, we will have to live with what we have. Post 5.0, we will make appropriate changes. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/889d7c68/attachment-0001.html From richie at vtiger.com Thu Jul 13 01:51:01 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:51:01 -0700 Subject: [Vtigercrm-developers] 5.x webmail changes In-Reply-To: <1152677172.16985.144.camel@localhost.localdomain> References: <1152677172.16985.144.camel@localhost.localdomain> Message-ID: <10c6714f425.4775035562108243105.2718638484930626999@@vtiger.com> No probs Matt. If it does not work, let us give what works the best way we can. We will revisit this later. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/23b5e029/attachment.htm From richie at vtiger.com Thu Jul 13 01:54:53 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:54:53 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c67187bff.-5041963494012382301.4384583989565056693@@vtiger.com> I take all your comments with eyes closed. Kindly expect the changes asap. Please do refer to my prev mail. Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless. So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now. The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) {  bar; } vice if ($foo) {  bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/6f714b17/attachment.html From richie at vtiger.com Thu Jul 13 01:56:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:18 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <10c6719c9f2.-6173366446330663734.-8914245299430889257@@vtiger.com> Well, well, /sak, hold on! We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)! Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/609744b4/attachment-0001.htm From richie at vtiger.com Thu Jul 13 01:56:58 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:58 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c671a6747.4209201887890377357.8473992930050161702@@vtiger.com> Ok Jeff. This is new to me. Guide me on this. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/1901e1ee/attachment.html From richie at vtiger.com Thu Jul 13 01:58:39 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:58:39 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152717401.16985.280.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> <1152717401.16985.280.camel@localhost.localdomain> Message-ID: <10c671bf103.1188771339393133750.-7786000437306059540@@vtiger.com> I agree with you Matt. I will post a separate mail to have the private forkers to have their codes submitted for integration to whichever trunk needed. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/dca318ca/attachment.htm From richie at vtiger.com Thu Jul 13 03:46:19 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 03:46:19 -0700 Subject: [Vtigercrm-developers] Calling all private 4.x development owners Message-ID: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Hi! This is a call to all the 4.x private development owners. Many of you would have been working on your own version of vtiger as you would have customized it to your own needs. This is a call for those guys. The intent is to aggregate most of the common features that you have built and have them integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch or even in the 5.x branch as needed by the community. Pros: By doing the above, you will be able to be in sync with the latest and greatest developments happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a read as one would think of but we are working on it. Yesterday we had comments about the code not being properly commented, we are working on that right now even as I type this post. So, the idea I am conveying is that we are not perfect but are listening to the comments and taking actions too. Hence, please do keep the faith. Cons: By maintaining your own code bases, you lose out on the community benefits like identifying bugs, feature integration, new ideas, etc. We welcome your contributions. Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise the folly. Let us get on with it and make vtiger a success. I have learnt from my past mistakes. Join the team, come on board. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/65c2edda/attachment.html From dgrant at accuratetechnologies.com Thu Jul 13 07:47:52 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 10:47:52 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... Yeah, but is it worth it? The 4.x codebase is really - sorry guys, I don't mean to take shots at you - but let's face it; it's really very nasty. Some of it is a good deal better than others... but there are three or four different coding paradigms all mixed together just on database queries alone, never mind display models and modularity and whatnot. It *works* great, but it's a serious bitch to maintain. As I mentioned earlier, I haven't looked at the 5.0 codebase, but it is my hope and expectation that it is a lot better. > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, No kidding.... > and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > I mean, if you are going to fork, then fork in all it's glory... Dude, I *NEVER* wanted to fork. I'd be *MUCH, MUCH* happier if I could run a vanilla install of VTiger with zero custom code in it. I was forced into forking by a lack of response from the core dev team, yes - but more so by the fact that I had users who wanted features and I needed to get them done NOW. > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Ahem. I tried to get patches into the core. I tried to get the dev team to do stuff by reporting bugs and providing detailed debug info. But there are limits as to how much time in a day I can burn trying to get an unresponsive dev team to fix my bug. "Why is this still broken?" "Well, I reported it to VTiger last month, and they haven't fixed it yet....." That just doesn't cut it. > My point was that we should find > a way to welcome these wayward forks back to the fold. How? I dunno.. Well, the way I'm going to do it is to roll all my features into 5.0 (which is a huge job, but so it goes) and then cut a patch set for merging into the main core. My expectation is that VTiger's version of Linus (or Alan Cox, or whoever) will then go through the patch set, and then either merge or reject patches based on merit - just like in the kernel. I will then work on trying to address concerns with my rejected patches, so as to get them accepted, except in cases where the patch is clearly local in scope - and those I will maintain myself. BTW, who is the local Linus? > So after the wind clears.. my point really comes down to getting all > these folks who are working on private forks to come back to the > community project, regardless of their justification (or lack of) for > the fork. In an OSS project your most valuable resource is your > developers and if we can find a way to get them back it will be well > worth it IMHO. I agree - and the best way to do that is to be RESPONSIVE. I understand that *my* problem may not be the top priority. I understand that core dev team members are NOT going to just drop everything and look after me. But I *do* expect a response, and to get into the pipeline, and to be given reasonably regular status updates on the status of my problem. And if I submit a patch, I expect it to be reviewed and either accepted or rejected in a reasonable timeframe. I don't know how many of you were/are involved in Linux kernel development, but I used to get help from people like Alan Cox and Linus on a regular basis. If a particular bit of hardware wasn't working, and it looked like a bug in Linux kernel code, we'd trade emails on a daily basis to debug the problem. That's the level of service we're talking about. And this is a good start: > Your comments are well taken. These will be in place at the earliest. > I know that this will be a quick fix but instructions have been sent > across to have the code properly commented from now on for any future > development/bug fixes. Thanks! DG From sergiokessler at gmail.com Thu Jul 13 08:40:25 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Thu, 13 Jul 2006 12:40:25 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> Message-ID: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak From allan.bush+vtiger_dev at gmail.com Thu Jul 13 08:59:48 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Thu, 13 Jul 2006 08:59:48 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From dgrant at accuratetechnologies.com Thu Jul 13 09:10:09 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 12:10:09 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CD8@exch.accuratetechnologies.com> > > BTW, who is the local Linus? > unfortunely, there is no local linus, Who is in charge of V5? Who is the core dev team leader? > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) Uh... thanks, but I'm going to have to pass. At this point, with V5 (seemingly) approaching completion, V4 is a dead end. I intend to move forward on V5 and get away from V4 as fast as I can. DG From jeri at vtiger.com Thu Jul 13 18:04:37 2006 From: jeri at vtiger.com (Jeri John) Date: Thu, 13 Jul 2006 18:04:37 -0700 Subject: [Vtigercrm-developers] Latest Docs updated Message-ID: <10c6a904f47.6172353167700401689.-5432537231218327818@@vtiger.com> Dear team, The latest Docs for vtigerCRM 5.0 beta 2 is updated, and it is available in the following url. http://vtiger.com/products/crm/phpdocs/index.php Thanks & Regards, Jerry. ------------------------------------------ D.Jeri John Skype: jerijohn_vtiger Toll Free: +1 877 788 4437 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f9eb2259/attachment.htm From mmbrich at fosslabs.com Thu Jul 13 18:16:45 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 19:16:45 -0600 Subject: [Vtigercrm-developers] Custom fields for activities Message-ID: <1152839806.16985.560.camel@localhost.localdomain> Does anyone have plans to implement custom fields in the activities module? Matt From mmbrich at fosslabs.com Thu Jul 13 19:16:38 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 20:16:38 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <1152843399.16985.611.camel@localhost.localdomain> I have some ideas for cleaning up the structure of vtiger as we move forward. I am just going to lay them out here, let me know what you think. My basic idea comes down to writing wrapper classes that are used to abstract most of the unnecessary functions from developers and instead provides a uniform API to access modules, permissions, input, etc. The idea comes in three pieces. Common UI classes, most of which is already done with the new UI. A "mainframe" engine similar to the joomla $mainframe. And last but certainly not least is an entity engine that would abstract most of the entity details from developers and truly provide the unified API. Lets start with the big one, Entity Engine: The entity engine would be accomplished in three steps. The first step is to move all common variables and functions into the EntityEngine class (which extends CRMEntity). The entity engine would go into the DB to populate these with the correct info. For example tab_name, tab_name_index and all the other most common variables would be stored in the db and populated when the entity engine has a request for that module. The next step would be to create common set of functions in this class that would be exposed to the developer. The initial functions I can think of are things like get/set functions for different field values, etc. The last step to the entity engine would be an XML install system. If a developer came along and wanted to create a simple data collection module, like the current campaigns module, they would simply create an XML file that defines all the fields to be displayed, what relationship types are allowed, etc. The entity engine would then create the correct tables, populate the needed tables for the entity engine (the ones holding tab_name, etc) and register the new entity type with the system. This leads into the UI system because if the developer is just creating the XML file, how are common views displayed (list, detail, edit, relatedlists)? The UI system would be a set of classes to extend smarty and again abstract the gory details of the internal workings from the developer. VTigerUI::DetailView($entity) would follow a flow: 1) Display all common elements (header, etc): $this->createTigerHeader(); 2) Display the common 2 tab display for edit/detail/related views $this->getCommonUI("DetailView"); 3) Create a block for each block type in the DB, and create the fields for it as well. $this->assign("NUM_BLOCKS",sizeof($entity->blocks)); foreach($entity->blocks as $blockid=>$fields) { $block_fields = array(); foreach($fields as $fieldname=>$field_data) { $block_fields = $this->CreateEditField($fieldname,$field_values); // creates new edit fields based on uitype and returns an array as $array[sequence_number] = "HTML output" } $this->assign("BLOCK_".$blockid,$this->addBlock($blockid, $block_fields)); } 4) Display data :) And just like magic, the ListView, DetailView, EditView and CallRelatedList files can all go away and these common views can be managed in a much easier way. Next, the mainframe. In joomla (as far as I understand) the mainframe is meant to handle all GET, POST, REQUEST and SESSSION variables and it also sanitizes that input before giving it to the developer ($mainframe->get_input("REQUEST","data")). On top of this it handles some user security and other things. In vtiger I could see it being used for many similar things. Take for example the CreateDetailField() function call above. Inside of this call would be: if($mainframe->is_allowed("Detail",$field->id)) { stuff.. else return; There are still other details to be worked out, but you see that this isn't a _really_ large change for the flexibility it will give you in the system. After it's all said and done you should have two sets of documents that a developer would have access to, the module developers document that would be a document outlining the three pieces discussed above and then the core developer document that would document all the core back-end functions (everything in utils/). Of course there would be a way to overwrite these methods so that developers can still create non-entity based modules (webmails, calendar, rss, etc), but it should make life much easier for module developers who follow the entity structure in vtiger. What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well. Matt From Matjaz.Slak at atol.si Thu Jul 13 23:42:52 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak@atol.si) Date: Fri, 14 Jul 2006 08:42:52 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: Hi! If there's no one else, I volunteer to be the v4 Linus. I have the exact same position as a lot of other people wrote about here - basically my own fork of v4.2.3, and I'm now working to get my patches compatible with v4.2.4 so as to get back to the main trunk. And it's a lot of work, which I need to trade with my basic task - which is supporting several customers we have on vTiger. I hope I will have my set of patches (there might be up to 100 of them, as it's looking right now :) ready in a week or so. I belive we as vTiger Dev team should provide more support for 4.2.x stream -> I guess that almost ALL of vTiger's "real world" users use that right now. And they might go for v5 when it's stable, but that won't be (in my experience) for at least 6 months after it's released. If you want me, I'm here. Just give me a direction to start in, and I (and my three colleagues here) can be reviewing submitted work in no time. And discussing it with you the team here to get decissions on include/reject. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Sergio A. Kessler" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:40 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/smime-0001.bin From Matjaz.Slak at atol.si Thu Jul 13 23:43:51 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak@atol.si) Date: Fri, 14 Jul 2006 08:43:51 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> Message-ID: Hi! Allan, if you need any help, let me know (see my previous post). Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Allan Bush" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:59 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/smime.bin From dgrant at accuratetechnologies.com Fri Jul 14 06:24:34 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 09:24:34 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG From allan.bush+vtiger_dev at gmail.com Fri Jul 14 07:32:02 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 07:32:02 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Proper use of a OO design would solves this for both of you. All the common code and default module behavior should be moved into the a set of default classes or "engines" as Matthew is calling them. Then for each module we inherit the classes and make a couple method calls (ideally this is abstracted as well so to create a module all you do is create a class which inherits the base class) which generates the required database actions / html page. If you want something different then the default, like Dennis describes, you simply extent the required method in your inherited class. This way the common code is abstracted and only needs to exist once while the module specific code is in the module for easy modification. The code is already partly structured this way (it's just not used properly). There's already a base class CRMentity which every module inherits from. What needs to be done is to clean up the CRMentity - module relationship so that only methods common to all modules and their default behavior is defined in CRMentity and only things which need to be changed are defined in the module class. Then we need to create a class for each page type (again some of this already exists. ala inculdes/Listview.php, but here it isn't used at all) with the default behaviors of each page type. Now we have an option, either we have each module inherit these page type classes (making changes as needed ala CRMentity) and have a common set of calls to render each page type or we create a SMALL file in each module with a couple of calls to the page type class to render the page and we substitute new functions as needed for customizations. Personally I think the first option here is the better design, but unless you get it right it could become difficult to modify the parts of the page you want without re-witting a lot of the base class (should be avoided at all cost or we're right back in the mess we are in now). That was a bit of a long winded explanation, let me know if anyone requires clarification. On 7/14/06, Dennis Grant wrote: > > > My basic idea comes down to writing wrapper classes that are used to > > abstract most of the unnecessary functions from developers and instead > > provides a uniform API to access modules, permissions, input, etc. > > Oooh. > > > The idea comes in three pieces. Common UI classes, most of which is > > already done with the new UI. A "mainframe" engine similar to the > > joomla $mainframe. And last but certainly not least is an entity > engine > > that would abstract most of the entity details from developers and > truly > > provide the unified API. > > To be honest, I think this is moving in the wrong direction. > > If everybody used the same vanilla VTiger installation, this would make > a lot of sense - one common UI for the entire set of users, and a much > cleaner codebase for developers. Happy happy for everybody. > > Unfortunately, a lot of us are NOT using vanilla VTiger; we have to > customize the application to meet the needs of our user base. And a lot > of the time, our users really really want changes that may seem utterly > trivial from a developer standpoint, but for whatever reason, they > REALLY want it that way. > > And the customer is always right, so we have to do it. > > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. > > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. > > Yes, it makes changing common code more difficult, 'cause now I have to > drill down into each submodule and make the same change over and over > again, and I can certainly see where modularizing and sharing code makes > that job a lot easier. But the assumption it is based on, while true of > a vanilla install, is NOT true in a customized install environment. > > I'd prefer to see every module live in its own subdirectory of the > modules directory, much as is does in 4.x, but more rigorously (ie, > separate Sales Orders from Purchase Orders, don't group them in Orders) > and each module should have its own, atomic codebase. > > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. > > I'd like to see some standardization on the module file structure > though: > > modules/Foo/EditView.php for the edit UI for the module object > modules/Foo/DetailView.php for the detailed view of the object > modules/Foo/Save.php for saving the object to the DB > modules/Foo/CreatePDF.php for creating a PDF version of the object > modules/Foo/UIElements.php for the common UI functions (that are now > stuffed in include/utils.php > modules/Foo/BarPopup.php if there is a popup window to select associated > Bar objects > > etc. > > It makes dealing with modules easier if we know where the various > functions are kept. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From isimpkins at premierrealm.com Fri Jul 14 08:10:32 2006 From: isimpkins at premierrealm.com (Ivar Simpkins) Date: Fri, 14 Jul 2006 17:10:32 +0200 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: Sorry DG this doesn?t wear with me. 'The price of programmability' is what it's about. There is the short term solution and it has its merits, but planning a structured API can only have its long term benefits. Where does vTiger want to be in the future, this has to be answered. If it wants to be in the top ratings, then I think every effort has to be made, to reconsolidate and then plan for the future. Sure the learning curve is steep but the rewards are enormous. Would it not be better to prefect a generic function, in an OO structure which does all you want, one entrance, one exit and away you go. A well documented code base that automatically builds your API documentation gives you a valuable toolbox, now concentrate the communities efforts on pulling together and raising the lowest common denominator and you have a work the progresses moving a an incredible rate. And as Matt said: 'What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well.' NO, you are not nuts, it gives you the long term ability to use ones creativity to best avail without (always) having to worry about the nuts & bolts. I think this is a courageous step in the right direction, where, after surviving the learning curve, all will benefit, creating a homogeneous standardised kernel, with the ability of Plug 'n Play ala Joomla and probably much more. 'The price of programmability' is high but seeing the caliber of work produced so far, I am convinced Matt is on the right track to creating a new dimension in CRM. Please excuse the tone but its hard to see the same mistake been made over and again. Ivar > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 From mmbrich at fosslabs.com Fri Jul 14 09:54:21 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:21 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Message-ID: <1152896061.16985.648.camel@localhost.localdomain> On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > Proper use of a OO design would solves this for both of you. > > All the common code and default module behavior should be moved into > the a set of default classes or "engines" as Matthew is calling them. > Then for each module we inherit the classes and make a couple method > calls (ideally this is abstracted as well so to create a module all > you do is create a class which inherits the base class) which > generates the required database actions / html page. If you want > something different then the default, like Dennis describes, you > simply extent the required method in your inherited class. This way > the common code is abstracted and only needs to exist once while the > module specific code is in the module for easy modification. I think we're right on the same page here, but if you take for example the Campaign.php class, it should not be needed. All of the functions and variables it defines are generic and do not need to be re-created for each module that does simple data collection and display. If you want to write a module that does more than this, and will need it's own class, by all means, extend the EntityEngine class (or CRMEntity if it becomes the engine) and then continue on your way. > > The code is already partly structured this way (it's just not used > properly). There's already a base class CRMentity which every module > inherits from. What needs to be done is to clean up the CRMentity - > module relationship so that only methods common to all modules and > their default behavior is defined in CRMentity and only things which > need to be changed are defined in the module class. But even things that need to be changed, may not need to be changed and defined in separate module classes. For example all the get_leads, get_contacts, etc functions can be standardized and instead use a set of DB keys to track relationship_types allowed for a module. function get_leads($id,$entity) { if($this->is_relationship_type($entity->module,"Leads")) { stuff.. } else return false; } > Then we need to > create a class for each page type (again some of this already exists. > ala inculdes/Listview.php, but here it isn't used at all) with the > default behaviors of each page type. Now we have an option, either we > have each module inherit these page type classes (making changes as > needed ala CRMentity) and have a common set of calls to render each > page type or we create a SMALL file in each module with a couple of > calls to the page type class to render the page and we substitute new > functions as needed for customizations. Personally I think the first > option here is the better design, but unless you get it right it could > become difficult to modify the parts of the page you want without > re-witting a lot of the base class (should be avoided at all cost or > we're right back in the mess we are in now). Correct, and I think if you created the correct UI classes you could very easily overwrite the functions you want to customize and _only_ the functions you want to customize (like AddBlock() for example). > That was a bit of a long winded explanation, let me know if anyone > requires clarification. I think we're pretty close to being in the same school of though but maybe I needed to explain my thoughts in a bit more detail. I really just laid out a very high level overview of what I think should be done. Matt From mmbrich at fosslabs.com Fri Jul 14 09:54:58 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:58 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <1152896098.16985.650.camel@localhost.localdomain> > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. So in these cases you could over-ride the system DetailView by creating /Accounts/DetailView.html.php for your actual HTML stuff, and /Accounts/Detailview.php if you want to change the logic flow. If you are only changing the look/feel, then re-declare the AddBlock() function with your new special sauce inside of it and off you go. > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. See above, the correct separation of these layers in the system can still give you the flexibility you need. > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > To create new field types it would just be a matter of creating a new UIType, populating the DB fields you want to have that uitype (via XML), and then creating the base HTML for it in the UIType.tpl file. {if {$uitype} == "230"} your_new_html {/if} On top of this you could just over-ride the system UI creator and replace it with your own display classes. > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. I actually think the entity engine will need to have a query builder in it so that the queries can be built dynamically depending on the type of data you are going for. A true entity engine (like the one in ofbiz.org) will not ever let you see a query, nor should you need to if the entity engine is doing it's job correctly. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. i hate utils.php :). But the examples you lay out above would not at all be impossible. You would simply tell the entity engine (via an XML file) that you want a seqno and header value assigned to each entity of type=Quotes, and then in the query builder it will check for seqno and if it find it, ORDER BY seqno will be appended to the query string. Really what I am trying to accomplish is to make your life easier in the long run than what it currently is, even when diverging from the standard way of doing it with-in vtiger. There is a learning curve that will come along with this but correct documentation and developer support via this mailing list should help you get past any of that. Matt From allan.bush+vtiger_dev at gmail.com Fri Jul 14 10:13:28 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 10:13:28 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <1152896061.16985.648.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> Message-ID: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> I'm pretty sure we're on the same page Matt, my reply was more of an attempt to convince Dennis then an attempt to disagree with anything you said. In your example though I'm not sure how much I like having a function called "get_leads" in the base class. I think there's way too much coupling between "modules" right now and I'd like to get away from that, however I'm not sure what the best way to do that is without losing any of the control we currently have. That's probably another discussion though. I agree with your design, I could probably argue all day over the implementation of the details, but as long as it's constant and logical I don't care too much. On 7/14/06, Matthew Brichacek wrote: > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > Proper use of a OO design would solves this for both of you. > > > > All the common code and default module behavior should be moved into > > the a set of default classes or "engines" as Matthew is calling them. > > Then for each module we inherit the classes and make a couple method > > calls (ideally this is abstracted as well so to create a module all > > you do is create a class which inherits the base class) which > > generates the required database actions / html page. If you want > > something different then the default, like Dennis describes, you > > simply extent the required method in your inherited class. This way > > the common code is abstracted and only needs to exist once while the > > module specific code is in the module for easy modification. > I think we're right on the same page here, but if you take for example > the Campaign.php class, it should not be needed. All of the functions > and variables it defines are generic and do not need to be re-created > for each module that does simple data collection and display. > If you want to write a module that does more than this, and will need > it's own class, by all means, extend the EntityEngine class (or > CRMEntity if it becomes the engine) and then continue on your way. > > > > > The code is already partly structured this way (it's just not used > > properly). There's already a base class CRMentity which every module > > inherits from. What needs to be done is to clean up the CRMentity - > > module relationship so that only methods common to all modules and > > their default behavior is defined in CRMentity and only things which > > need to be changed are defined in the module class. > But even things that need to be changed, may not need to be changed and > defined in separate module classes. For example all the get_leads, > get_contacts, etc functions can be standardized and instead use a set of > DB keys to track relationship_types allowed for a module. > function get_leads($id,$entity) { > if($this->is_relationship_type($entity->module,"Leads")) { > stuff.. > } else > return false; > } > > > Then we need to > > create a class for each page type (again some of this already exists. > > ala inculdes/Listview.php, but here it isn't used at all) with the > > default behaviors of each page type. Now we have an option, either we > > have each module inherit these page type classes (making changes as > > needed ala CRMentity) and have a common set of calls to render each > > page type or we create a SMALL file in each module with a couple of > > calls to the page type class to render the page and we substitute new > > functions as needed for customizations. Personally I think the first > > option here is the better design, but unless you get it right it could > > become difficult to modify the parts of the page you want without > > re-witting a lot of the base class (should be avoided at all cost or > > we're right back in the mess we are in now). > Correct, and I think if you created the correct UI classes you could > very easily overwrite the functions you want to customize and _only_ the > functions you want to customize (like AddBlock() for example). > > > > That was a bit of a long winded explanation, let me know if anyone > > requires clarification. > I think we're pretty close to being in the same school of though but > maybe I needed to explain my thoughts in a bit more detail. I really > just laid out a very high level overview of what I think should be done. > > Matt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From mmbrich at fosslabs.com Fri Jul 14 10:18:54 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 11:18:54 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> Message-ID: <1152897535.16985.654.camel@localhost.localdomain> On Fri, 2006-07-14 at 10:13 -0700, Allan Bush wrote: > I'm pretty sure we're on the same page Matt, my reply was more of an > attempt to convince Dennis then an attempt to disagree with anything > you said. > > In your example though I'm not sure how much I like having a function > called "get_leads" in the base class. I think there's way too much > coupling between "modules" right now and I'd like to get away from > that, however I'm not sure what the best way to do that is without > losing any of the control we currently have. That's probably another > discussion though. I'm not a big fan of how this is done either but you're right, this falls into another discussion about how to clean up current practices going forward with a new structure. > > I agree with your design, I could probably argue all day over the > implementation of the details, but as long as it's constant and > logical I don't care too much. Plenty of details that are yet to be worked out ;). Matt > > > On 7/14/06, Matthew Brichacek wrote: > > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > > Proper use of a OO design would solves this for both of you. > > > > > > All the common code and default module behavior should be moved into > > > the a set of default classes or "engines" as Matthew is calling them. > > > Then for each module we inherit the classes and make a couple method > > > calls (ideally this is abstracted as well so to create a module all > > > you do is create a class which inherits the base class) which > > > generates the required database actions / html page. If you want > > > something different then the default, like Dennis describes, you > > > simply extent the required method in your inherited class. This way > > > the common code is abstracted and only needs to exist once while the > > > module specific code is in the module for easy modification. > > I think we're right on the same page here, but if you take for example > > the Campaign.php class, it should not be needed. All of the functions > > and variables it defines are generic and do not need to be re-created > > for each module that does simple data collection and display. > > If you want to write a module that does more than this, and will need > > it's own class, by all means, extend the EntityEngine class (or > > CRMEntity if it becomes the engine) and then continue on your way. > > > > > > > > The code is already partly structured this way (it's just not used > > > properly). There's already a base class CRMentity which every module > > > inherits from. What needs to be done is to clean up the CRMentity - > > > module relationship so that only methods common to all modules and > > > their default behavior is defined in CRMentity and only things which > > > need to be changed are defined in the module class. > > But even things that need to be changed, may not need to be changed and > > defined in separate module classes. For example all the get_leads, > > get_contacts, etc functions can be standardized and instead use a set of > > DB keys to track relationship_types allowed for a module. > > function get_leads($id,$entity) { > > if($this->is_relationship_type($entity->module,"Leads")) { > > stuff.. > > } else > > return false; > > } > > > > > Then we need to > > > create a class for each page type (again some of this already exists. > > > ala inculdes/Listview.php, but here it isn't used at all) with the > > > default behaviors of each page type. Now we have an option, either we > > > have each module inherit these page type classes (making changes as > > > needed ala CRMentity) and have a common set of calls to render each > > > page type or we create a SMALL file in each module with a couple of > > > calls to the page type class to render the page and we substitute new > > > functions as needed for customizations. Personally I think the first > > > option here is the better design, but unless you get it right it could > > > become difficult to modify the parts of the page you want without > > > re-witting a lot of the base class (should be avoided at all cost or > > > we're right back in the mess we are in now). > > Correct, and I think if you created the correct UI classes you could > > very easily overwrite the functions you want to customize and _only_ the > > functions you want to customize (like AddBlock() for example). > > > > > > > That was a bit of a long winded explanation, let me know if anyone > > > requires clarification. > > I think we're pretty close to being in the same school of though but > > maybe I needed to explain my thoughts in a bit more detail. I really > > just laid out a very high level overview of what I think should be done. > > > > Matt > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From nolan at peaceworks.ca Fri Jul 14 10:44:55 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Fri, 14 Jul 2006 13:44:55 -0400 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Message-ID: <1152899095.32568.49.camel@rockcrusher> As one of the mentioned 4.2 developers mostly lurking on this list... Like others have mentioned, I've got 2 classes of modifications: 1. those _I think_ others may be interested in 2. those _I think_ others will not be interested in What I want to know is...is what _I think_ in any way connected with reality? More to the point... How do I know whether or not I *should* submit a given patch to the current tree for 4.2.5? In my previous (though admittedly minimal) exploration, I got the sense that 4.2.x was essentially "feature frozen" and that bug/security fixes and deployment/installation/maintenance stuff were fair game. For myself (and others like me), is 4.2 open for new features? If so, should we just continue to take it on ourselves to self-select those things _we think_ are more universal in nature? Should we try the shotgun approach (submit everything to 'Code Contributions' and see what gets picked up)? Is there a "proper place" to provide a list of changes we've made and give others the opportunity to speak for/against including them (or give a 'vTiger Linus' the opportunity to accept/reject them)? I think once I have a clear idea of how best to contribute, particularly to 4.2, I'll be more able to do so effectively. By the way, I think Matt's v5 architecture ideas are great, but they do muddy the waters for me a bit. Seeing those ideas, I have hope that something along those lines may be implemented, but it also makes me question *when* the right time will be to port some of my changes and additions to v5...I'd rather just do it once. peace, nokes On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > Hi! > This is a call to all the 4.x private development owners. > > Many of you would have been working on your own version of vtiger as you would have > customized it to your own needs. This is a call for those guys. > > The intent is to aggregate most of the common features that you have built and have them > integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch > or even in the 5.x branch as needed by the community. > > Pros: > > By doing the above, you will be able to be in sync with the latest and greatest developments > happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a > read as one would think of but we are working on it. Yesterday we had comments about the > code not being properly commented, we are working on that right now even as I type this post. > So, the idea I am conveying is that we are not perfect but are listening to the comments and > taking actions too. Hence, please do keep the faith. > > Cons: > > By maintaining your own code bases, you lose out on the community benefits like > identifying bugs, feature integration, new ideas, etc. > > We welcome your contributions. > > Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise > the folly. Let us get on with it and make vtiger a success. > I have learnt from my past mistakes. Join the team, come on board. > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Fri Jul 14 12:37:08 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 15:37:08 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> > Really what I am trying to accomplish is to make your life easier in the > long run than what it currently is, even when diverging from the > standard way of doing it with-in vtiger. There is a learning curve that > will come along with this but correct documentation and developer > support via this mailing list should help you get past any of that. Except that you're killing me with your good intentions. The life of an integrator doesn't permit steep learning curves and heavy abstractions; there just isn't time to do so. I've got a dozen different systems to get to play together, a boss screaming at me to get this stuff done yesterday, and no time to devote to learning whatever abstraction layer you've decided to implement. And Murphy's Law being what it is, if your abstraction model has one flaw, that will be the thing that my boss wants as his top priority. "Perfect is the enemy of good enough" I don't want "perfect"; I want "good enough" I want to be able to dive into the source and start modifying how the thing works *right now* without having to trace back a billion functions or wrap my brain around your object model. I don't have time to do so, because I'm simultaneously trying to play with a dozen other pieces of the puzzle. Guys, I have been playing this game for a LONG time. I have written major applications to perform mission-critical business functions.(At one time, if my code broke DaimlerChrysler stopped building cars) I have seen and dealt with thousands of software projects, both as a participant and as an observer, and almost without fail, every time somebody sets out to do the "perfect" object-based, extensible, customizable framework, it just leads to tears. I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. If you write code that any decent developer can pick up, find his bearings in a couple of seconds, and then comprehend *without* the benefit of having read the thousand-page project definition in advance, then you are doing well. The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator - because if your code is so illegible (or so heavily abstracted, or has such a steep learning curve, or whatever) that I cannot figure it out on my own in a few minutes and so have to drop everything until I can get some assistance... well then, you've burned up my precious, precious time. That code might be sheer genius. It might be, once you have tackled the learning curve, breathtakingly beautiful. But if I can't just fire up vi and dive in, then it is WRONG. Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. The big problem with the current state of Vtiger 4.x is that it straddles both worlds. There are parts of the code that are fairly straightforward and out in plain sight, and only lack comments to make them "good enough". Then there are parts that want to be object-oriented with an API, but really depend on a couple of heavily-overloaded megafunctions buried deep in the depths of util.php (also uncommented) so you have to play API detective to figure out just what the hell is happening where. And then there's parts of the code that mix both. It'd be SO much easier to maintain if all the code that related to a module (less some *basic* toolkit functions that could reside in a common include) just lived in that module. Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility. DG From dan.means at teamsrs.com Fri Jul 14 13:25:56 2006 From: dan.means at teamsrs.com (Dan Means) Date: Fri, 14 Jul 2006 13:25:56 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <44B7FDD4.4080009@teamsrs.com> I couldn't have said this better than Dennis.... -- Dan Means Mission Viejo, CA www.dkmeansonline.com www.teamsrs.com From crm at email.si Fri Jul 14 14:34:37 2006 From: crm at email.si (Ales Petric) Date: Fri, 14 Jul 2006 22:34:37 +0100 Subject: [Vtigercrm-developers] What's with 4.2.x future ? Message-ID: <44B80DED.4010808@email.si> HI EVERYONE This is my first post to 'vTiger' developers mailing list About me: My native environment is development environment (around C/C++, VB, HTML, CSS, PHP, ASP, Python). My home system environment is 'Linux' based desktop os. like 'Debian' and 'Debian' based (my latest is 'Ubuntu') For my business server system I use 'Debian' stable. Like all I had to do some system tunning and other stuff related for system to work properly and live. I worked for small and big companies, within groups and on solo projects. My favorite project is project that is more to an end oriented that other. I had worked on lost project to but I had learned something from that, hope you to. Project called 'vTIger': Yes, 'vTiger' :), I am working with this great free source project for some time now (let me think back, 1 year and 6 month it is, sounds like my birthday :) Reason is that I am involved with business that uses 'CRM' software and solution for them 'vTiger' was the answer, from me to them :) Yes, it sells good if support is guaranteed and signed in contract (like must be included); Yes what's new :) What is new? That was my question looking 'vTiger' community. Let's get serious. In my business we had implemented over 150 issues, or tickets related, not features. We have less then 10 serious stuff implemented, tested and deployed. I believe, and some of you will confirm that this is big step back for community when stuff is included in 'vTiger' and not updated on live track inside community. As we now, there are many companys that offers hosting with 'vTiger' CRM, and many are just keeping one eye on 4.2.x. I belive that 'vTiger' is under 'GPL' and much more, there is community above that is responsible for maintaining the project. Community: Let's face it. There should be readable state and mission, end oriented leadership, free participation, known business model of 'vTiger CRM', useful documents on-line, tutorials, subgroups with a roles like module manager, testers, and many more beautiful stuff, ..I yes there is many but not enough. I have read that someone was begging not for himself for some other guy that they should give him some type of account that he can post code 'not(anonymous)' Question is. Can community afford that kind of behaviour, that no actions are taken. Many are complaining about non activity that is going on right now. Proposal: Let's build team of project/module managers and sys-admin guys to do some steeps needed to put out htp://new.vtiger.com/ based on latest release of 4.2.x thread. On the same portal if it is possible ? Within the same community if it is possible ? We can invite all existing groups that are using 4.2.x thread and join forces and merge existing sources and fixed issues. We need that, and more we need all help we can get within testing activities that are needed when new release comes out. With future plans of what's included in first build and what in next. Yes we can plan what features and build them in future within subgroups of module managers responsible to finish what was started. 4.2.x future to be when 4.3 and then 5.0, isn't that the way ? If there is comment, I now there is, and I now there is the way we can bring action into 'vTiger' community. What do ya say? Respect, Ales Petric From carylt at gmail.com Fri Jul 14 14:47:03 2006 From: carylt at gmail.com (Caryl Takvorian) Date: Fri, 14 Jul 2006 22:47:03 +0100 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <8075d1e0607141447y1b5a878at5321bb42dafcd01b@mail.gmail.com> Just for the sake of it, let me say that I whole heartedly agree with Dennis. I'm not unfortunately convinced that his (our) opinion will change anything, but I find the arguments truthfully compelling. Caryl On 7/14/06, Dennis Grant wrote: > > > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/02f2875a/attachment.html From mmbrich at fosslabs.com Fri Jul 14 15:29:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 16:29:30 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <1152916171.16985.800.camel@localhost.localdomain> OK, so I am going to highlight and comment on some of my favorite quotes from DG so far, this way when I start ignoring his emails you will all understand why. 1) It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules. This has to be hands-down the stupidest thing I have ever heard in my life and I can't believe that anyone who claims the experience you do actually posts this drivel on a public mailing list. 2) I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. I am utterly convinced that anyone who argues that 95% code similarities in vtiger modules is a "good enough" method is utterly stupid. 3) The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator ... well then, you've burned up my precious, precious time So your 'job' as an OSS systems integrator has never included needing to RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing question on a mailing list? 4) That code might be sheer genius. But if I can't just fire up vi and dive in, then it is WRONG. I'm starting to see the picture now.. you're lazy, and rather than do something about the current problems in the system you are going to whine about it. Sergio was right, my apologies Sergio. 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. I think I've made it clear that simple, concise and logical are all design goals of the system. And you sir have made it clear that you have no intention of helping move this project forward by displaying your willingness to fork instead of work with a _real_ design structure that a _real_ OSS systems integrator would be very happy to have. Matt On Fri, 2006-07-14 at 15:37 -0400, Dennis Grant wrote: > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From brian at awnow.com Fri Jul 14 18:48:13 2006 From: brian at awnow.com (Brian Laughlin) Date: Fri, 14 Jul 2006 18:48:13 -0700 Subject: [Vtigercrm-developers] Poorly written code is poorly written code. Message-ID: <27CABE0A5EFD714EA5B2F9B47EE5CB855BCFA2@svawmc1.awnow.local> 'Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility.' This is not really a fair statement. OO code done well is a gem. The statement above automatically implies that it will be written poorly. OO code, procedure code or a sql query written badly is poorly written code - period. No method can overcome poor coding. It seems reasonable that v5 is about the future, one that creates better code base that is more reusable and it encourages more development talent to improve, iterate and integrate. With some effort I think we can mature this process so that the core product can continue to benefit from the community's contributions. There seems to be a simple fix to the debate that is ensuing. If you want to keep it as it is then support the 4.2.x branch, otherwise help to mature the code for v5. One last comment. There is a large class of developers that don't really care how the code was written or how it works as long as it works and works well. If you can extend its functionality or easily call it when you need it then for the most part they are happy. That doesn't stop those that want to dig deeper and tweak it at that level. More power to you. Regards, Brian Laughlin From mmbrich at fosslabs.com Sun Jul 16 20:31:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 21:31:30 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight Message-ID: <1153107090.5582.9.camel@localhost.localdomain> I wasn't able to get all the upgrades done last night, expect some more spotty access tonight as I try to finish up the list of to-dos Matt From mmbrich at fosslabs.com Sun Jul 16 21:31:29 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 22:31:29 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight In-Reply-To: <1153107090.5582.9.camel@localhost.localdomain> References: <1153107090.5582.9.camel@localhost.localdomain> Message-ID: <1153110689.5582.17.camel@localhost.localdomain> Upgraded SVN to 1.2.3 from backports.org. Let me know if you have problems with it. There is a backup of both the forge repo and the main repo from just before the upgrade. Matt On Sun, 2006-07-16 at 21:31 -0600, Matthew Brichacek wrote: > I wasn't able to get all the upgrades done last night, expect some more > spotty access tonight as I try to finish up the list of to-dos > > Matt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Mon Jul 17 02:18:50 2006 From: crm at email.si (Ales Petric) Date: Mon, 17 Jul 2006 10:18:50 +0100 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <1152899095.32568.49.camel@rockcrusher> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> <1152899095.32568.49.camel@rockcrusher> Message-ID: <44BB55FA.4050909@email.si> Ok As private developer owner of 4.2.x I would like to be involved 'actively' in planning, maintaining and updating the 4.2.x. With what can I contribute: 1- I can bug fix (ticket solve) 2- I can suggest & plan with others what's to be in next release (4.2.X) and help with coding to achieve that 3- I can define groups for managing individual modules (maintainers) that will togather with other involved in 4.2.x deceide what's needed to build as add-on 4- I can do the functional analyse of current 4.2.x and publish .pdf, like system & user help (for developers and others related) 5- I can built three of functionality, like dir structure (for UseCase, TestCase and other related) 6- I can define which ticket/issue goes with X module or X functionality (for quick issue solving and other related) 7- I can help sync with other anonymous/private developers what was solved/debugged and help to merge existing code into next to be released 8 .. and many other stuff that I had have already done and not published...I can decode that for other users... What do I need: 1- Account with permissions to do something, I don't want to be anonymous updater. Now it's 8 vs 1 :( I it would be great to be involved with when to release and what's included in next 4.2.x. Ales Nolan Andres wrote: > As one of the mentioned 4.2 developers mostly lurking on this list... > > Like others have mentioned, I've got 2 classes of modifications: > > 1. those _I think_ others may be interested in > 2. those _I think_ others will not be interested in > > What I want to know is...is what _I think_ in any way connected with > reality? > > More to the point... > > How do I know whether or not I *should* submit a given patch to the > current tree for 4.2.5? In my previous (though admittedly minimal) > exploration, I got the sense that 4.2.x was essentially "feature frozen" > and that bug/security fixes and deployment/installation/maintenance > stuff were fair game. > > For myself (and others like me), is 4.2 open for new features? If so, > should we just continue to take it on ourselves to self-select those > things _we think_ are more universal in nature? Should we try the > shotgun approach (submit everything to 'Code Contributions' and see what > gets picked up)? Is there a "proper place" to provide a list of changes > we've made and give others the opportunity to speak for/against > including them (or give a 'vTiger Linus' the opportunity to > accept/reject them)? > > I think once I have a clear idea of how best to contribute, particularly > to 4.2, I'll be more able to do so effectively. > > By the way, I think Matt's v5 architecture ideas are great, but they do > muddy the waters for me a bit. Seeing those ideas, I have hope that > something along those lines may be implemented, but it also makes me > question *when* the right time will be to port some of my changes and > additions to v5...I'd rather just do it once. > > peace, > nokes > > > > On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > >> Hi! >> This is a call to all the 4.x private development owners. >> >> Many of you would have been working on your own version of vtiger as you would have >> customized it to your own needs. This is a call for those guys. >> >> The intent is to aggregate most of the common features that you have built and have them >> integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch >> or even in the 5.x branch as needed by the community. >> >> Pros: >> >> By doing the above, you will be able to be in sync with the latest and greatest developments >> happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a >> read as one would think of but we are working on it. Yesterday we had comments about the >> code not being properly commented, we are working on that right now even as I type this post. >> So, the idea I am conveying is that we are not perfect but are listening to the comments and >> taking actions too. Hence, please do keep the faith. >> >> Cons: >> >> By maintaining your own code bases, you lose out on the community benefits like >> identifying bugs, feature integration, new ideas, etc. >> >> We welcome your contributions. >> >> Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise >> the folly. Let us get on with it and make vtiger a success. >> I have learnt from my past mistakes. Join the team, come on board. >> >> Richie >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > __________ NOD32 1.1661 (20060714) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f0af863c/attachment.htm From sergiokessler at gmail.com Mon Jul 17 06:36:39 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 10:36:39 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak From dgrant at accuratetechnologies.com Mon Jul 17 06:51:45 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Mon, 17 Jul 2006 09:51:45 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG From richie at vtiger.com Mon Jul 17 07:48:07 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:48:07 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> Message-ID: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Hi Team! Let us take a step back and review what is happening. As the case stands, the intent is to provide an ideal vtiger architecture which needs almost everyones needs. It is plain that as of now, there are only 2 "strong/loud" arguments. I am sure you all will agree that both of them are not overly subscribed by any majority yet. Let us get some more ideas- however radical they be- into this list and then we will vote the good ideas in. By being too strongly worded on any particular idea, it will only stop short the other guys to put forth their ideas however miniscule/insignificant that might appear to be. I have myself faced this situations many times and I wish that the same does not happen here. Let us target 2 weeks from today as the time within which we should get all the ideas in. We can always short list as we have quite some experienced hands on board. vtigercrm-5.0.0 will be out within that time. Good to see some emotion here but I am sure we will hold to the rules of basic etiquettes and only wrt the point in concern. Thank You, Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9af843db/attachment.html From richie at vtiger.com Mon Jul 17 07:57:28 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:57:28 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> Message-ID: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/d71cb2dd/attachment-0001.htm From richie at vtiger.com Mon Jul 17 08:43:10 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 08:43:10 -0700 Subject: [Vtigercrm-developers] automated tests update Message-ID: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f783fc2f/attachment.html From richie at vtiger.com Mon Jul 17 09:01:27 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:01:27 -0700 Subject: [Vtigercrm-developers] have a go at the demo Message-ID: <10c7d3878ee.-2525705299028808692.-7798707862789036512@@vtiger.com> Dear Team, Kindly have a go at the demo so that we can identify the bugs and fix them. We are planning to freeze taking up any new bug-fixing post this week. Needless to say, if there be any pressing bugs, we will have to re-consider else we stick to this plan. We would like to take into consideration all the bugs that we get by this week alone. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/05c6f7c8/attachment.htm From richie at vtiger.com Mon Jul 17 09:04:40 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:04:40 -0700 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 Message-ID: <10c7d3b68c9.-1733958150241885349.-2381377074013605034@@vtiger.com> Ken asked me a question in my blogs about how we can have a better documentation for v5. I honestly do not know if any setup is available which can help us achieve the same other than that of a wiki. Any new ideas are welcome. It will be nice to have a distributed effort on for the documentation as well. Let us get some working backbone for collaborative documentation up and running fast. Any ideas/suggestions? Any experienced documentor on board, please raise hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/effef8f7/attachment.html From richie at vtiger.com Mon Jul 17 09:24:59 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:24:59 -0700 Subject: [Vtigercrm-developers] Help Needed Feature Message-ID: <10c7d4e0030.-6478902657238423422.8728970723888816495@@vtiger.com> Is there any Help Needed feature available in the forge? Ken asked me this and I could not answer the query. Please find the link to the blog post for contextual reference: http://blogs.vtiger.com/weblog_entry.php?p=28125#28125 I think what Ken is referring is to have a more vertically-distributed setup something like Help Needed in Leads Module Bug-fixing Help Needed in Leads Module Docs Help Needed in Leads Module Automation of test cases etc. Matt/Fathi, can we have this for all the projects in the forge please or does it already exist? I just checked the forge and did not find any links. Am I missing something? Probably, we can have a link to the vtigercrm-5.0.0 live source in the vtigerforge too. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/1c9b7dca/attachment.htm From richie at vtiger.com Mon Jul 17 09:31:34 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:31:34 -0700 Subject: [Vtigercrm-developers] automated trac registration Message-ID: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9e1e63d7/attachment.html From richie at vtiger.com Mon Jul 17 09:34:57 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:34:57 -0700 Subject: [Vtigercrm-developers] Fwd: error Message-ID: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> ----j.ruisz at ruisz.com wrote ---- ============Forwarded Mail============ >From : j.ruisz at ruisz.com To : richie at vtiger.com Date :Fri, 14 Jul 2006 08:11:36 +0200 Subject : error ============Forwarded Mail============ Hello , trying to test the online demo of vtiger 5 i got this result: *Fatal error*: Call to a member function on a non-object in */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* on line *431* with best regards, mit freundlichen Gr??en, Joachim Ruisz Werbegrafik, Bildagentur, Webagentur Softwareentwicklung Joachim Ruisz A 8940 Liezen +43 664 312 4830 j.ruisz at ruisz.com http://www.ruisz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/332ceeeb/attachment.htm From richie at vtiger.com Mon Jul 17 09:35:17 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:35:17 -0700 Subject: [Vtigercrm-developers] Fwd: Translations Message-ID: <10c7d576ed5.6497289794643483356.-5939067564803299625@@vtiger.com> ----webmaster at vtigerfacile.com wrote ---- ============Forwarded Mail============ >From : webmaster at vtigerfacile.com To : richie at vtiger.com Date :Mon, 17 Jul 2006 02:31:42 +0200 Subject : Translations ============Forwarded Mail============ Vanakkam Shankar, i have made a little test for translation. I have added few line in app_strings file. And like for module customview, all dropdown in all editviews (Call/Meeting inclued) are translated. If we can have the same things in listview & detailview, the translation will be perfect, and vtiger 5 can be used in multilang without problem. I want to mention the value of select box is keep in english () Best regards, A?ssa Find the added strings in /include/languages/fr_fr.lang.php below //activities 'Planned'=>'Plannifi?', 'Held'=>'A eu lieu', 'Not Held'=>'N\'a pas eu lieu', 'Medium'=>'Normale', 'Private'=>'Priv?', 'Public'=>'Public', 'Daily'=>'Quotidienne', 'Weekly'=>'Hebdomadaire', 'Monthly'=>'Mensuelle', 'Yearly'=>'Annuelle', 'Completed'=>'Termin?', 'Deferred'=>'Report?', //Campaigns 'Excellent'=>'Excellent', 'Good'=>'Bonne', 'Average'=>'Moyenne', 'Poor'=>'Faible', 'Conference'=>'Conf?rence', 'Webinar'=>'S?minaire', 'Trade Show'=>'Salon', 'Public Relations'=>'Relations Publique', 'Partners'=>'Partenaires', 'Referral Program'=>'Programme', 'Advertisement'=>'Publicit?', 'Banner Ads'=>'Banni?re web', 'Direct Mail'=>'Email direct', 'Email'=>'Email', 'Telemarketing'=>'T?l?marketing', 'Others'=>'Autre', 'Planning'=>'Plannifi?', 'Complete'=>'Termin?', 'Cancelled'=>'Annul?', //Accounts //Industry list 'Apparel'=>'Appareillage', 'Banking'=>'Banque', 'Biotechnology'=>'Biotechnologie', 'Chemicals'=>'Industrie chimique', 'Communications'=>'Communications', 'Construction'=>'BTP', 'Consulting'=>'Conseil', 'Education'=>'Education', 'Electronics'=>'Electronique', 'Energy'=>'Energie', 'Engineering'=>'Engineering', 'Entertainment'=>'Divertissement', 'Environmental'=>'Environnement', 'Finance'=>'Finance', 'Food & Beverage'=>'Agro alimentaire', 'Government'=>'Secteur public', 'Healthcare'=>'Sant?', 'Hospitality'=>'Hopitaux', 'Insurance'=>'Assurances', 'Machinery'=>'', 'Manufacturing'=>'Manufacture', 'Media'=>'M?dia', 'Not For Profit'=>'But non lucratif', 'Recreation'=>'Amusement', 'Retail'=>'D?taillant', 'Shipping'=>'Livreur', 'Technology'=>'Technologie', 'Telecommunications'=>'T?l?communications', 'Transportation'=>'Voyage', 'Utilities'=>'D\'utilit? publique', 'Other'=>'Autre', //accounts type 'Analyst'=>'Analyste', 'Competitor'=>'Concurrent', 'Customer'=>'Client', 'Integrator'=>'Int?grateur', 'Investor'=>'Investisseur', 'Partner'=>'Partenaire', 'Press'=>'Presse', 'Prospect'=>'Prospect', 'Reseller'=>'Revendeur', 'Other'=>'Autre', 'Existing Business'=>'Client existant', 'New Business'=>'Nouveau client', 'Cold Call'=>'Appel direct', 'Existing Customer'=>'Client existant', 'Self Generated'=>'Auto g?n?r?', 'Employee'=>'Employ?', 'Partner'=>'Partenaire', 'Public Relations'=>'Relation publique', 'Direct Mail'=>'Email direct', 'Conference'=>'Conf?rence', 'Trade Show'=>'Salon', 'Web Site'=>'Site web', 'Word of mouth'=>'Bouche ? oreille', 'Other'=>'Autre', 'Prospecting'=>'Prospection', 'Qualification'=>'Qualification', 'Needs Analysis'=>'Requiert analyse', 'Value Proposition'=>'Proposition', 'Id. Decision Makers'=>'Attente d?cision', 'Perception Analysis'=>'Anallyse', 'Proposal/Price Quote'=>'Devis', 'Negotiation/Review'=>'N?gociation', 'Closed Won'=>'Clos gagn?', 'Closed Lost'=>'Clos perdu', 'Attempted to Contact'=>'Attente contact', 'Cold'=>'Froid', 'Contact in Future'=>'A recontacter', 'Contacted'=>'Contact?', 'Hot'=>'Chaud', 'Junk Lead'=>'Corbeille', 'Lost Lead'=>'Perdu', 'Not Contacted'=>'Non contact?', 'Pre Qualified'=>'Pr? qualifi?', 'Qualified'=>'Qualifi?', 'Warm'=>'Brulant', 'Acquired'=>'Acquis', 'Active'=>'Actif', 'Market Failed'=>'March? perdu', 'Project Cancelled'=>'Projet annul?', 'Shutdown'=>'Eteint', 'Open'=>'Ouvert', 'In Progress'=>'En cours', 'Wait For Response'=>'Attente de r?ponse', 'Closed'=>'Clos', 'General'=>'G?n?ral', 'Low'=>'Basse', 'Normal'=>'Normale', 'High'=>'Haute', 'Urgent'=>'Urgent', 'Minor'=>'Mineure', 'Major'=>'Majeur', 'Feature'=>'Fonctionnalit?', 'Critical'=>'Critique', 'Big Problem'=>'Gros probl?me', 'Small Problem'=>'Petit probl?me', 'Other Problem'=>'Autre probl?me', 'Hardware'=>'Mat?riel', 'Software'=>'Logiciel', 'CRM Applications'=>'Application CRM', 'Box'=>'Boite', 'Carton'=>'Carton', 'Dozen'=>'Douzaine', 'Each'=>'Pi?ce', 'Hours'=>'Heure', 'Impressions'=>'Impression', 'Lb'=>'Lb', 'M'=>'M', 'Pack'=>'Pack', 'Pages'=>'Pages', 'Pieces'=>'Pi?ces', 'Quantity'=>'Quantit?', 'Reams'=>'Rames', 'Sheet'=>'Pages', 'Spiral Binder'=>'Reliure', 'Sq Ft'=>'Sq Ft', 'Created'=>'Cr??', 'Delivered'=>'Livr?', 'Reviewed'=>'Corrig?', 'Accepted'=>'Accept?', 'Rejected'=>'Rejett?', 'Approved'=>'Approuv?', 'Sent'=>'Envoy?', 'Credit Invoice'=>'Avoir', 'Paid'=>'Sold?', 'Received Shipment'=>'Commande re?ue', 'Call'=>'Appel', 'Meeting'=>'Rendez-vous', 'Task'=>'T?che', '--None--'=>'Aucun', -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9ad522c6/attachment-0001.html From gopals at vtiger.com Mon Jul 17 10:58:01 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 10:58:01 -0700 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Message-ID: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Hi, If there is automate option, it is better to notify user id and password to the correct email ids. I am already struggling with free forums and wiki registration process. People register with junk mail ids and spam our bug tracker as well. My be we can create a group mail id and alias to admin users, who can create trac users ids so that load is shared among developer community. Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/c36beaeb/attachment.htm From mmbrich at fosslabs.com Mon Jul 17 11:18:22 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:18:22 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Message-ID: <1153160302.5582.73.camel@localhost.localdomain> > It is plain that as of now, there are only 2 "strong/loud" arguments. > I am sure you all will agree that both of them are not overly > subscribed by any majority yet. Yes but there is only one idea on the table, and 1 set of criticisms followed by absolutely no suggestions on how to better the first idea. This was really my bitch about the first set of posts. > > Let us get some more ideas- however radical they be- into this list > and then we will vote the good ideas in. This is a great idea. I have been looking forward to someone else posting some ideas to get the ball rolling. I for one welcome radical ideas if anyone has any. > By being too strongly worded on any particular idea, it will only stop > short the other guys to put forth their ideas however > miniscule/insignificant that might appear to be. I certainly don't mean to scare off any developers that are going to actually bring some ideas to the table, quite the contrary. If someone has been playing around in 5.x and said to themselves "wouldn't it be easier if this was done like this..." then please tell us what you are thinking, even if it doesn't involve a full change to the architecture and only covers some small area of the code. > > I have myself faced this situations many times and I wish that the > same does not happen here. > > Let us target 2 weeks from today as the time within which we should > get all the ideas in. Lets not rush this, or pile on top of the workload that many vtiger devels are probably already experiencing. The only reason I brought my idea to the table this soon is because you and I had discussed this off list and I thought it needed to be in front of the community. > We can always short list as we have quite some experienced hands on > board. > vtigercrm-5.0.0 will be out within that time. But after 5.0.0 is out is when I think we'll start to see the most interesting ideas. Many devels may still be in 4.x and haven't had a chance yet to start playing with 5.x. Lets let them get their hands dirty in the new code first. > > Good to see some emotion here but I am sure we will hold to the rules > of basic etiquettes and only wrt the point in concern. I know I am a blunt person and sometimes that catches people off guard :), I rarely mean to come off as rude unless someone fully deserves it. Anyways, bring on the ideas for improving vtiger! Matt From mmbrich at fosslabs.com Mon Jul 17 11:22:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:22:49 -0600 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Message-ID: <1153160569.5582.79.camel@localhost.localdomain> I can't think of a great way to do automated sign-up without using captcha or something similar, and we all know there are ways around those systems. I like your ideas of an admin list that people can request access from. And BTW, which interface are you guys using to give developers trac accounts? There is the trac module which was installed or there is the service page that I created to manage SVN and trac. The reason I ask is because the service page may be out of date now that we've upgraded trac a couple times since I wrote it. Matt On Mon, 2006-07-17 at 10:58 -0700, Gopal wrote: > Hi, > > If there is automate option, it is better to notify user id and > password to the correct email ids. I am already struggling with free > forums and wiki registration process. People register with junk mail > ids and spam our bug tracker as well. > > My be we can create a group mail id and alias to admin users, who can > create trac users ids so that load is shared among developer > community. > > Gopal > --- > S.S.G.Gopal > skype: sripadag > ph: +1 877 788 4437 > blog: http://gopal.vtiger.com > > > > > ----richie at vtiger.com wrote ---- > > > Hi! > Team, is there any way we can have an automated trac registration? I can do the registrations > till a point and the current mechanism is too crude. > > Jeff/Matt any ideas please? > > Richie _______________________________________________ > Get started with creating presentations online - > http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Mon Jul 17 11:24:20 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:24:20 -0600 Subject: [Vtigercrm-developers] Fwd: error In-Reply-To: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> References: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> Message-ID: <1153160660.5582.81.camel@localhost.localdomain> I'll upgrade the demo sometime this afternoon, I still haven't had a chance to sit down and write an automation system for this since. I plan to create something along the lines of Jeff's suggestion and automate it with post-commit hooks. Anyone who wants to help, just say the word. Matt On Mon, 2006-07-17 at 09:34 -0700, Richie wrote: > > > > > ----j.ruisz at ruisz.com wrote ---- > > ============Forwarded Mail============ > From : j.ruisz at ruisz.com > To : richie at vtiger.com > Date :Fri, 14 Jul 2006 08:11:36 +0200 > Subject : error > ============Forwarded Mail============ > > Hello , > > trying to test the online demo of vtiger 5 i got this result: > > *Fatal error*: Call to a member function on a non-object in > */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* > on line *431* > > > > with best regards, > mit freundlichen Gr??en, > > Joachim Ruisz > > Werbegrafik, Bildagentur, Webagentur > Softwareentwicklung > > Joachim Ruisz > A 8940 Liezen > +43 664 312 4830 > j.ruisz at ruisz.com > http://www.ruisz.com > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From gopals at vtiger.com Mon Jul 17 11:37:05 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 11:37:05 -0700 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> References: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Message-ID: <10c7dc6f0c9.-5230172439552086929.-6694355083648319934@@vtiger.com> Hi Richie, I am aware of that currently we are using AdventNet QEngine for automating some of the test cases. But I am not clear, how can our external developer community use this tool in their local environment. Do you have any plans to get some more licenses for the sake of vtiger developer community? Thanks, Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/8b304edc/attachment.html From jtk at yahoo.com Mon Jul 17 12:01:00 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 15:01:00 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: Gopal wrote: > I am aware of that currently we are using AdventNet QEngine for > automating some of the test cases. But I am not clear, how can our > external developer community use this tool in their local environment. > Do you have any plans to get some more licenses for the sake of vtiger > developer community? I'm glad to see regression tests on the agenda, but we don't need non-free tools to get this done. Selenium, which I've mentioned before, runs recorded tests in a browser, giving the most/only realistic test environment for javascript, etc. Selenium tests can be recorded by a firefox plugin, and the test source can be checked into subversion like any other source. This is what we should use, IMHO. http://openqa.org/selenium/ As far as running 'continuous integration testing'; some testing experts have used buildbot and vmware/vnc integration to continuously and automatically run unit and integration tests in a headless environment. http://www.google.com/search?q=buildbot+selenium http://agile.idyll.org/wiki/BuildBotTechnologyNarrative http://agile.idyll.org/buildbot/ All this testing technology uses free software. From mmbrich at fosslabs.com Mon Jul 17 14:25:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 15:25:52 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: <1153171552.5582.166.camel@localhost.localdomain> I haven't looked into Selenium yet but with JS does it work at the source level only, does it use gecko to actually execute and evaluate the JS or can it check for changes in the DOM like it does the source? In 5.x there are quite a few places where the DOM is being manipulated directly or indirectly and I don't think a source level verification tool will catch most of those. Maybe augmenting it with the scriptactulous unit test lib would work? http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Matt On Mon, 2006-07-17 at 15:01 -0400, Jeff Kowalczyk wrote: > Gopal wrote: > > I am aware of that currently we are using AdventNet QEngine for > > automating some of the test cases. But I am not clear, how can our > > external developer community use this tool in their local environment. > > Do you have any plans to get some more licenses for the sake of vtiger > > developer community? > > I'm glad to see regression tests on the agenda, but we don't need non-free > tools to get this done. > > Selenium, which I've mentioned before, runs recorded tests in a browser, > giving the most/only realistic test environment for javascript, etc. > > Selenium tests can be recorded by a firefox plugin, and the test source > can be checked into subversion like any other source. This is what we > should use, IMHO. > > http://openqa.org/selenium/ > > As far as running 'continuous integration testing'; some testing experts > have used buildbot and vmware/vnc integration to continuously and > automatically run unit and integration tests in a headless environment. > > http://www.google.com/search?q=buildbot+selenium > > http://agile.idyll.org/wiki/BuildBotTechnologyNarrative > > http://agile.idyll.org/buildbot/ > > All this testing technology uses free software. > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Mon Jul 17 15:53:33 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 18:53:33 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: Matthew Brichacek wrote: > I haven't looked into Selenium yet but with JS does it work at the > source level only, does it use gecko to actually execute and evaluate > the JS or can it check for changes in the DOM like it does the source? > In 5.x there are quite a few places where the DOM is being manipulated > directly or indirectly and I don't think a source level verification > tool will catch most of those. Selenium directly drives the browser as if the user were clicking it. The demo http://www.openqa.org/selenium-core/demos.html illustrates the concept. > Maybe augmenting it with the scriptactulous unit test lib would work? > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Unit tests in the client and server-side source would be enhancements, to be sure. However, I am skeptical about trying to retrofit unit test coverage to a large code base. The community would have a hard time achieving useful code coverage unless there were tests for *everything*, starting from early in the project. Selenium's end-result testing, and the fact that such tests can be recorded for submission by even novice users, would be an efficient use of limited community resources. If the testing fever strikes the community, perhaps all new code could be required to have unit tests, and so on. From sergiokessler at gmail.com Mon Jul 17 16:14:20 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 20:14:20 -0300 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 In-Reply-To: <8091387652950704133@unknownmsgid> References: <8091387652950704133@unknownmsgid> Message-ID: <49216030607171614g2a47b5di900e13b06c4810f6@mail.gmail.com> richie, a wiki is the best aproach for this, don't worry... (of course, then you need people that do collaborate) /sak On 7/17/06, Richie wrote: > > Ken asked me a question in my blogs about how we can have > a better documentation for v5. > I honestly do not know if any setup is available which > can help us achieve the same other than > that of a wiki. > Any new ideas are welcome. > > It will be nice to have a distributed effort on for > the documentation as well. > Let us get some working backbone for > collaborative documentation up and running > fast. > > Any ideas/suggestions? > Any experienced documentor on board, please raise hands! > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From mmbrich at fosslabs.com Mon Jul 17 17:13:46 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 18:13:46 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: <1153181627.5582.194.camel@localhost.localdomain> On Mon, 2006-07-17 at 18:53 -0400, Jeff Kowalczyk wrote: > Matthew Brichacek wrote: > > I haven't looked into Selenium yet but with JS does it work at the > > source level only, does it use gecko to actually execute and evaluate > > the JS or can it check for changes in the DOM like it does the source? > > In 5.x there are quite a few places where the DOM is being manipulated > > directly or indirectly and I don't think a source level verification > > tool will catch most of those. > > Selenium directly drives the browser as if the user were clicking it. The > demo http://www.openqa.org/selenium-core/demos.html illustrates the > concept. I tried this out and did a little digging in the Core and IDE. From the looks of it, Selenium can handle a _lot_ of the javascript testing we would need, if not all of it. > > > Maybe augmenting it with the scriptactulous unit test lib would work? > > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting > > Unit tests in the client and server-side source would be enhancements, to > be sure. However, I am skeptical about trying to retrofit unit test > coverage to a large code base. The community would have a hard time > achieving useful code coverage unless there were tests for *everything*, > starting from early in the project. > > Selenium's end-result testing, and the fact that such tests can be > recorded for submission by even novice users, would be an efficient use of > limited community resources. If the testing fever strikes the community, > perhaps all new code could be required to have unit tests, and so on. I had thought of this before too but my experience in requiring unit tests has not been good :). In the CGL project we tried to enforce a rule like this and it was shot down almost before it left the ground. In a PoC environment like that it's understandable but I think even in the case of vtiger the fever would have to be HOT to get everyone on board. Matt From richie at vtiger.com Mon Jul 17 22:40:42 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 22:40:42 -0700 Subject: [Vtigercrm-developers] XTemplate removed Message-ID: <10c80267f98.3578777089016548574.3997907602755987476@@vtiger.com> This is to inform that we have removed XTemplate dependency in vtigercrm5.0.0. XTemplate has been removed from the source as well. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9fe2c2d6/attachment.htm From webmaster at vtigerfacile.com Tue Jul 18 02:18:43 2006 From: webmaster at vtigerfacile.com (=?ISO-8859-1?Q?A=EFssa?=) Date: Tue, 18 Jul 2006 11:18:43 +0200 Subject: [Vtigercrm-developers] Idea for future Message-ID: <44BCA773.9050506@vtigerfacile.com> Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa From richie at vtiger.com Tue Jul 18 03:20:36 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:20:36 -0700 Subject: [Vtigercrm-developers] need helping hands Message-ID: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> I am quoting Gopal's bug report. " As per discussion. I am testing product on the following setup: OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a-installer.exe php settings: error_reporting = E_ALL display_errors = On display_startup_errors = On log_errors = On After completion of installation 1.2 mb error log is generated in Apache error.log file. It is better to fix some of the notices and warnings, which will definitely improve the performance of the product. Thanks, Gopal " Need helping hands who can dig into this and give the fixes. We are held up with validation over here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/071764bc/attachment.html From richie at vtiger.com Tue Jul 18 03:21:42 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:21:42 -0700 Subject: [Vtigercrm-developers] Idea for future In-Reply-To: <44BCA773.9050506@vtigerfacile.com> References: <44BCA773.9050506@vtigerfacile.com> Message-ID: <10c8127c4e2.-191772016694368201.-7661796100973677084@@vtiger.com> Hello! I do agree with that. I wanted it to be part of vtigercrm-5.0.0 but it was a feature so dropped it. It does not require too much effort actually. Will be taken up as part of 5.0.1 Richie ---- A?ssa<webmaster at vtigerfacile.com> wrote ---- Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/c3cec421/attachment.htm From richie at vtiger.com Tue Jul 18 05:13:08 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 05:13:08 -0700 Subject: [Vtigercrm-developers] need helping hands-2 Message-ID: <10c818dc9b0.-7967502206826138398.-2571256210646174921@@vtiger.com> We are getting quite some javascript issues in IE browsers. Any one out there game to test it in IE and help us by giving the fixes will be great. Please ensure that the fix does not break the Firefox/Mozilla support. Kindly post the fix in the trac and a blurb here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/a6b94bf0/attachment.html From developer at infointegrated.com Tue Jul 18 05:33:39 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Tue, 18 Jul 2006 07:33:39 -0500 Subject: [Vtigercrm-developers] need helping hands In-Reply-To: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> References: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> Message-ID: <9160DA4D-DAAA-4C0D-B458-E401E03C5E49@infointegrated.com> Sounds like quite the challenge. I just started doing some more thorough testing of vtiger 5.0. I have created 3 new tickets on it. I was able to create patches for the first two. #1531 is to reset the Quick Create menu to Quick Create... after selecting an item (with a patch). #1532 cleans up the formatting of the AllMenu: putting headers on all columns, keeping the length more consistent (with a patch). #1533 is a bug when resizing the window too small. the HomePage Dashboard looks horrible. There needs to be some resize code, but I've not had time to look into patching this one. If I have time, I will also look for solutions to some of the error logs and IE JavaScript Issues. Not sure how much free time I'll have... Brian On Jul 18, 2006, at 5:20 AM, Richie wrote: > I am quoting Gopal's bug report. > " > As per discussion. I am testing product on the following setup: > OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a- > installer.exe php settings: > error_reporting = E_ALL display_errors = On display_startup_errors > = On log_errors = On > After completion of installation 1.2 mb error log is generated in > Apache error.log file. > It is better to fix some of the notices and warnings, which will > definitely improve the performance of the product. > Thanks, Gopal > " > > > Need helping hands who can dig into this and give the fixes. > We are held up with validation over here. > > Richie > _______________________________________________ > Get started with creating presentations online - http:// > zohoshow.com?vt From dgrant at accuratetechnologies.com Tue Jul 18 05:58:03 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 18 Jul 2006 08:58:03 -0400 Subject: [Vtigercrm-developers] vtiger arch going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090C@exch.accuratetechnologies.com> >> It is plain that as of now, there are only 2 "strong/loud" arguments. >> I am sure you all will agree that both of them are not overly >> subscribed by any majority yet. > Yes but there is only one idea on the table, and 1 set of criticisms > followed by absolutely no suggestions on how to better the first idea. > This was really my bitch about the first set of posts. Then frankly, you misread. 1) All code must be commented. Ideally, this would be a priority such that commenting existing code would be an actual project, but realistically, the goal of "all NEW code must be commented" or perhaps "every time you touch the code, a comment must be inserted" is doable. 2) The current (4.x) architecture uses a number of "common" functions (so identified by virtue of living in the include directory) that are not really common. An easy test is that if at any time a soi-disant "common" function tests to see what module it was called from and then acts differently based on the result of that test, it ain't common. Those functions should be broken out of the include directory and moved into the appropriate module directory - perhaps something like modules/Foo/UI.php (although this naming convention is definitely open for discussion) 3) Any time you go to the database, the actual SQL should be exposed; it helps integrators understand the layout and function of the database and makes extending the database much easier. It's OK to streamline db functions somewhat though - something like: $query = 'SOME SQL'; @2D_array = query_db($query) or handle_db_error; Is OK. 3) All modules must be atomic. At no time is it EVER permissible that changing the code in module FOO *changes* the functionality of module BAR - with one exception; if module FOO ever *calls* module BAR, and a code change to BAR has broken the interface, then it is understood that FOO calling BAR will break (and shame on whoever changed BAR's interface) In some cases, this will actually move functionality INTO common code, and that's a good thing. For example, currently HelpDesk calls code in Emails to do its email notification stuff (HORROR!) This would be better served by a function in utils.php that called some sort of generic email API: $result = send_email($to, $from, $cc, $bcc, $subject, $body, $flags); 4) There are two major challenges facing the vtiger architecture, independent of code structure: a) Per-user localization, which in turn is broken down into: i) User language of choice; and ii) User operating currency (which may be a function of what office the user is working out of) b) Per-user security (a user cannot edit someone else's Quote, for example) Both of these are ABSOLUTE MUSTS going forward, and there's a lot of heavy lifting there. No matter what the code structure is, these two design structures must be part of the arch. I'm hoping that 5.0 has support for this already... >> Let us get some more ideas- however radical they be- into this list >> and then we will vote the good ideas in. > This is a great idea. I have been looking forward to someone else > posting some ideas to get the ball rolling. I for one welcome radical > ideas if anyone has any. Hrm, well, let's see how welcoming you *really* are. DG From jens at Strawberry.COM Tue Jul 18 06:16:35 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 15:16:35 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] Message-ID: <20060718151635.D16513@Strawberry.COM> -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- An embedded message was scrubbed... From: Jens Hamisch Subject: Patches required for PostgreSQL 8.1.4 Date: Tue, 18 Jul 2006 09:02:01 +0200 Size: 27774 Url: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/efd557cc/attachment.mht From allan.bush+vtiger_dev at gmail.com Tue Jul 18 07:14:27 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 07:14:27 -0700 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <20060718151635.D16513@Strawberry.COM> References: <20060718151635.D16513@Strawberry.COM> Message-ID: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> I have given up on getting postgres support into 5.0 because I got tired of having my changes reverted and the database changing on me. The last straw was when all the database table names were changed without warning. If someone else wants to continue the effect feel free to take a look at this patch and take over the effort. On 7/18/06, Jens Hamisch wrote: > > -- > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > > ---------- Forwarded message ---------- > From: Jens Hamisch > To: vtigercrm-developers at lists.vtigercrm.com > Date: Tue, 18 Jul 2006 09:02:01 +0200 > Subject: Patches required for PostgreSQL 8.1.4 > Hi, > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > database. Compared to mySQL this database seems to require some code > changes. I've located and fixed the following problems: > > 1. SELECT count(*) count FROM ... won't work. > The AS clause is missing: SELECT count(*) AS count FROM ... > > 2. Referring table columns in case of joined tables in the > SELECT or ORDER BY clause requires the columns also to be > listed in a GROUP BY clause. > > 3. tablename.* won't work in a GROUP BY clause > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > LIMIT and OFFSET clause. > > 5. PostgreSQL supports transactions. However the current coding > results in transaction failures. > > I've attached my patches to this mail. Those patches at a first glance > address the problems 1-4. The transaction problem is not yet fixed. > I want to clean up the "simple" SQL statements first, before analyzing > such complex things. > > I'm not a 100% satisfied with the patches, because they introduce some > dbType dependencies into the "high level" vtiger code. Also structural > information is required in the function which expands the queries by > the required GROUP BY clause. I was thinking of moving those things > to a more abstract layer, but stopped doing this, because a generic > solution would either result in parsing and fixing each entire SQL statement > (including all its features and possibilities) or a redesign of the > affected SQL queries itsself. > > In most cases (especially the LIMIT changes) my patches might also work > for mySQL, so the database dependency possibly could be removed. This > might also apply to some of the GROUP BY patches. > > > Hope those changes will find their way to the vtigercrm5 mainline. > > Kind regards > -- Jens > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > From jens at Strawberry.COM Tue Jul 18 08:12:13 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 17:12:13 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com>; from Allan Bush on Tue, Jul 18, 2006 at 07:14:27AM -0700 References: <20060718151635.D16513@Strawberry.COM> <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> Message-ID: <20060718171213.F16513@Strawberry.COM> Hi Allan, hi *, most changes I did seem not to be related to postgres only. So it would help a lot (and remove dbType dependencies) from the code if smb. could check if my changes will also be valid for mySQL ... Jens On Tue, Jul 18, 2006 at 07:14:27AM -0700, Allan Bush wrote: > I have given up on getting postgres support into 5.0 because I got > tired of having my changes reverted and the database changing on me. > The last straw was when all the database table names were changed > without warning. > > If someone else wants to continue the effect feel free to take a look > at this patch and take over the effort. > > On 7/18/06, Jens Hamisch wrote: > > > > -- > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > > > ---------- Forwarded message ---------- > > From: Jens Hamisch > > To: vtigercrm-developers at lists.vtigercrm.com > > Date: Tue, 18 Jul 2006 09:02:01 +0200 > > Subject: Patches required for PostgreSQL 8.1.4 > > Hi, > > > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > > database. Compared to mySQL this database seems to require some code > > changes. I've located and fixed the following problems: > > > > 1. SELECT count(*) count FROM ... won't work. > > The AS clause is missing: SELECT count(*) AS count FROM ... > > > > 2. Referring table columns in case of joined tables in the > > SELECT or ORDER BY clause requires the columns also to be > > listed in a GROUP BY clause. > > > > 3. tablename.* won't work in a GROUP BY clause > > > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > > LIMIT and OFFSET clause. > > > > 5. PostgreSQL supports transactions. However the current coding > > results in transaction failures. > > > > I've attached my patches to this mail. Those patches at a first glance > > address the problems 1-4. The transaction problem is not yet fixed. > > I want to clean up the "simple" SQL statements first, before analyzing > > such complex things. > > > > I'm not a 100% satisfied with the patches, because they introduce some > > dbType dependencies into the "high level" vtiger code. Also structural > > information is required in the function which expands the queries by > > the required GROUP BY clause. I was thinking of moving those things > > to a more abstract layer, but stopped doing this, because a generic > > solution would either result in parsing and fixing each entire SQL statement > > (including all its features and possibilities) or a redesign of the > > affected SQL queries itsself. > > > > In most cases (especially the LIMIT changes) my patches might also work > > for mySQL, so the database dependency possibly could be removed. This > > might also apply to some of the GROUP BY patches. > > > > > > Hope those changes will find their way to the vtigercrm5 mainline. > > > > Kind regards > > -- Jens > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From allan.bush+vtiger_dev at gmail.com Tue Jul 18 08:21:46 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 08:21:46 -0700 Subject: [Vtigercrm-developers] Commit list is broken Message-ID: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> I haven't received any email from the commit/ticket list (vtigercrm-commits at lists.vtigercrm.com) since the 16th. I just made a couple changes which should have triggered emails and they haven't been received either so I'm fairly certain the list is down. From mmbrich at fosslabs.com Tue Jul 18 11:28:48 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 18 Jul 2006 12:28:48 -0600 Subject: [Vtigercrm-developers] Commit list is broken In-Reply-To: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> References: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> Message-ID: <1153247328.5582.214.camel@localhost.localdomain> This is probably from the SVN upgrade, the version we are on now moved all hook scripts to a diff area and I probably missed one. I'll see if I can fix it ASAP. Matt On Tue, 2006-07-18 at 08:21 -0700, Allan Bush wrote: > I haven't received any email from the commit/ticket list > (vtigercrm-commits at lists.vtigercrm.com) since the 16th. > > I just made a couple changes which should have triggered emails and > they haven't been received either so I'm fairly certain the list is > down. > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jens at Strawberry.COM Tue Jul 18 11:44:48 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 20:44:48 +0200 Subject: [Vtigercrm-developers] Yet another postgres8 patch Message-ID: <20060718204448.D29275@Strawberry.COM> Hi, yet another patch addressing postgres8 Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- *** vtiger_crm/include/database/Postgres8.php.rev8092 Tue Jul 18 20:37:05 2006 --- vtiger_crm/include/database/Postgres8.php Tue Jul 18 20:38:50 2006 *************** *** 122,127 **** --- 122,131 ---- elseif( $table == "vtiger_profile2field") $subfields = array ( "profileid", "tabid", "fieldid", "visible", "readonly"); + //vtiger_field + elseif( $table == "vtiger_field") + $subfields = array ( "tabid", "fieldid", "columnname", "tablename", "generatedtype", "uitype", "fieldname", "fieldlabel", "readonly", "presence", "selected", "maximumlength", "sequence", "block", "displaytype", "typeofdata", "quickcreate", "quickcreatesequence", "info_type"); + //fields of the requested array still undefined else $log->info("function expandRecord: please add structural information for table '".$table."'"); *** vtiger_crm/include/utils/CommonUtils.php.rev8092 Tue Jul 18 20:25:23 2006 --- vtiger_crm/include/utils/CommonUtils.php Tue Jul 18 20:36:01 2006 *************** *** 960,971 **** { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in $blockid_list and vtiger_field.displaytype in (1,2,4) order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and vtiger_field.displaytype in (1,2,4) and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." group by vtiger_field.fieldid order by block,sequence"; } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); --- 960,974 ---- { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN $blockid_list AND vtiger_field.displaytype IN (1,2,4) ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND vtiger_field.displaytype IN (1,2,4) AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); *************** *** 976,987 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list ." and ".$display_type_check." and info_type = '".$info_type."' order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and info_type = '".$info_type."' and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } else --- 979,993 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list ." AND ".$display_type_check." AND info_type = '".$info_type."' ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND info_type = '".$info_type."' AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } else *************** *** 988,999 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } $result = $adb->query($sql); --- 994,1008 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } $result = $adb->query($sql); *************** *** 1789,1796 **** } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and quickcreate=0 and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." order by quickcreatesequence"; } $category = getParentTab(); --- 1798,1808 ---- } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND quickcreate=0 AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." ORDER BY quickcreatesequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $quickcreate_query = fixPostgresQuery( $quickcreate_query, $log, 0); } $category = getParentTab(); *** vtiger_crm/modules/Users/Authenticate.php.rev8092 Tue Jul 18 19:55:38 2006 --- vtiger_crm/modules/Users/Authenticate.php Tue Jul 18 19:57:24 2006 *************** *** 40,47 **** { //Inserting entries for audit trail during login ! $date_var = date('YmdHis'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,$date_var)"; $adb->query($query); --- 40,47 ---- { //Inserting entries for audit trail during login ! $date_var = date('Y-m-d H:i:s'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,'$date_var')"; $adb->query($query); From libregeek at gmail.com Tue Jul 18 22:07:25 2006 From: libregeek at gmail.com (Manilal K M) Date: Wed, 19 Jul 2006 10:37:25 +0530 Subject: [Vtigercrm-developers] Something happened with forums.vtiger.com Message-ID: <2315046d0607182207k577376efv69026d9ce7e887c2@mail.gmail.com> Hi Team, Today Morning I got the reminder for the forum topic given below. How this happened? There are mo updates on this thread and it's almost 4 months old. Please look into it. regards Manilal ---------- Forwarded message ---------- From: webmaster at vtiger.com Date: 19-Jul-2006 07:38 Subject: New Topic Notification for forum "Announcements" - vtiger CRM 5 Alpha 5 Released To: Hello ! Sai has posted a new topic called "vtiger CRM 5 Alpha 5 Released" in the "Announcements" forum at vtiger. You can use the following link to view the topic: http://forums.vtiger.com/viewtopic.php?p=23074#23074 ----------------------------------------------- Posted text: Hi, We are pleased to announce the vtiger [b:7141f7c5eb]CRM 5.0 Alpha 5 release[/b:7141f7c5eb]. The intent of this release is to showcase to the vtiger community, the significant changes made after v5 Alpha 4 release i.e., changes since Mar 31, 06\' . We have conducted performance testing for some of the modules using a popular [b:7141f7c5eb]Web Based Testing Software (AdventNet QEngine 6.0),[/b:7141f7c5eb] which helped us to identify some of the bottlenecks in performance. We will publish the performance reports soon. We thank AdventNet for permitting us to make use of this interesting software and we gladly recommend it to everyone too, not because AdventNet allowed us to use it but because it is really good. We are also pleased to release the downloadable version of the [b:7141f7c5eb]vtiger CRM PHP API Documentation.[/b:7141f7c5eb] The demo of vtigerCRM 5 alpha 5 is available at http://vtiger.com/products/crm/demo_5alpha/index.php You can download the [b:7141f7c5eb]EXE, BIN, or tar.gz[/b:7141f7c5eb] from Sourceforge.net. [b:7141f7c5eb]NOTE:[/b:7141f7c5eb] We strongly recommend CRM community NOT to USE vtiger CRM 5 Alpha 5 for real-time deployment. In case you are looking for an immediate CRM solution for your business, please consider using the vtiger CRM 4.2.3 (latest stable version) or 4.2.4 which will be out shortly. [b:7141f7c5eb]Important URLs:[/b:7141f7c5eb] [b:7141f7c5eb]Download:[/b:7141f7c5eb] http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=186641 [b:7141f7c5eb]Report Bugs[/b:7141f7c5eb] @: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Note: Please refer to the reported bugs before submitting a new bug. [b:7141f7c5eb]Release Notes:[/b:7141f7c5eb] * Smarty template applied to Currency Configuration Feature * List View feature database queries are optimized for all the modules * PHP API documentation for some of the major function * New module called Marketing is added. Campaigns module is now part of Marketing primary module. * AJAXified Notification Schedulers * AJAXified Inventory Notifications * AJAXified Picklist Settings * AJAXified Assign Module Owners * New UI for Integration of Mail Merge Templates * New UI for Company Information * New UI for Outgoing Mail Server * New UI for Backup Server Configuration * New UI for Terms and Conditions * New UI for Announcements * New UI for RSS module Thanks & Regards, Don ----------------------------------------------- You are receiving this email because you are watching the forum, "Announcements" at vtiger. If you no longer wish to watch this forum you can either click the "Stop watching this forum link" found at the bottom of the "Announcements" forum, or by clicking the following link: http://forums.vtiger.com/viewforum.php?f=1&unwatch=forum -- Thanks, The Management -- I would rather be a serf in a poor man's house and be above ground than reign among the dead From dgrant at accuratetechnologies.com Wed Jul 19 05:58:46 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 19 Jul 2006 08:58:46 -0400 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Simple question: when is the next (Beta?) release of V5.0 due out? DG From richie at vtiger.com Wed Jul 19 06:22:20 2006 From: richie at vtiger.com (Richie) Date: Wed, 19 Jul 2006 06:22:20 -0700 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? In-Reply-To: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Message-ID: <10c86f3829c.5523764322808677804.-2671785383507032457@@vtiger.com> Simpler answer :-): No betas. Expect RC1 in 10 days or so. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Simple question: when is the next (Beta?) release of V5.0 due out? DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/e1ba94eb/attachment.html From Matjaz.Slak at atol.si Wed Jul 19 07:45:49 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak@atol.si) Date: Wed, 19 Jul 2006 16:45:49 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Message-ID: Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/smime.bin From developer at infointegrated.com Wed Jul 19 21:45:03 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Wed, 19 Jul 2006 23:45:03 -0500 Subject: [Vtigercrm-developers] Categories / Sub-Categories, Too Much In-Reply-To: References: Message-ID: If you haven't looked at the current collection of categories and subcategories, take a look. I think that it is becoming too much. Here's the current layout: My Home Page Home Activities Calendar Emails Marketing Campaigns Accounts Contacts Emails Leads Activities Calendar Notes Sales Leads Accounts Contacts Potentials Quotes Sales Order Invoice Products PriceBooks Notes Activities Calendar Support HelpDesk FAQ Accounts Contacts Products Notes Emails Activities Calendar Analytics Dashboard Reports Inventory Products Vendors PriceBooks Purchase Order Sales Order Quotes Invoice Tools RSS My Sites Notes Settings Settings I know the list is long and hard to read, but that's my point. I know and understand that different people will want their sub-modules in different places. As long as the method for changing this is documented, I think that is ok. The default configuration, though, should be simpler. This current layout is almost scary. At least for an end-user it would be. I feel this change should be made before 5.0 GA. To simplify, each item should only appear in one category. I have an updated proposal below that is the closest to meeting most of my customer's needs. With the All Menu, Quick Create, Related Items, and Tag Cloud, it shouldn't matter much if some modules are on different categories. I hope that there are still plans on combining activities and calendar into one item as well (I believe this was put off until after 5.0 GA). I think that an interface for managing these should also be planned post 5.0 GA. I also think the order of the items is important and (where relevant) the order should remain consistent. For example, the sub categories should remain in the same order under the category as it shows in the All Menu. What does everyone else think? Anyone else show this to existing clients and get questions about why the same module appears in many places? That's what got me started thinking of improvements. Any better ideas? My Home Page Home Emails Activities Calendar Contacts Notes Marketing Campaigns Leads Sales Accounts Potentials Quotes Sales Order Invoice Support HelpDesk FAQ Inventory Products Vendors PriceBooks Purchase Order Analytics Dashboard Reports Tools Settings My Sites RSS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/50687ed3/attachment-0001.htm From richie at vtiger.com Thu Jul 20 01:06:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:06:18 -0700 Subject: [Vtigercrm-developers] unable to add users to trac Message-ID: <10c8af88631.-2915976287139770639.-215398406965928840@@vtiger.com> Hi Matt! Could you please have a look at the issue please? I am unable to add users to the trac anymore. I am using the following url. vtiger.fosslabs.com/service Do have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/02abcafe/attachment.html From richie at vtiger.com Thu Jul 20 01:17:10 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:17:10 -0700 Subject: [Vtigercrm-developers] trac down? Message-ID: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Hi! The trac seems to be down. Matt, kindly have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/df8c96af/attachment.htm From mmbrich at fosslabs.com Thu Jul 20 01:24:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 20 Jul 2006 02:24:10 -0600 Subject: [Vtigercrm-developers] trac down? In-Reply-To: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> References: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Message-ID: <1153383850.5617.0.camel@localhost.localdomain> I was doing some work and had to give it a quick reboot. Should be back up and working now. Matt On Thu, 2006-07-20 at 01:17 -0700, Richie wrote: > Hi! > > The trac seems to be down. > Matt, kindly have a look please. > > Thanks, > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Thu Jul 20 02:47:37 2006 From: crm at email.si (Ales Petric) Date: Thu, 20 Jul 2006 10:47:37 +0100 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44AE643B.1040800@vtigerfacile.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> Message-ID: <44BF5139.9050402@email.si> Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Ai"ssa wrote: > Hi Richie, > i have a login for track, but not the right to submit ticket. > thanks, > Ai"ssa (very busy !) > > Richie a ?crit : > >> Hello! >> >> I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. >> Please cross-check if you have received the relevant mails in the id from which you had made the access >> request. >> >> Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. >> >> richie at vtiger dot com >> >> Richie >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/f47f9233/attachment.html From richie at vtiger.com Thu Jul 20 01:58:46 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:58:46 -0700 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44BF5139.9050402@email.si> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> <44BF5139.9050402@email.si> Message-ID: <10c8b2890c0.2475106285347017844.4336268421121807772@@vtiger.com> Hi Ales! I have granted permission to the trac to all those who have asked for it. Not even 1 single request has been denied. Why should it be? The product is as much yours as mine just that someone has to be in some hiearchy somewhere does not mean that we have a monopoly over it. This is the first time I have got your request and I have granted access to you too. The 1 minute that I spend giving permission saves hours to the community as a whole. You are important, not only to me but to the community as well. I am sure you will do well. Richie ---- Ales Petric<crm at email.si> wrote ---- Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Aïssa wrote: Hi Richie, i have a login for track, but not the right to submit ticket. thanks, Aïssa (very busy !) Richie a ?crit : Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie ------------------------------------------------------------------------ _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/aeeddad4/attachment.htm From richie at vtiger.com Thu Jul 20 08:30:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 08:30:05 -0700 Subject: [Vtigercrm-developers] permissions revoked Message-ID: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Dear Team, I have revoked permissions for checkin in the main 5.0 trunk. Only the following have permission to checkin now into the 5.0 trunk. core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj All checkins have to be thru these guys alone. The permissions will be restored once the 5.0 is released. Requesting your understanding, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/0cea747a/attachment.html From tgironnay at lexsi.com Thu Jul 20 08:54:15 2006 From: tgironnay at lexsi.com (GIRONNAY Thibault) Date: Thu, 20 Jul 2006 17:54:15 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi all, Matjaz I'll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It's too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we'll have others hands up cabugs ________________________________ De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: * debugging (fixing parts that either don't work at all and/or work incorrectly) * improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: * multilanguage support (simply get rid of any and all hard-coded strings) * full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/fdd85202/attachment-0001.htm From nolan at peaceworks.ca Thu Jul 20 10:50:43 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Thu, 20 Jul 2006 13:50:43 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: References: Message-ID: <44BFC273.5060604@peaceworks.ca> Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Thu Jul 20 10:47:54 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 20 Jul 2006 13:47:54 -0400 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE4@exch.accuratetechnologies.com> Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection My vtigercrm.log is full of these. Where are they coming from and what can I do to stop it? DG From jens at Strawberry.COM Thu Jul 20 23:34:10 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Fri, 21 Jul 2006 08:34:10 +0200 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com>; from Richie on Thu, Jul 20, 2006 at 08:30:05AM -0700 References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Message-ID: <20060721083410.A22106@Strawberry.COM> Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From Matjaz.Slak at atol.si Fri Jul 21 00:04:48 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak@atol.si) Date: Fri, 21 Jul 2006 09:04:48 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi! I agree completly. Security should be on the list of to-dos. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "GIRONNAY Thibault" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 17:54 Please respond to vtigercrm-developers at lists.vtigercrm.com To cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Matjaz I?ll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It?s too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we?ll have others hands up cabugs De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/smime-0001.bin From Matjaz.Slak at atol.si Fri Jul 21 04:36:00 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak@atol.si) Date: Fri, 21 Jul 2006 13:36:00 +0200 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <44BFC273.5060604@peaceworks.ca> Message-ID: Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Nolan Andres Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/smime-0001.bin From jtk at yahoo.com Fri Jul 21 06:09:10 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Fri, 21 Jul 2006 09:09:10 -0400 Subject: [Vtigercrm-developers] permissions revoked References: <20060721083410.A22106@Strawberry.COM> Message-ID: Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. From richie at vtiger.com Fri Jul 21 07:11:25 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:11:25 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <20060721083410.A22106@Strawberry.COM> References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916d296e.5312358042738553104.8864199634924158691@@vtiger.com> Hi Jens! Currently, we are working on fixing the breakages that we have committed. Let these stabilize, then we can integrate this together. ok? I do not want to add one more variable now. Hence the precaution. Richie ---- Jens Hamisch<jens at strawberry.com> wrote ---- Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/ed49a8d5/attachment.html From richie at vtiger.com Fri Jul 21 07:12:10 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:12:10 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: References: <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916dd6be.-546019034062113847.-6787520244753134675@@vtiger.com> Yes, you are right. We will take this into consideration before vtigercrm-5.0.0 is out. In other words, postgres is going to be part of this very release. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/51fe5c86/attachment.htm From richie at vtiger.com Fri Jul 21 07:13:48 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:13:48 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: References: Message-ID: <10c916f5716.-3447470126087516421.7834933168012625785@@vtiger.com> Matjaz, you already would have got the access mail for the trac. About the TRAC Wiki, Matt will do the needful. Let us know if you need anything else. Richie ---- Matjaz.Slak at atol.si<Matjaz.Slak at atol.si> wrote ---- Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 Nolan Andres <nolan at peaceworks.ca> Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned        Plea        froma        VTiger        Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > >   > > Matjaz I’ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It’s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > >   > > Hope we’ll have others hands up > >   > > cabugs > >   > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > >   > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > >     * debugging (fixing parts that either don't work at all and/or work >       incorrectly) >     * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > >     * multilanguage support (simply get rid of any and all hard-coded >       strings) >     * full per user or at least per-system localization support (number >       format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 > > *Richie <richie at vtiger.com>* > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > >                   > > To > >                   > > vtigercrm-developers at lists.vtigercrm.com > > cc > >                   > > vtigercrm-developers at lists.vtigercrm.com > > Subject > >                   > > Re: [Vtigercrm-developers] An Impassioned Plea from a        VTiger     >    Integrator > >   > >   > >                   > >   > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: >> >>  Hi! >> >>  If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > <http://zohoshow.com?vt/> _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7be12bf9/attachment-0001.html From allan.bush+vtiger_dev at gmail.com Fri Jul 21 08:32:23 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 21 Jul 2006 08:32:23 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <-8603876167918116646@unknownmsgid> References: <-8603876167918116646@unknownmsgid> Message-ID: <3bec26390607210832x65ed46eo60856d8e2972c110@mail.gmail.com> This is the page we should be using to keep track of everything to be done for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=new&status=assigned&status=reopened&milestone=4.2.5 It would be nice to have a 4.2.6 (or 4.2 future) milestone to keep the list realistic though. Fell free to organize, add and prioritize the things in that list. On the same note you here is the page of everything already accomplished for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=closed&milestone=4.2.5 On 7/21/06, Richie wrote: > > Matjaz, you already would have got the access mail for the trac. > About the TRAC Wiki, Matt will do the needful. > > > Let us know if you need anything else. > > Richie > > > > > ---- Matjaz.Slak at atol.si wrote ---- > > > > Hi! > > Thank you! > > I hope I'll be able to finish up some of my other tasks within a week or > so and then I'll start posting ideas about what to work on here. > > *If anybody has any general wishes and/or requests about which item(s) you > would like to have fixed in 4.2.x, post them here.* By this I mean areas > perceived by vTiger users. Try to fit them in the following categories: > > - debugging (fixing user-perceived functions that either don't work > at all and/or work incorrectly) > - improving usability (based on feedback from users) > - improving security (let us know of possible security holes) > - multilanguage support (simply get rid of any and all hard-coded > strings) > - localization support (number format, date format, currency support > etc - per user or at least per-system) > - other (we can create aditional categories if the need arises) > > > For example: > > - Private Custom Views - allow for a custom view to be marked as > private and only be visible to the user that created it (usability) > - All View columns sortable - allow a user to click on any column > and sort it (usability) > - Repeating calls/meetings - don't work at all? (debugging) > - etc... > > > I'll be collecting them and posting them somewhere - the TRAC Wiki comes > to mind as an appropriate place. We can the priorithise them and look into > required work - and then create tickets for developers (us, again :) to work > on. > > *Richie, Jeff, Matt and/or others:* would it me possible for me to have > acces to post some content to the TRAC Wiki? I would create a document like > "vTiger 4.2.x to-do area" that would include these items we wish to work > on - and specific goals for them. Tickets would then be created based on > these. This document would represent the general guideline. > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > *Nolan Andres * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 20.07.2006 19:50 Please respond to > vtigercrm-developers at lists.vtigercrm.com > > To > vtigercrm-developers at lists.vtigercrm.com cc > > Subject > Re: [Vtigercrm-developers] An Impassioned Plea froma > VTiger Integrator > > > > > > > Hi all, > > Although I'd really love to be able to just contribute features without > having to re-integrate (into v5,) I agree with priorities and I'll > second the addition of security to the list. Security through obscurity > is bad enough, but with open source projects, it simply becomes security > through ignorance. I certainly wouldn't trust vTiger's security in an > environment where the data is actually confidential and a malicious or > competitive party would stand to gain by accessing it illicitly. > > I don't have the availability to co-ordinate things, but you can count > on me for some quantity of bug-fixes, security patches, etc. > > peace, > nokes > > GIRONNAY Thibault wrote: > > Hi all, > > > > > > > > Matjaz I'll be with you and your team in your enterprise, I agree with > > your priorities and have one another to add : the security. The > > organisation sharing privileges for example is indeed totally an > > illusion. It's too easy too change those settings while not being admin > > or to see all records even if the privileges are private. I think this > > is very harmful to offer such buggy features and can discredit Vtiger > > for the people who have interests in security. > > > > > > > > Hope we'll have others hands up > > > > > > > > cabugs > > > > > > > > ------------------------------------------------------------------------ > > > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > > de* Matjaz.Slak at atol.si > > *Envoy? :* mercredi 19 juillet 2006 16:46 > > *? :* vtigercrm-developers at lists.vtigercrm.com > > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > > Integrator > > > > > > > > > > Hi Richie and the rest of the team! > > > > You address me correctly, Matjaz is my name :) > > > > > > As I belive the 4.2.x stream is the current "production" vTiger > > environment for most of the users, my primary goal would be to focus on: > > > > * debugging (fixing parts that either don't work at all and/or work > > incorrectly) > > * improving usability (based on feedback from users) > > > > > > I would also like to try and get the following not-quite-features, maybe > > > bugs? implemented/fixed: > > > > * multilanguage support (simply get rid of any and all hard-coded > > strings) > > * full per user or at least per-system localization support (number > > format, date format, currency support etc) > > > > > > These two last items are - in my opinion - somewhere between debugging > > and new features. vTiger is already supposed to support multiple > > languages, however this support is not well implemented. The same can be > > > said for localization - vTiger is supposed to be able to support > > per-user date format, but again there are areas where the implementation > > > is not as good as it could be. > > > > Also, based on my researches into existing vTiger deployments, I see > > there are a lot of non-english users, but they probably are using forked > > > code, as due to these two issues they cannot use the "official" 4.2.x > > stream code. I would like to get these users back on the team, and I > > know they might return only if we provide them with a 100% localisable > > product. This will enable them to post the patches they make back to the > > > community or at least give them an opportunity to work with us on > > resolving them. > > > > I would try and keep us on this track, rather than go try implement new > > features and make large changes to UI - the place for these is v5. > > > > > > To achieve this, I would first gather any and all contributions > > currently lying around (in the forum, as provided by other people here > > etc.) - matching the categories above - and start the process of getting > > > them in the code. *I would like to see a show of hands* from people that > > > would be prepared to devote some time to debugging/updating tthese > > contributions - as some might need an update. I know me and my > > colleagues in our company will. > > > > If all goes well, we could try and implement a regular timeline (say > > every month) when we would be releasing point versions. If I get at > > least two or three people to help, I guess we could have our first > > result (4.2.5 I guess) in two months. > > > > I think there will be people using the 4.2.x stream for at least a year > > after v5 is released, and that if we as a team show them we are > > supporting them, than they will upgrade to v5 -> if we don't they might > > start looking elsewhere. > > > > > > *Thoughts, anyone?* > > > > > > Matjaz Slak > > matjaz.slak at atol.si > > > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > > *Richie * > > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > > > 17.07.2006 16:57 > > > > Please respond to > > vtigercrm-developers at lists.vtigercrm.com > > > > > > > > To > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > cc > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > Subject > > > > > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > > Integrator > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matjaz! > > I hope I am addressing you properly if not please forgive me and direct > > to the proper mode of addressing. > > > > If you are game then great! > > Welcome to the club. > > Please select your stand-in helper so that at least we have a backup for > > > Linus Matjaz. Let me know and I will grant you the relevant access. > > > > It would be nice if you could briefly state how you plan to address the > > disparate contributions. This is just to get an idea as there are lots > > of data floating around in the code contributions and mailing lists; > > wanted to know if you have any specific plan. I will be busy with the v5 > > > release and will not be able to help you much so the query. > > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > > page which reflects the status of the contributions. I am not sure if > > that is updated till the 4.2.4 release though. > > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > > > > Allan, any tips from you will be nice. > > > > Richie > > > > > > > > > > ---- Sergio A. Kessler wrote ---- > > > > On 7/14/06, Matjaz.Slak at atol.si wrote: > >> > >> Hi! > >> > >> If there's no one else, I volunteer to be the v4 Linus. > > > > just do it. ;-) > > > > > > /sak > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > -- > > > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/411ae3e6/attachment-0001.htm From don at vtiger.com Fri Jul 21 09:31:48 2006 From: don at vtiger.com (don) Date: Fri, 21 Jul 2006 09:31:48 -0700 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <10c91edb0e4.-4543952587404481040.-9186935435207679906@@vtiger.com> Hi DG, The logs given below are generated from the include/database/PearDatabase.php file. To avoid this kindly do the following: Edit the include/database/PearDatabase.php file and comment the following lines: -- $this->println("TRANS creating new connection"); in the function checkConnection -- $this->println("ADODB fetchByAssoc return null"); in the function function fetchByAssoc Hope this helps you. Kindly contact us for any further clarifications. Thanks & Regards, Don Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7714d42a/attachment.html From jens at Strawberry.COM Tue Jul 18 00:02:14 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 07:02:14 -0000 Subject: [Vtigercrm-developers] Patches required for PostgreSQL 8.1.4 Message-ID: <20060718090201.B15699@Strawberry.COM> Hi, I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 database. Compared to mySQL this database seems to require some code changes. I've located and fixed the following problems: 1. SELECT count(*) count FROM ... won't work. The AS clause is missing: SELECT count(*) AS count FROM ... 2. Referring table columns in case of joined tables in the SELECT or ORDER BY clause requires the columns also to be listed in a GROUP BY clause. 3. tablename.* won't work in a GROUP BY clause 4. LIMIT #,# is not supported. PostgreSQL requires a single LIMIT and OFFSET clause. 5. PostgreSQL supports transactions. However the current coding results in transaction failures. I've attached my patches to this mail. Those patches at a first glance address the problems 1-4. The transaction problem is not yet fixed. I want to clean up the "simple" SQL statements first, before analyzing such complex things. I'm not a 100% satisfied with the patches, because they introduce some dbType dependencies into the "high level" vtiger code. Also structural information is required in the function which expands the queries by the required GROUP BY clause. I was thinking of moving those things to a more abstract layer, but stopped doing this, because a generic solution would either result in parsing and fixing each entire SQL statement (including all its features and possibilities) or a redesign of the affected SQL queries itsself. In most cases (especially the LIMIT changes) my patches might also work for mySQL, so the database dependency possibly could be removed. This might also apply to some of the GROUP BY patches. Hope those changes will find their way to the vtigercrm5 mainline. Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- A non-text attachment was scrubbed... Name: postgres-patches.tgz Type: application/octet-stream Size: 18385 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/e9b482c8/postgres-patches-0001.obj From richie at vtiger.com Tue Jul 4 07:02:55 2006 From: richie at vtiger.com (Richie) Date: Tue, 04 Jul 2006 04:02:55 -0700 Subject: [Vtigercrm-developers] update bleeding edge svn Message-ID: <10c393477d3.4701894980957041264.-7646275652836694714@@vtiger.com> Hi Matt! Wanted to confirm if we have a script in place for updating the latest code in the vtiger-demo.fosslabs.com site? There have been forum queries if the updates are happening in the first place. Kindly inform. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060704/3631a295/attachment-0002.html From saint at vtiger.com Tue Jul 4 14:40:33 2006 From: saint at vtiger.com (Saint) Date: Wed, 05 Jul 2006 00:10:33 +0530 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings Message-ID: <44AAB621.8080701@vtiger.com> Folks, The following are the new "Settings" icons getting into vtiger 5. *Module * *Icon * Users Roles Privilege Profiles Groups Modules Access Fields Access Module Owners Announcements Custom Fields Picklist Editor Email Templates Mail Merge Tempaltes Notification Schedulers Inventory Notifications Inventory Terms & Conditions Company Details Mail Server Settings Backup Server Settings Proxy Server Settings System Information Invoice Configuration Audit Trail Tax Configuration Currency Settings Migration -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1968 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0048.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1951 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0049.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2197 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0050.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2328 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0051.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2134 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0052.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2319 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0053.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1925 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0054.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2267 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0055.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1883 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0056.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1957 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0057.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2160 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0058.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2175 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0059.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1975 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0060.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2264 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0061.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2370 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0062.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1732 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0063.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2121 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0064.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1972 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0065.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2182 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0066.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2492 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0067.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2546 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0068.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1796 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0069.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2441 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0070.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2451 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0071.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: set-IcoMigration.gif Type: image/gif Size: 2187 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0072.gif From sergiokessler at gmail.com Tue Jul 4 15:09:33 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 4 Jul 2006 16:09:33 -0300 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings In-Reply-To: <44AAB621.8080701@vtiger.com> References: <44AAB621.8080701@vtiger.com> Message-ID: <49216030607041209h171b32d1w9b6e737e1c65a5a8@mail.gmail.com> wow, beautiful ! /sak On 7/4/06, Saint wrote: > > > Folks, > > The following are the new "Settings" icons getting into vtiger 5. > > > Module > Icon > > Users > > > Roles > > > Privilege Profiles > > > Groups > > > Modules Access > > > Fields Access > > > Module Owners > > > Announcements > > > Custom Fields > > > Picklist Editor > > > Email Templates > > > Mail Merge Tempaltes > > > Notification Schedulers > > > Inventory Notifications > > > Inventory Terms & Conditions > > > Company Details > > > Mail Server Settings > > > Backup Server Settings > > > Proxy Server Settings > > > System Information > > > Invoice Configuration > > > Audit Trail > > > Tax Configuration > > > Currency Settings > > > Migration > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From don at vtiger.com Wed Jul 5 11:59:39 2006 From: don at vtiger.com (don) Date: Wed, 05 Jul 2006 08:59:39 -0700 Subject: [Vtigercrm-developers] vtiger CRM 5.0 Beta2 Released Message-ID: <10c3f6a8177.-9001623588305850621.-4297454805191080021@@vtiger.com> Hi All, We are pleased to announce the release of vtigerCRM 5.0 Beta 2. In this release the main focus is on the quality front and we have fixed most of the major bugs that were in the vtigerCRM 5.0 Beta. We have also incorporated most of the feedbacks/suggestions given by the community over 5.0 Beta. In the UI front, the Settings UI has been totally revamped. This release will depict the developments done after vtiger CRM 5.0 Beta. You can give it a try and let us know your valuable feedbacks and suggestions. The live demo of vtigerCRM 5.0 Beta is available at http://vtiger.com/products/crm/demo_5beta/index.php You can download the vtiger CRM 5.0 Beta2 from the following URL : http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=196218&release_id=429844 You can post your feed backs and suggestions at http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Thanks & Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/59d438e1/attachment.html From nico.gnauck at googlemail.com Thu Jul 6 13:12:58 2006 From: nico.gnauck at googlemail.com (Nico Gnauck) Date: Thu, 6 Jul 2006 19:12:58 +0200 Subject: [Vtigercrm-developers] Merge with OpenOffice documents Message-ID: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Hello, I'm currently working on a Mail Merge for version 5.0 with Open Office Dokuments based on the rtf Merge for version 4.2.3. You can find the thread and the Merge skripts for Accounts and Contacts in this thread: http://forums.vtiger.com/viewtopic.php?t=7223. If anybody has time to test this, please do so and give me feedback. Thanks, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/776050fd/attachment-0002.html From mmbrich at fosslabs.com Thu Jul 6 13:32:44 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 06 Jul 2006 11:32:44 -0600 Subject: [Vtigercrm-developers] Merge with OpenOffice documents In-Reply-To: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> References: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Message-ID: <1152207165.22922.96.camel@localhost.localdomain> Hi Nico, I haven't had a chance to test yet but I did merge this into my vtiger5 branch in the branches/ directory of the SCM system. I will get it tested as soon as I can, from there the other developers can decide if it should be merged into trunk/. If you find/fix issues in this branch please post the patches here and I will get them merged in. If you have enough issues and would like, I can set you up with commit access to my branch. Thanks for your contribution! Matt On Thu, 2006-07-06 at 19:12 +0200, Nico Gnauck wrote: > Hello, > > I'm currently working on a Mail Merge for version 5.0 with Open Office > Dokuments based on the rtf Merge for version 4.2.3. > You can find the thread and the Merge skripts for Accounts and > Contacts in this thread: > http://forums.vtiger.com/viewtopic.php?t=7223. > If anybody has time to test this, please do so and give me feedback. > > Thanks, Nico > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Thu Jul 6 16:17:20 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Thu, 06 Jul 2006 16:17:20 -0400 Subject: [Vtigercrm-developers] Trac 0.9.6 released Message-ID: Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. From richie at vtiger.com Fri Jul 7 01:22:12 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:22:12 -0700 Subject: [Vtigercrm-developers] trac account Message-ID: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/f616fb9d/attachment.html From richie at vtiger.com Fri Jul 7 01:25:43 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:25:43 -0700 Subject: [Vtigercrm-developers] update svn-version Message-ID: <10c4772d440.733718465091492167.4729172311574536110@@vtiger.com> Hi! Got this mail in the forums. Can someone do the needful please? Jeff, what do you say? "Hi forum users and especially vtiger admins, im not quite sure, if this is the right place to post, but i think you guys should really consider updating your subversion server to > 1.2.x. For us developers using eclipse it's painstaking to get it to work well, because the svn plugin (subclipse.tigris.org) only supports the old svn servers (< 1.2.0) only if you choose to install a very old version of the plugin (< 0.9.3.0). Unfortunately, this version of the plugin is very buggy, and i can't get it to work properly in my env, especially with eclipse 3.1. It maybe a little selfish to request an update, just because of me not getting my setup to work, but svn has improved so much from 1.1.x to 1.2.x so it might be usefull for everyone. Regards Benjamin" Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/606fa218/attachment-0002.html From richie at vtiger.com Fri Jul 7 01:28:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:28:56 -0700 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com Message-ID: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Hi! Is the vtiger-demo.fosslabs.com updated with the bleeding edge code please? Matt, I guess, we are putting a lot of stress on you alone and it is not fair. Do you think you require some guys from the community to assist you? My main concern is that not any single individual be overloaded. vtiger is team-work and it should be that way. Everyone should prosper. Dedicated volunteers please raise their hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/4782857f/attachment.html From richie at vtiger.com Fri Jul 7 01:31:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:31:56 -0700 Subject: [Vtigercrm-developers] Trac 0.9.6 released In-Reply-To: References: Message-ID: <10c47788588.1738553798220722432.6769330270375144874@@vtiger.com> Let us get this upgraded then. Jeff, would you take ownership for all the 3rd party upgrades please. I know you are already tracking the 3rd party packages but what I am stating is to take ownership for all upgrades for the s/w used to keep track of vtiger? If you need assistants, give a shout in the mailing list. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/1aaf8fb0/attachment-0002.html From webmaster at vtigerfacile.com Fri Jul 7 09:40:11 2006 From: webmaster at vtigerfacile.com (=?UTF-8?B?QcOvc3Nh?=) Date: Fri, 07 Jul 2006 15:40:11 +0200 Subject: [Vtigercrm-developers] trac account In-Reply-To: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Message-ID: <44AE643B.1040800@vtigerfacile.com> Hi Richie, i have a login for track, but not the right to submit ticket. thanks, A?ssa (very busy !) Richie a ?crit : > Hello! > > I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. > Please cross-check if you have received the relevant mails in the id from which you had made the access > request. > > Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. > > richie at vtiger dot com > > Richie > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Fri Jul 7 23:23:02 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 21:23:02 -0600 Subject: [Vtigercrm-developers] New communications system Message-ID: <1152328983.32174.36.camel@localhost.localdomain> I wrote a new CommSystem module in my 5.0.2-MMBRICH branch. The comm system is a full replacement for the chat system from RC1 and also adds a host of API's to manipulate it from your favorite external system or vtiger module :). Here is a short list of features, any testers or patches to help move it along are appreciated. Features: 1) Full P2P chat 2) Session/Off-line messaging capabilities (ie: if a new message comes in right when you click on a link in the system, when the new page loads you will see the message that appeared as the page was being reloaded). 3) Follows your window focus. If you have multiple tabs open in the CRM, you will only get new messages and status messages in the focused window. All messages are cached when there is no focus on a CRM window. 4) Alert/Event messages. An "MSN like" status box that appears at the bottom of your browser to alert about new emails, voicemails, incoming calls, etc. It has pretty effects to make it slide in and out for alerts :). 5) "User is typing" status messages. 6) Email messages from either periodic checks via JSON or can also be injected via scripts. (Ie: incoming emails to helpdesk at domain.com could be announced to users x,y and z) 7) Simple CommSystem.php and CommSystem.js classes to manipulate the alerts and chat system. CommSystem.js is wrote to follow prototype standards as much as I could get it to. ToDo: 1) Finish the group IM feature. 2) Lots of ugly, needs UI work. 3) Support Portal integration ("Chat with Live Help" links in the portal) 4) Message archives so that old messages can be deleted from the CRM (maybe a monthly cron script to backup and delete the messages from the DB). 5) Asterisk AGI Script and SOAP functions to inject Voicemail or Incoming call alerts 6) Cron scripts to populate email alerts? 7) Fix annoying bugs (Ie: '\n\r' breaks sending messages) 8) Internationalization 9) Test, test, test 10) Jabber connector? Drawbacks to this system: 1) Makes a request to the server every N milliseconds to check for new messages, alerts or status updates. This gets heavy on the server. One way to take load off the server is with the focus tracking mentioned above. Un-focused windows will not make requests back to the server. Another way is to create a decay timer like the one used in the prototype Ajax.PeriodicalUpdater() class. This basically checks the last output status and compares it to the current output status. If they are the same then N = (N*) and if the current output status is diff than the last output status N=(N). 2) The whole system is one large timer loop and global references to the CommSystem.js class have to be created to access the class within the loop. This is a memory usage issue but shouldn't be too noticeable for most. 3) Probably a 70% client side and 30% server side system. Thats a lot of javascript. If you get a chance to check it out, let me know what you think and if you'd like to see something like this in vt5 going forward. Matt From mmbrich at fosslabs.com Sat Jul 8 00:15:14 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 22:15:14 -0600 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com In-Reply-To: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> References: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Message-ID: <1152332114.32174.40.camel@localhost.localdomain> On Thu, 2006-07-06 at 22:28 -0700, Richie wrote: > Hi! > > Is the vtiger-demo.fosslabs.com updated with the bleeding edge code > please? I updated it the day RC1 came out but haven't since then. It is currently not automated. > Matt, I guess, we are putting a lot of stress on you alone and it is not fair. > Do you think you require some guys from the community to assist you? > > My main concern is that not any single individual be overloaded. vtiger is team-work and > it should be that way. Everyone should prosper. The workload isn't too bad yet but any help is more than welcomed! > Dedicated volunteers please raise their hands! Matt From richie at vtiger.com Mon Jul 10 08:36:35 2006 From: richie at vtiger.com (Richie) Date: Mon, 10 Jul 2006 05:36:35 -0700 Subject: [Vtigercrm-developers] move to trac-0.9.6 Message-ID: <10c58706195.1364243099676550119.-2686427800793695304@@vtiger.com> Hi! Anyone game to help us move to trac-0.9.6 so that we can utilize the latest and greatest features? Matt, send me a mail with the access to the machine. Also let me know what steps to follow to upgrade. If no one does it, I will have it done. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/cc4fdd2a/attachment.html From mmbrich at fosslabs.com Mon Jul 10 17:09:03 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 15:09:03 -0600 Subject: [Vtigercrm-developers] UI help Message-ID: <1152565743.32174.120.camel@localhost.localdomain> In case no one noticed in the past I suck @ UI design so I figured we would see who wants to step up to the plate on this one. Right now I need the following things, if you want to take one just say so that way no one else duplicates your work. 1) De-Duplication system for settings module. I want this to be able to delete/merge/etc records that can be matched based on certain criteria. I'll write the search engine and logic system to merge/de-dup if someone wants to take on the UI :). I was thinking about having this work in steps. Step 1: select search criteria. Step 2: display duplicate results that are candidates for merge/delete, un-select records from the list via checkbox. Step 3: Select fields to merge or other action to take (delete). Step 4: Execute actions. There was a bounty on this in the forums. If that pans out you'll get a chunk, let me know what you think is fair for your time/effort. 2) Geolocation/Action tracking for email campaigns. This will be a simple popup window that should show a list of the commands from that email (ie: open, followed link, unsubscribed, etc) in one html tab and then the google map to show the actual locations those commands were executed at in another tab. Most likely I will just push one XML descriptor up to google maps to display the country/state/town the email was opened in, but I want to be able to push multiple XML descriptors to google in cases where more than one location is tracked. These extra descriptors can be used to mark possible forwards for that email. Along with this feature we'll need a simple settings area to input your google maps key. 3) Default email unsubscription page. This is a simple page that is visited when a user clicks on the 'unsubscribe' link in emails. The page should have a nice header, a hello message or something, give the user a choice to unsubscribe from that campaign or from all lists in the CRM and then display a success or failure message depending on the result from the CRM's attempt to remove them. If the unsubscribe fails the page should display the company info from the DB so that the user can write in or call to have their information removed. 4) Workflow module? I thought I saw a post that the vtiger crew was going to take this on. If thats the case then this one is void and we don't need to worry about it. Otherwise, go check out the bounty, let me know what you think is a fair cut for your work, then submit me your ideas. If the bounty pans out you'll get a cut of course. 5) Communications system. This is built and ready enough for beta. I need a p2p chat window, group chat window, right hand 'slider' (to show who is online, etc) and we should probably do something with the alert slider as well, it's very plain. The fun part about the chat windows is that none of them are built with HTML so you'll have to do most of the design in CSS. You can also look into the scriptaculous Builder() function for more info on how I create the chat windows, there is flexibility in how you can design them so you're not necessarily restricted to css only. Also could use a chat window for the customer portal if you're up to it :). 6) Direct Mail Designer. This is still on the drawing board but it would be super cool. The idea is to have a list of templates in the "Direct Mail" campaigns that could be merged with the campaign records. Sounds familiar right? Well it would build off of the current merge system by allowing .rtf and .odt files to be merge templates but would also make use of a 'packaging' standard. Basically this packaging (a tarball or zip file) would have a templatename.xml file that would have things like params and thumbnail images and other useful information for merging, etc. This has the ability to have services packaged around it (like we could define an API for designers to make their designs available for pre-set prices and also printing companies to actually do the printing.) Lots of possibilities, if you decide this one is interesting, email me on or off list and we can start a discussion about how this could work. This is candidate for a forge project so if there is enough interest I might just open one. All of this stuff is being created in my branch. I'll give you access to my sandbox area on vtiger-demo.fosslabs.com so you can track stuff and help out. I have every intention of doing these myself if no one takes them, but I can say that I have no skill in UI design whatsoever :). Matt From mmbrich at fosslabs.com Mon Jul 10 23:58:53 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 21:58:53 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590333.16985.2.camel@localhost.localdomain> This is an example screen of what I would like to do for managing campaign actions. If there is a way to tell the campaign type, even when using a diff language or changing the picklist, then I wouldn't have to show every single action. Opinions? Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-24.png Type: image/png Size: 66134 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/86b7c2be/attachment.png From mmbrich at fosslabs.com Tue Jul 11 00:02:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 22:02:49 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590570.16985.4.camel@localhost.localdomain> Here is a screenie of the current comm system if anyone wants to give suggestions. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-25.png Type: image/png Size: 77505 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/854ed82e/attachment.png From dgrant at accuratetechnologies.com Tue Jul 11 14:12:38 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 11 Jul 2006 14:12:38 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG From jtk at yahoo.com Tue Jul 11 17:12:32 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Tue, 11 Jul 2006 17:12:32 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone From sergiokessler at gmail.com Tue Jul 11 18:37:23 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 11 Jul 2006 19:37:23 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> dennis, On 7/11/06, Dennis Grant wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak From mmbrich at fosslabs.com Tue Jul 11 21:58:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 19:58:10 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <1152669490.16985.122.camel@localhost.localdomain> > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt From mmbrich at fosslabs.com Wed Jul 12 00:06:12 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:06:12 -0600 Subject: [Vtigercrm-developers] 5.x webmail changes Message-ID: <1152677172.16985.144.camel@localhost.localdomain> I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt From mmbrich at fosslabs.com Wed Jul 12 00:20:56 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:20:56 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152590570.16985.4.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> Message-ID: <1152678056.16985.149.camel@localhost.localdomain> I'm going to keep posting these hoping that someone will finally get fed up with the ugly and help out ;). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-26.png Type: image/png Size: 90999 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-27.png Type: image/png Size: 67631 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-28.png Type: image/png Size: 90831 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0002.png From saint at vtiger.com Wed Jul 12 02:09:35 2006 From: saint at vtiger.com (Saint) Date: Wed, 12 Jul 2006 11:39:35 +0530 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152678056.16985.149.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> Message-ID: <44B4921F.8020402@vtiger.com> Matt.. I am aware that, the campaigns module is fairly attended in the UI front. I am in the middle of other works. So give me a few more days.. I will hop in and check it out :-) -Saint Matthew Brichacek wrote: > I'm going to keep posting these hoping that someone will finally get fed > up with the ugly and help out ;). > > Matt > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90999 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 67631 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0007.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90831 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0008.png From dgrant at accuratetechnologies.com Wed Jul 12 09:41:28 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 12 Jul 2006 09:41:28 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) { bar; } vice if ($foo) { bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG From sergiokessler at gmail.com Wed Jul 12 09:48:28 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Wed, 12 Jul 2006 10:48:28 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From jtk at yahoo.com Wed Jul 12 10:06:57 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Wed, 12 Jul 2006 10:06:57 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). From mmbrich at fosslabs.com Wed Jul 12 11:16:41 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:16:41 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <1152717401.16985.280.camel@localhost.localdomain> On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt From mmbrich at fosslabs.com Wed Jul 12 11:48:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:48:52 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <1152719332.16985.289.camel@localhost.localdomain> I have started doing the query part as I run into them in my branch. I'm also moving the query strings out of functions like get_leads() and putting it in get_related_leads_query() instead. This way the query can be used for other things.. like for example if you want mostly the same output of get_leads() but without the HTML that manged to find its way out of the presentation layer and into the data layer... don't get me started on that. Anyways, with the HUGE db query strings that are used in the system, breaking them into separate short lines is a great suggestion for manageability and if it makes merges easier it's like getting your cake and eating it too :). Matt On Wed, 2006-07-12 at 10:06 -0400, Jeff Kowalczyk wrote: > Dennis Grant wrote: > > Actually, I think with VTiger you are going to see a lot of private > > forks, because individual businesses have their own needs and wants that > > are supersets of core VTiger functionality that simply don't apply to > > other businesses. > > This is one of the reasons why I care about making the source more > merge-friendly (particularly short, vertically formatted SQL statement > string lines). > > If we can get the codebase to the point where branching and merging is a > manageable burden, customization branches have a fighting chance to be > maintained in the repository. Or use a distributed repository such as > bazaar-ng can be used (bzr has a trac backend now). > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 13:16:13 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 11:16:13 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <44B4921F.8020402@vtiger.com> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> <44B4921F.8020402@vtiger.com> Message-ID: <1152724573.16985.290.camel@localhost.localdomain> Gracias, in the mean time I will keep working on the back-end and breaking stuff. Matt On Wed, 2006-07-12 at 11:39 +0530, Saint wrote: > Matt.. > > I am aware that, the campaigns module is fairly attended in the UI > front.I am in the middle of other works. So give me a few more days.. > I will hop in and check it out :-) > > -Saint > > > > > Matthew Brichacek wrote: > > I'm going to keep posting these hoping that someone will finally get fed > > up with the ugly and help out ;). > > > > Matt > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > ____________________________________________________________________ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 23:39:08 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 21:39:08 -0600 Subject: [Vtigercrm-developers] vtiger.fosslabs.com maint Message-ID: <1152761948.16985.311.camel@localhost.localdomain> I am going to shut the vtiger.fosslabs.com machine down this weekend for hardware upgrades. When I bring it back up I plan to snapshot and upgrade SVN. Expect the access to the system to be spotty over the weekend. I am tentatively scheduled to do the work on Saturday evening @ 11PM MST but that may change depending on other upgrades being done at the same time. Matt From richie at vtiger.com Thu Jul 13 04:43:03 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:43:03 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670da880.830325448603459473.-9072372394275150906@@vtiger.com> Hi DG! Your comments are well taken. These will be in place at the earliest. I know that this will be a quick fix but instructions have been sent across to have the code properly commented from now on for any future development/bug fixes. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/488cba6b/attachment.html From richie at vtiger.com Thu Jul 13 04:44:36 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:44:36 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670f131a.7768422503650913231.-7005067799642887197@@vtiger.com> I am game for it . Any takers? What is the procedure and how do we guarantee that there are no breakages? Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f2aae45a/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:46:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:46:05 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <10c67107064.-1678188602298141788.6045287401021222103@@vtiger.com> I second /sak. Contribute your code and we will have it in the 4.2.x branch and then have it subsequently ported to the 5.x too. We could have done it much earlier but it is far too late to get any contributions into 5.x at this stage. As far as possible, keep your changes in separate files so that they can be function invoked from the core code. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- dennis, On 7/11/06, Dennis Grant <dgrant at accuratetechnologies.com> wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/8bd60cb5/attachment.html From richie at vtiger.com Thu Jul 13 04:49:51 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:49:51 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <10c6713e13e.2152742122979094039.4943172801070965118@@vtiger.com> I agree with Matt. We have just started to work on a API-basis. The APIs will be difficult to use initially no doubt. I expect the APIs to be APIs like by 5.2 only as it is a huge change in mindset. Moreover, whatever APIs we have now, have to be properly documented and made much more usable. Matt has pointed out quite a few lacunaes and I do assure you that we do intend to fix them. Guidance and direction on the implementation toward achieving the same are welcome. To all System Integrators, yes, I do understand your pain. But, please understand getting rid of legacy code is much easier said than done. As of now, we will have to live with what we have. Post 5.0, we will make appropriate changes. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/889d7c68/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:51:01 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:51:01 -0700 Subject: [Vtigercrm-developers] 5.x webmail changes In-Reply-To: <1152677172.16985.144.camel@localhost.localdomain> References: <1152677172.16985.144.camel@localhost.localdomain> Message-ID: <10c6714f425.4775035562108243105.2718638484930626999@@vtiger.com> No probs Matt. If it does not work, let us give what works the best way we can. We will revisit this later. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/23b5e029/attachment.html From richie at vtiger.com Thu Jul 13 04:54:53 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:54:53 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c67187bff.-5041963494012382301.4384583989565056693@@vtiger.com> I take all your comments with eyes closed. Kindly expect the changes asap. Please do refer to my prev mail. Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless. So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now. The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) {  bar; } vice if ($foo) {  bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/6f714b17/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:56:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:18 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <10c6719c9f2.-6173366446330663734.-8914245299430889257@@vtiger.com> Well, well, /sak, hold on! We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)! Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/609744b4/attachment.html From richie at vtiger.com Thu Jul 13 04:56:58 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:58 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c671a6747.4209201887890377357.8473992930050161702@@vtiger.com> Ok Jeff. This is new to me. Guide me on this. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/1901e1ee/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:58:39 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:58:39 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152717401.16985.280.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> <1152717401.16985.280.camel@localhost.localdomain> Message-ID: <10c671bf103.1188771339393133750.-7786000437306059540@@vtiger.com> I agree with you Matt. I will post a separate mail to have the private forkers to have their codes submitted for integration to whichever trunk needed. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/dca318ca/attachment.html From richie at vtiger.com Thu Jul 13 06:46:19 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 03:46:19 -0700 Subject: [Vtigercrm-developers] Calling all private 4.x development owners Message-ID: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Hi! This is a call to all the 4.x private development owners. Many of you would have been working on your own version of vtiger as you would have customized it to your own needs. This is a call for those guys. The intent is to aggregate most of the common features that you have built and have them integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch or even in the 5.x branch as needed by the community. Pros: By doing the above, you will be able to be in sync with the latest and greatest developments happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a read as one would think of but we are working on it. Yesterday we had comments about the code not being properly commented, we are working on that right now even as I type this post. So, the idea I am conveying is that we are not perfect but are listening to the comments and taking actions too. Hence, please do keep the faith. Cons: By maintaining your own code bases, you lose out on the community benefits like identifying bugs, feature integration, new ideas, etc. We welcome your contributions. Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise the folly. Let us get on with it and make vtiger a success. I have learnt from my past mistakes. Join the team, come on board. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/65c2edda/attachment-0002.html From dgrant at accuratetechnologies.com Thu Jul 13 10:47:52 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 10:47:52 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... Yeah, but is it worth it? The 4.x codebase is really - sorry guys, I don't mean to take shots at you - but let's face it; it's really very nasty. Some of it is a good deal better than others... but there are three or four different coding paradigms all mixed together just on database queries alone, never mind display models and modularity and whatnot. It *works* great, but it's a serious bitch to maintain. As I mentioned earlier, I haven't looked at the 5.0 codebase, but it is my hope and expectation that it is a lot better. > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, No kidding.... > and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > I mean, if you are going to fork, then fork in all it's glory... Dude, I *NEVER* wanted to fork. I'd be *MUCH, MUCH* happier if I could run a vanilla install of VTiger with zero custom code in it. I was forced into forking by a lack of response from the core dev team, yes - but more so by the fact that I had users who wanted features and I needed to get them done NOW. > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Ahem. I tried to get patches into the core. I tried to get the dev team to do stuff by reporting bugs and providing detailed debug info. But there are limits as to how much time in a day I can burn trying to get an unresponsive dev team to fix my bug. "Why is this still broken?" "Well, I reported it to VTiger last month, and they haven't fixed it yet....." That just doesn't cut it. > My point was that we should find > a way to welcome these wayward forks back to the fold. How? I dunno.. Well, the way I'm going to do it is to roll all my features into 5.0 (which is a huge job, but so it goes) and then cut a patch set for merging into the main core. My expectation is that VTiger's version of Linus (or Alan Cox, or whoever) will then go through the patch set, and then either merge or reject patches based on merit - just like in the kernel. I will then work on trying to address concerns with my rejected patches, so as to get them accepted, except in cases where the patch is clearly local in scope - and those I will maintain myself. BTW, who is the local Linus? > So after the wind clears.. my point really comes down to getting all > these folks who are working on private forks to come back to the > community project, regardless of their justification (or lack of) for > the fork. In an OSS project your most valuable resource is your > developers and if we can find a way to get them back it will be well > worth it IMHO. I agree - and the best way to do that is to be RESPONSIVE. I understand that *my* problem may not be the top priority. I understand that core dev team members are NOT going to just drop everything and look after me. But I *do* expect a response, and to get into the pipeline, and to be given reasonably regular status updates on the status of my problem. And if I submit a patch, I expect it to be reviewed and either accepted or rejected in a reasonable timeframe. I don't know how many of you were/are involved in Linux kernel development, but I used to get help from people like Alan Cox and Linus on a regular basis. If a particular bit of hardware wasn't working, and it looked like a bug in Linux kernel code, we'd trade emails on a daily basis to debug the problem. That's the level of service we're talking about. And this is a good start: > Your comments are well taken. These will be in place at the earliest. > I know that this will be a quick fix but instructions have been sent > across to have the code properly commented from now on for any future > development/bug fixes. Thanks! DG From sergiokessler at gmail.com Thu Jul 13 11:40:25 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Thu, 13 Jul 2006 12:40:25 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> Message-ID: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak From allan.bush+vtiger_dev at gmail.com Thu Jul 13 11:59:48 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Thu, 13 Jul 2006 08:59:48 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From dgrant at accuratetechnologies.com Thu Jul 13 12:10:09 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 12:10:09 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CD8@exch.accuratetechnologies.com> > > BTW, who is the local Linus? > unfortunely, there is no local linus, Who is in charge of V5? Who is the core dev team leader? > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) Uh... thanks, but I'm going to have to pass. At this point, with V5 (seemingly) approaching completion, V4 is a dead end. I intend to move forward on V5 and get away from V4 as fast as I can. DG From jeri at vtiger.com Thu Jul 13 21:04:37 2006 From: jeri at vtiger.com (Jeri John) Date: Thu, 13 Jul 2006 18:04:37 -0700 Subject: [Vtigercrm-developers] Latest Docs updated Message-ID: <10c6a904f47.6172353167700401689.-5432537231218327818@@vtiger.com> Dear team, The latest Docs for vtigerCRM 5.0 beta 2 is updated, and it is available in the following url. http://vtiger.com/products/crm/phpdocs/index.php Thanks & Regards, Jerry. ------------------------------------------ D.Jeri John Skype: jerijohn_vtiger Toll Free: +1 877 788 4437 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f9eb2259/attachment.html From mmbrich at fosslabs.com Thu Jul 13 21:16:45 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 19:16:45 -0600 Subject: [Vtigercrm-developers] Custom fields for activities Message-ID: <1152839806.16985.560.camel@localhost.localdomain> Does anyone have plans to implement custom fields in the activities module? Matt From mmbrich at fosslabs.com Thu Jul 13 22:16:38 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 20:16:38 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <1152843399.16985.611.camel@localhost.localdomain> I have some ideas for cleaning up the structure of vtiger as we move forward. I am just going to lay them out here, let me know what you think. My basic idea comes down to writing wrapper classes that are used to abstract most of the unnecessary functions from developers and instead provides a uniform API to access modules, permissions, input, etc. The idea comes in three pieces. Common UI classes, most of which is already done with the new UI. A "mainframe" engine similar to the joomla $mainframe. And last but certainly not least is an entity engine that would abstract most of the entity details from developers and truly provide the unified API. Lets start with the big one, Entity Engine: The entity engine would be accomplished in three steps. The first step is to move all common variables and functions into the EntityEngine class (which extends CRMEntity). The entity engine would go into the DB to populate these with the correct info. For example tab_name, tab_name_index and all the other most common variables would be stored in the db and populated when the entity engine has a request for that module. The next step would be to create common set of functions in this class that would be exposed to the developer. The initial functions I can think of are things like get/set functions for different field values, etc. The last step to the entity engine would be an XML install system. If a developer came along and wanted to create a simple data collection module, like the current campaigns module, they would simply create an XML file that defines all the fields to be displayed, what relationship types are allowed, etc. The entity engine would then create the correct tables, populate the needed tables for the entity engine (the ones holding tab_name, etc) and register the new entity type with the system. This leads into the UI system because if the developer is just creating the XML file, how are common views displayed (list, detail, edit, relatedlists)? The UI system would be a set of classes to extend smarty and again abstract the gory details of the internal workings from the developer. VTigerUI::DetailView($entity) would follow a flow: 1) Display all common elements (header, etc): $this->createTigerHeader(); 2) Display the common 2 tab display for edit/detail/related views $this->getCommonUI("DetailView"); 3) Create a block for each block type in the DB, and create the fields for it as well. $this->assign("NUM_BLOCKS",sizeof($entity->blocks)); foreach($entity->blocks as $blockid=>$fields) { $block_fields = array(); foreach($fields as $fieldname=>$field_data) { $block_fields = $this->CreateEditField($fieldname,$field_values); // creates new edit fields based on uitype and returns an array as $array[sequence_number] = "HTML output" } $this->assign("BLOCK_".$blockid,$this->addBlock($blockid, $block_fields)); } 4) Display data :) And just like magic, the ListView, DetailView, EditView and CallRelatedList files can all go away and these common views can be managed in a much easier way. Next, the mainframe. In joomla (as far as I understand) the mainframe is meant to handle all GET, POST, REQUEST and SESSSION variables and it also sanitizes that input before giving it to the developer ($mainframe->get_input("REQUEST","data")). On top of this it handles some user security and other things. In vtiger I could see it being used for many similar things. Take for example the CreateDetailField() function call above. Inside of this call would be: if($mainframe->is_allowed("Detail",$field->id)) { stuff.. else return; There are still other details to be worked out, but you see that this isn't a _really_ large change for the flexibility it will give you in the system. After it's all said and done you should have two sets of documents that a developer would have access to, the module developers document that would be a document outlining the three pieces discussed above and then the core developer document that would document all the core back-end functions (everything in utils/). Of course there would be a way to overwrite these methods so that developers can still create non-entity based modules (webmails, calendar, rss, etc), but it should make life much easier for module developers who follow the entity structure in vtiger. What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well. Matt From Matjaz.Slak at atol.si Fri Jul 14 02:42:52 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:42:52 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: Hi! If there's no one else, I volunteer to be the v4 Linus. I have the exact same position as a lot of other people wrote about here - basically my own fork of v4.2.3, and I'm now working to get my patches compatible with v4.2.4 so as to get back to the main trunk. And it's a lot of work, which I need to trade with my basic task - which is supporting several customers we have on vTiger. I hope I will have my set of patches (there might be up to 100 of them, as it's looking right now :) ready in a week or so. I belive we as vTiger Dev team should provide more support for 4.2.x stream -> I guess that almost ALL of vTiger's "real world" users use that right now. And they might go for v5 when it's stable, but that won't be (in my experience) for at least 6 months after it's released. If you want me, I'm here. Just give me a direction to start in, and I (and my three colleagues here) can be reviewing submitted work in no time. And discussing it with you the team here to get decissions on include/reject. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Sergio A. Kessler" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:40 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment.bin From Matjaz.Slak at atol.si Fri Jul 14 02:43:51 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:43:51 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> Message-ID: Hi! Allan, if you need any help, let me know (see my previous post). Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Allan Bush" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:59 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment.bin From dgrant at accuratetechnologies.com Fri Jul 14 09:24:34 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 09:24:34 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG From allan.bush+vtiger_dev at gmail.com Fri Jul 14 10:32:02 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 07:32:02 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Proper use of a OO design would solves this for both of you. All the common code and default module behavior should be moved into the a set of default classes or "engines" as Matthew is calling them. Then for each module we inherit the classes and make a couple method calls (ideally this is abstracted as well so to create a module all you do is create a class which inherits the base class) which generates the required database actions / html page. If you want something different then the default, like Dennis describes, you simply extent the required method in your inherited class. This way the common code is abstracted and only needs to exist once while the module specific code is in the module for easy modification. The code is already partly structured this way (it's just not used properly). There's already a base class CRMentity which every module inherits from. What needs to be done is to clean up the CRMentity - module relationship so that only methods common to all modules and their default behavior is defined in CRMentity and only things which need to be changed are defined in the module class. Then we need to create a class for each page type (again some of this already exists. ala inculdes/Listview.php, but here it isn't used at all) with the default behaviors of each page type. Now we have an option, either we have each module inherit these page type classes (making changes as needed ala CRMentity) and have a common set of calls to render each page type or we create a SMALL file in each module with a couple of calls to the page type class to render the page and we substitute new functions as needed for customizations. Personally I think the first option here is the better design, but unless you get it right it could become difficult to modify the parts of the page you want without re-witting a lot of the base class (should be avoided at all cost or we're right back in the mess we are in now). That was a bit of a long winded explanation, let me know if anyone requires clarification. On 7/14/06, Dennis Grant wrote: > > > My basic idea comes down to writing wrapper classes that are used to > > abstract most of the unnecessary functions from developers and instead > > provides a uniform API to access modules, permissions, input, etc. > > Oooh. > > > The idea comes in three pieces. Common UI classes, most of which is > > already done with the new UI. A "mainframe" engine similar to the > > joomla $mainframe. And last but certainly not least is an entity > engine > > that would abstract most of the entity details from developers and > truly > > provide the unified API. > > To be honest, I think this is moving in the wrong direction. > > If everybody used the same vanilla VTiger installation, this would make > a lot of sense - one common UI for the entire set of users, and a much > cleaner codebase for developers. Happy happy for everybody. > > Unfortunately, a lot of us are NOT using vanilla VTiger; we have to > customize the application to meet the needs of our user base. And a lot > of the time, our users really really want changes that may seem utterly > trivial from a developer standpoint, but for whatever reason, they > REALLY want it that way. > > And the customer is always right, so we have to do it. > > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. > > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. > > Yes, it makes changing common code more difficult, 'cause now I have to > drill down into each submodule and make the same change over and over > again, and I can certainly see where modularizing and sharing code makes > that job a lot easier. But the assumption it is based on, while true of > a vanilla install, is NOT true in a customized install environment. > > I'd prefer to see every module live in its own subdirectory of the > modules directory, much as is does in 4.x, but more rigorously (ie, > separate Sales Orders from Purchase Orders, don't group them in Orders) > and each module should have its own, atomic codebase. > > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. > > I'd like to see some standardization on the module file structure > though: > > modules/Foo/EditView.php for the edit UI for the module object > modules/Foo/DetailView.php for the detailed view of the object > modules/Foo/Save.php for saving the object to the DB > modules/Foo/CreatePDF.php for creating a PDF version of the object > modules/Foo/UIElements.php for the common UI functions (that are now > stuffed in include/utils.php > modules/Foo/BarPopup.php if there is a popup window to select associated > Bar objects > > etc. > > It makes dealing with modules easier if we know where the various > functions are kept. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From isimpkins at premierrealm.com Fri Jul 14 11:10:32 2006 From: isimpkins at premierrealm.com (Ivar Simpkins) Date: Fri, 14 Jul 2006 17:10:32 +0200 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: Sorry DG this doesn?t wear with me. 'The price of programmability' is what it's about. There is the short term solution and it has its merits, but planning a structured API can only have its long term benefits. Where does vTiger want to be in the future, this has to be answered. If it wants to be in the top ratings, then I think every effort has to be made, to reconsolidate and then plan for the future. Sure the learning curve is steep but the rewards are enormous. Would it not be better to prefect a generic function, in an OO structure which does all you want, one entrance, one exit and away you go. A well documented code base that automatically builds your API documentation gives you a valuable toolbox, now concentrate the communities efforts on pulling together and raising the lowest common denominator and you have a work the progresses moving a an incredible rate. And as Matt said: 'What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well.' NO, you are not nuts, it gives you the long term ability to use ones creativity to best avail without (always) having to worry about the nuts & bolts. I think this is a courageous step in the right direction, where, after surviving the learning curve, all will benefit, creating a homogeneous standardised kernel, with the ability of Plug 'n Play ala Joomla and probably much more. 'The price of programmability' is high but seeing the caliber of work produced so far, I am convinced Matt is on the right track to creating a new dimension in CRM. Please excuse the tone but its hard to see the same mistake been made over and again. Ivar > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 From mmbrich at fosslabs.com Fri Jul 14 12:54:21 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:21 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Message-ID: <1152896061.16985.648.camel@localhost.localdomain> On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > Proper use of a OO design would solves this for both of you. > > All the common code and default module behavior should be moved into > the a set of default classes or "engines" as Matthew is calling them. > Then for each module we inherit the classes and make a couple method > calls (ideally this is abstracted as well so to create a module all > you do is create a class which inherits the base class) which > generates the required database actions / html page. If you want > something different then the default, like Dennis describes, you > simply extent the required method in your inherited class. This way > the common code is abstracted and only needs to exist once while the > module specific code is in the module for easy modification. I think we're right on the same page here, but if you take for example the Campaign.php class, it should not be needed. All of the functions and variables it defines are generic and do not need to be re-created for each module that does simple data collection and display. If you want to write a module that does more than this, and will need it's own class, by all means, extend the EntityEngine class (or CRMEntity if it becomes the engine) and then continue on your way. > > The code is already partly structured this way (it's just not used > properly). There's already a base class CRMentity which every module > inherits from. What needs to be done is to clean up the CRMentity - > module relationship so that only methods common to all modules and > their default behavior is defined in CRMentity and only things which > need to be changed are defined in the module class. But even things that need to be changed, may not need to be changed and defined in separate module classes. For example all the get_leads, get_contacts, etc functions can be standardized and instead use a set of DB keys to track relationship_types allowed for a module. function get_leads($id,$entity) { if($this->is_relationship_type($entity->module,"Leads")) { stuff.. } else return false; } > Then we need to > create a class for each page type (again some of this already exists. > ala inculdes/Listview.php, but here it isn't used at all) with the > default behaviors of each page type. Now we have an option, either we > have each module inherit these page type classes (making changes as > needed ala CRMentity) and have a common set of calls to render each > page type or we create a SMALL file in each module with a couple of > calls to the page type class to render the page and we substitute new > functions as needed for customizations. Personally I think the first > option here is the better design, but unless you get it right it could > become difficult to modify the parts of the page you want without > re-witting a lot of the base class (should be avoided at all cost or > we're right back in the mess we are in now). Correct, and I think if you created the correct UI classes you could very easily overwrite the functions you want to customize and _only_ the functions you want to customize (like AddBlock() for example). > That was a bit of a long winded explanation, let me know if anyone > requires clarification. I think we're pretty close to being in the same school of though but maybe I needed to explain my thoughts in a bit more detail. I really just laid out a very high level overview of what I think should be done. Matt From mmbrich at fosslabs.com Fri Jul 14 12:54:58 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:58 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <1152896098.16985.650.camel@localhost.localdomain> > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. So in these cases you could over-ride the system DetailView by creating /Accounts/DetailView.html.php for your actual HTML stuff, and /Accounts/Detailview.php if you want to change the logic flow. If you are only changing the look/feel, then re-declare the AddBlock() function with your new special sauce inside of it and off you go. > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. See above, the correct separation of these layers in the system can still give you the flexibility you need. > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > To create new field types it would just be a matter of creating a new UIType, populating the DB fields you want to have that uitype (via XML), and then creating the base HTML for it in the UIType.tpl file. {if {$uitype} == "230"} your_new_html {/if} On top of this you could just over-ride the system UI creator and replace it with your own display classes. > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. I actually think the entity engine will need to have a query builder in it so that the queries can be built dynamically depending on the type of data you are going for. A true entity engine (like the one in ofbiz.org) will not ever let you see a query, nor should you need to if the entity engine is doing it's job correctly. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. i hate utils.php :). But the examples you lay out above would not at all be impossible. You would simply tell the entity engine (via an XML file) that you want a seqno and header value assigned to each entity of type=Quotes, and then in the query builder it will check for seqno and if it find it, ORDER BY seqno will be appended to the query string. Really what I am trying to accomplish is to make your life easier in the long run than what it currently is, even when diverging from the standard way of doing it with-in vtiger. There is a learning curve that will come along with this but correct documentation and developer support via this mailing list should help you get past any of that. Matt From allan.bush+vtiger_dev at gmail.com Fri Jul 14 13:13:28 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 10:13:28 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <1152896061.16985.648.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> Message-ID: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> I'm pretty sure we're on the same page Matt, my reply was more of an attempt to convince Dennis then an attempt to disagree with anything you said. In your example though I'm not sure how much I like having a function called "get_leads" in the base class. I think there's way too much coupling between "modules" right now and I'd like to get away from that, however I'm not sure what the best way to do that is without losing any of the control we currently have. That's probably another discussion though. I agree with your design, I could probably argue all day over the implementation of the details, but as long as it's constant and logical I don't care too much. On 7/14/06, Matthew Brichacek wrote: > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > Proper use of a OO design would solves this for both of you. > > > > All the common code and default module behavior should be moved into > > the a set of default classes or "engines" as Matthew is calling them. > > Then for each module we inherit the classes and make a couple method > > calls (ideally this is abstracted as well so to create a module all > > you do is create a class which inherits the base class) which > > generates the required database actions / html page. If you want > > something different then the default, like Dennis describes, you > > simply extent the required method in your inherited class. This way > > the common code is abstracted and only needs to exist once while the > > module specific code is in the module for easy modification. > I think we're right on the same page here, but if you take for example > the Campaign.php class, it should not be needed. All of the functions > and variables it defines are generic and do not need to be re-created > for each module that does simple data collection and display. > If you want to write a module that does more than this, and will need > it's own class, by all means, extend the EntityEngine class (or > CRMEntity if it becomes the engine) and then continue on your way. > > > > > The code is already partly structured this way (it's just not used > > properly). There's already a base class CRMentity which every module > > inherits from. What needs to be done is to clean up the CRMentity - > > module relationship so that only methods common to all modules and > > their default behavior is defined in CRMentity and only things which > > need to be changed are defined in the module class. > But even things that need to be changed, may not need to be changed and > defined in separate module classes. For example all the get_leads, > get_contacts, etc functions can be standardized and instead use a set of > DB keys to track relationship_types allowed for a module. > function get_leads($id,$entity) { > if($this->is_relationship_type($entity->module,"Leads")) { > stuff.. > } else > return false; > } > > > Then we need to > > create a class for each page type (again some of this already exists. > > ala inculdes/Listview.php, but here it isn't used at all) with the > > default behaviors of each page type. Now we have an option, either we > > have each module inherit these page type classes (making changes as > > needed ala CRMentity) and have a common set of calls to render each > > page type or we create a SMALL file in each module with a couple of > > calls to the page type class to render the page and we substitute new > > functions as needed for customizations. Personally I think the first > > option here is the better design, but unless you get it right it could > > become difficult to modify the parts of the page you want without > > re-witting a lot of the base class (should be avoided at all cost or > > we're right back in the mess we are in now). > Correct, and I think if you created the correct UI classes you could > very easily overwrite the functions you want to customize and _only_ the > functions you want to customize (like AddBlock() for example). > > > > That was a bit of a long winded explanation, let me know if anyone > > requires clarification. > I think we're pretty close to being in the same school of though but > maybe I needed to explain my thoughts in a bit more detail. I really > just laid out a very high level overview of what I think should be done. > > Matt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From mmbrich at fosslabs.com Fri Jul 14 13:18:54 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 11:18:54 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> Message-ID: <1152897535.16985.654.camel@localhost.localdomain> On Fri, 2006-07-14 at 10:13 -0700, Allan Bush wrote: > I'm pretty sure we're on the same page Matt, my reply was more of an > attempt to convince Dennis then an attempt to disagree with anything > you said. > > In your example though I'm not sure how much I like having a function > called "get_leads" in the base class. I think there's way too much > coupling between "modules" right now and I'd like to get away from > that, however I'm not sure what the best way to do that is without > losing any of the control we currently have. That's probably another > discussion though. I'm not a big fan of how this is done either but you're right, this falls into another discussion about how to clean up current practices going forward with a new structure. > > I agree with your design, I could probably argue all day over the > implementation of the details, but as long as it's constant and > logical I don't care too much. Plenty of details that are yet to be worked out ;). Matt > > > On 7/14/06, Matthew Brichacek wrote: > > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > > Proper use of a OO design would solves this for both of you. > > > > > > All the common code and default module behavior should be moved into > > > the a set of default classes or "engines" as Matthew is calling them. > > > Then for each module we inherit the classes and make a couple method > > > calls (ideally this is abstracted as well so to create a module all > > > you do is create a class which inherits the base class) which > > > generates the required database actions / html page. If you want > > > something different then the default, like Dennis describes, you > > > simply extent the required method in your inherited class. This way > > > the common code is abstracted and only needs to exist once while the > > > module specific code is in the module for easy modification. > > I think we're right on the same page here, but if you take for example > > the Campaign.php class, it should not be needed. All of the functions > > and variables it defines are generic and do not need to be re-created > > for each module that does simple data collection and display. > > If you want to write a module that does more than this, and will need > > it's own class, by all means, extend the EntityEngine class (or > > CRMEntity if it becomes the engine) and then continue on your way. > > > > > > > > The code is already partly structured this way (it's just not used > > > properly). There's already a base class CRMentity which every module > > > inherits from. What needs to be done is to clean up the CRMentity - > > > module relationship so that only methods common to all modules and > > > their default behavior is defined in CRMentity and only things which > > > need to be changed are defined in the module class. > > But even things that need to be changed, may not need to be changed and > > defined in separate module classes. For example all the get_leads, > > get_contacts, etc functions can be standardized and instead use a set of > > DB keys to track relationship_types allowed for a module. > > function get_leads($id,$entity) { > > if($this->is_relationship_type($entity->module,"Leads")) { > > stuff.. > > } else > > return false; > > } > > > > > Then we need to > > > create a class for each page type (again some of this already exists. > > > ala inculdes/Listview.php, but here it isn't used at all) with the > > > default behaviors of each page type. Now we have an option, either we > > > have each module inherit these page type classes (making changes as > > > needed ala CRMentity) and have a common set of calls to render each > > > page type or we create a SMALL file in each module with a couple of > > > calls to the page type class to render the page and we substitute new > > > functions as needed for customizations. Personally I think the first > > > option here is the better design, but unless you get it right it could > > > become difficult to modify the parts of the page you want without > > > re-witting a lot of the base class (should be avoided at all cost or > > > we're right back in the mess we are in now). > > Correct, and I think if you created the correct UI classes you could > > very easily overwrite the functions you want to customize and _only_ the > > functions you want to customize (like AddBlock() for example). > > > > > > > That was a bit of a long winded explanation, let me know if anyone > > > requires clarification. > > I think we're pretty close to being in the same school of though but > > maybe I needed to explain my thoughts in a bit more detail. I really > > just laid out a very high level overview of what I think should be done. > > > > Matt > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From nolan at peaceworks.ca Fri Jul 14 13:44:55 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Fri, 14 Jul 2006 13:44:55 -0400 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Message-ID: <1152899095.32568.49.camel@rockcrusher> As one of the mentioned 4.2 developers mostly lurking on this list... Like others have mentioned, I've got 2 classes of modifications: 1. those _I think_ others may be interested in 2. those _I think_ others will not be interested in What I want to know is...is what _I think_ in any way connected with reality? More to the point... How do I know whether or not I *should* submit a given patch to the current tree for 4.2.5? In my previous (though admittedly minimal) exploration, I got the sense that 4.2.x was essentially "feature frozen" and that bug/security fixes and deployment/installation/maintenance stuff were fair game. For myself (and others like me), is 4.2 open for new features? If so, should we just continue to take it on ourselves to self-select those things _we think_ are more universal in nature? Should we try the shotgun approach (submit everything to 'Code Contributions' and see what gets picked up)? Is there a "proper place" to provide a list of changes we've made and give others the opportunity to speak for/against including them (or give a 'vTiger Linus' the opportunity to accept/reject them)? I think once I have a clear idea of how best to contribute, particularly to 4.2, I'll be more able to do so effectively. By the way, I think Matt's v5 architecture ideas are great, but they do muddy the waters for me a bit. Seeing those ideas, I have hope that something along those lines may be implemented, but it also makes me question *when* the right time will be to port some of my changes and additions to v5...I'd rather just do it once. peace, nokes On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > Hi! > This is a call to all the 4.x private development owners. > > Many of you would have been working on your own version of vtiger as you would have > customized it to your own needs. This is a call for those guys. > > The intent is to aggregate most of the common features that you have built and have them > integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch > or even in the 5.x branch as needed by the community. > > Pros: > > By doing the above, you will be able to be in sync with the latest and greatest developments > happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a > read as one would think of but we are working on it. Yesterday we had comments about the > code not being properly commented, we are working on that right now even as I type this post. > So, the idea I am conveying is that we are not perfect but are listening to the comments and > taking actions too. Hence, please do keep the faith. > > Cons: > > By maintaining your own code bases, you lose out on the community benefits like > identifying bugs, feature integration, new ideas, etc. > > We welcome your contributions. > > Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise > the folly. Let us get on with it and make vtiger a success. > I have learnt from my past mistakes. Join the team, come on board. > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Fri Jul 14 15:37:08 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 15:37:08 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> > Really what I am trying to accomplish is to make your life easier in the > long run than what it currently is, even when diverging from the > standard way of doing it with-in vtiger. There is a learning curve that > will come along with this but correct documentation and developer > support via this mailing list should help you get past any of that. Except that you're killing me with your good intentions. The life of an integrator doesn't permit steep learning curves and heavy abstractions; there just isn't time to do so. I've got a dozen different systems to get to play together, a boss screaming at me to get this stuff done yesterday, and no time to devote to learning whatever abstraction layer you've decided to implement. And Murphy's Law being what it is, if your abstraction model has one flaw, that will be the thing that my boss wants as his top priority. "Perfect is the enemy of good enough" I don't want "perfect"; I want "good enough" I want to be able to dive into the source and start modifying how the thing works *right now* without having to trace back a billion functions or wrap my brain around your object model. I don't have time to do so, because I'm simultaneously trying to play with a dozen other pieces of the puzzle. Guys, I have been playing this game for a LONG time. I have written major applications to perform mission-critical business functions.(At one time, if my code broke DaimlerChrysler stopped building cars) I have seen and dealt with thousands of software projects, both as a participant and as an observer, and almost without fail, every time somebody sets out to do the "perfect" object-based, extensible, customizable framework, it just leads to tears. I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. If you write code that any decent developer can pick up, find his bearings in a couple of seconds, and then comprehend *without* the benefit of having read the thousand-page project definition in advance, then you are doing well. The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator - because if your code is so illegible (or so heavily abstracted, or has such a steep learning curve, or whatever) that I cannot figure it out on my own in a few minutes and so have to drop everything until I can get some assistance... well then, you've burned up my precious, precious time. That code might be sheer genius. It might be, once you have tackled the learning curve, breathtakingly beautiful. But if I can't just fire up vi and dive in, then it is WRONG. Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. The big problem with the current state of Vtiger 4.x is that it straddles both worlds. There are parts of the code that are fairly straightforward and out in plain sight, and only lack comments to make them "good enough". Then there are parts that want to be object-oriented with an API, but really depend on a couple of heavily-overloaded megafunctions buried deep in the depths of util.php (also uncommented) so you have to play API detective to figure out just what the hell is happening where. And then there's parts of the code that mix both. It'd be SO much easier to maintain if all the code that related to a module (less some *basic* toolkit functions that could reside in a common include) just lived in that module. Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility. DG From dan.means at teamsrs.com Fri Jul 14 16:25:56 2006 From: dan.means at teamsrs.com (Dan Means) Date: Fri, 14 Jul 2006 13:25:56 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <44B7FDD4.4080009@teamsrs.com> I couldn't have said this better than Dennis.... -- Dan Means Mission Viejo, CA www.dkmeansonline.com www.teamsrs.com From crm at email.si Fri Jul 14 17:34:37 2006 From: crm at email.si (Ales Petric) Date: Fri, 14 Jul 2006 22:34:37 +0100 Subject: [Vtigercrm-developers] What's with 4.2.x future ? Message-ID: <44B80DED.4010808@email.si> HI EVERYONE This is my first post to 'vTiger' developers mailing list About me: My native environment is development environment (around C/C++, VB, HTML, CSS, PHP, ASP, Python). My home system environment is 'Linux' based desktop os. like 'Debian' and 'Debian' based (my latest is 'Ubuntu') For my business server system I use 'Debian' stable. Like all I had to do some system tunning and other stuff related for system to work properly and live. I worked for small and big companies, within groups and on solo projects. My favorite project is project that is more to an end oriented that other. I had worked on lost project to but I had learned something from that, hope you to. Project called 'vTIger': Yes, 'vTiger' :), I am working with this great free source project for some time now (let me think back, 1 year and 6 month it is, sounds like my birthday :) Reason is that I am involved with business that uses 'CRM' software and solution for them 'vTiger' was the answer, from me to them :) Yes, it sells good if support is guaranteed and signed in contract (like must be included); Yes what's new :) What is new? That was my question looking 'vTiger' community. Let's get serious. In my business we had implemented over 150 issues, or tickets related, not features. We have less then 10 serious stuff implemented, tested and deployed. I believe, and some of you will confirm that this is big step back for community when stuff is included in 'vTiger' and not updated on live track inside community. As we now, there are many companys that offers hosting with 'vTiger' CRM, and many are just keeping one eye on 4.2.x. I belive that 'vTiger' is under 'GPL' and much more, there is community above that is responsible for maintaining the project. Community: Let's face it. There should be readable state and mission, end oriented leadership, free participation, known business model of 'vTiger CRM', useful documents on-line, tutorials, subgroups with a roles like module manager, testers, and many more beautiful stuff, ..I yes there is many but not enough. I have read that someone was begging not for himself for some other guy that they should give him some type of account that he can post code 'not(anonymous)' Question is. Can community afford that kind of behaviour, that no actions are taken. Many are complaining about non activity that is going on right now. Proposal: Let's build team of project/module managers and sys-admin guys to do some steeps needed to put out htp://new.vtiger.com/ based on latest release of 4.2.x thread. On the same portal if it is possible ? Within the same community if it is possible ? We can invite all existing groups that are using 4.2.x thread and join forces and merge existing sources and fixed issues. We need that, and more we need all help we can get within testing activities that are needed when new release comes out. With future plans of what's included in first build and what in next. Yes we can plan what features and build them in future within subgroups of module managers responsible to finish what was started. 4.2.x future to be when 4.3 and then 5.0, isn't that the way ? If there is comment, I now there is, and I now there is the way we can bring action into 'vTiger' community. What do ya say? Respect, Ales Petric From carylt at gmail.com Fri Jul 14 17:47:03 2006 From: carylt at gmail.com (Caryl Takvorian) Date: Fri, 14 Jul 2006 22:47:03 +0100 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <8075d1e0607141447y1b5a878at5321bb42dafcd01b@mail.gmail.com> Just for the sake of it, let me say that I whole heartedly agree with Dennis. I'm not unfortunately convinced that his (our) opinion will change anything, but I find the arguments truthfully compelling. Caryl On 7/14/06, Dennis Grant wrote: > > > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/02f2875a/attachment-0002.html From mmbrich at fosslabs.com Fri Jul 14 18:29:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 16:29:30 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <1152916171.16985.800.camel@localhost.localdomain> OK, so I am going to highlight and comment on some of my favorite quotes from DG so far, this way when I start ignoring his emails you will all understand why. 1) It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules. This has to be hands-down the stupidest thing I have ever heard in my life and I can't believe that anyone who claims the experience you do actually posts this drivel on a public mailing list. 2) I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. I am utterly convinced that anyone who argues that 95% code similarities in vtiger modules is a "good enough" method is utterly stupid. 3) The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator ... well then, you've burned up my precious, precious time So your 'job' as an OSS systems integrator has never included needing to RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing question on a mailing list? 4) That code might be sheer genius. But if I can't just fire up vi and dive in, then it is WRONG. I'm starting to see the picture now.. you're lazy, and rather than do something about the current problems in the system you are going to whine about it. Sergio was right, my apologies Sergio. 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. I think I've made it clear that simple, concise and logical are all design goals of the system. And you sir have made it clear that you have no intention of helping move this project forward by displaying your willingness to fork instead of work with a _real_ design structure that a _real_ OSS systems integrator would be very happy to have. Matt On Fri, 2006-07-14 at 15:37 -0400, Dennis Grant wrote: > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From brian at awnow.com Fri Jul 14 21:48:13 2006 From: brian at awnow.com (Brian Laughlin) Date: Fri, 14 Jul 2006 18:48:13 -0700 Subject: [Vtigercrm-developers] Poorly written code is poorly written code. Message-ID: <27CABE0A5EFD714EA5B2F9B47EE5CB855BCFA2@svawmc1.awnow.local> 'Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility.' This is not really a fair statement. OO code done well is a gem. The statement above automatically implies that it will be written poorly. OO code, procedure code or a sql query written badly is poorly written code - period. No method can overcome poor coding. It seems reasonable that v5 is about the future, one that creates better code base that is more reusable and it encourages more development talent to improve, iterate and integrate. With some effort I think we can mature this process so that the core product can continue to benefit from the community's contributions. There seems to be a simple fix to the debate that is ensuing. If you want to keep it as it is then support the 4.2.x branch, otherwise help to mature the code for v5. One last comment. There is a large class of developers that don't really care how the code was written or how it works as long as it works and works well. If you can extend its functionality or easily call it when you need it then for the most part they are happy. That doesn't stop those that want to dig deeper and tweak it at that level. More power to you. Regards, Brian Laughlin From mmbrich at fosslabs.com Sun Jul 16 23:31:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 21:31:30 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight Message-ID: <1153107090.5582.9.camel@localhost.localdomain> I wasn't able to get all the upgrades done last night, expect some more spotty access tonight as I try to finish up the list of to-dos Matt From mmbrich at fosslabs.com Mon Jul 17 00:31:29 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 22:31:29 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight In-Reply-To: <1153107090.5582.9.camel@localhost.localdomain> References: <1153107090.5582.9.camel@localhost.localdomain> Message-ID: <1153110689.5582.17.camel@localhost.localdomain> Upgraded SVN to 1.2.3 from backports.org. Let me know if you have problems with it. There is a backup of both the forge repo and the main repo from just before the upgrade. Matt On Sun, 2006-07-16 at 21:31 -0600, Matthew Brichacek wrote: > I wasn't able to get all the upgrades done last night, expect some more > spotty access tonight as I try to finish up the list of to-dos > > Matt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Mon Jul 17 05:18:50 2006 From: crm at email.si (Ales Petric) Date: Mon, 17 Jul 2006 10:18:50 +0100 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <1152899095.32568.49.camel@rockcrusher> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> <1152899095.32568.49.camel@rockcrusher> Message-ID: <44BB55FA.4050909@email.si> Ok As private developer owner of 4.2.x I would like to be involved 'actively' in planning, maintaining and updating the 4.2.x. With what can I contribute: 1- I can bug fix (ticket solve) 2- I can suggest & plan with others what's to be in next release (4.2.X) and help with coding to achieve that 3- I can define groups for managing individual modules (maintainers) that will togather with other involved in 4.2.x deceide what's needed to build as add-on 4- I can do the functional analyse of current 4.2.x and publish .pdf, like system & user help (for developers and others related) 5- I can built three of functionality, like dir structure (for UseCase, TestCase and other related) 6- I can define which ticket/issue goes with X module or X functionality (for quick issue solving and other related) 7- I can help sync with other anonymous/private developers what was solved/debugged and help to merge existing code into next to be released 8 .. and many other stuff that I had have already done and not published...I can decode that for other users... What do I need: 1- Account with permissions to do something, I don't want to be anonymous updater. Now it's 8 vs 1 :( I it would be great to be involved with when to release and what's included in next 4.2.x. Ales Nolan Andres wrote: > As one of the mentioned 4.2 developers mostly lurking on this list... > > Like others have mentioned, I've got 2 classes of modifications: > > 1. those _I think_ others may be interested in > 2. those _I think_ others will not be interested in > > What I want to know is...is what _I think_ in any way connected with > reality? > > More to the point... > > How do I know whether or not I *should* submit a given patch to the > current tree for 4.2.5? In my previous (though admittedly minimal) > exploration, I got the sense that 4.2.x was essentially "feature frozen" > and that bug/security fixes and deployment/installation/maintenance > stuff were fair game. > > For myself (and others like me), is 4.2 open for new features? If so, > should we just continue to take it on ourselves to self-select those > things _we think_ are more universal in nature? Should we try the > shotgun approach (submit everything to 'Code Contributions' and see what > gets picked up)? Is there a "proper place" to provide a list of changes > we've made and give others the opportunity to speak for/against > including them (or give a 'vTiger Linus' the opportunity to > accept/reject them)? > > I think once I have a clear idea of how best to contribute, particularly > to 4.2, I'll be more able to do so effectively. > > By the way, I think Matt's v5 architecture ideas are great, but they do > muddy the waters for me a bit. Seeing those ideas, I have hope that > something along those lines may be implemented, but it also makes me > question *when* the right time will be to port some of my changes and > additions to v5...I'd rather just do it once. > > peace, > nokes > > > > On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > >> Hi! >> This is a call to all the 4.x private development owners. >> >> Many of you would have been working on your own version of vtiger as you would have >> customized it to your own needs. This is a call for those guys. >> >> The intent is to aggregate most of the common features that you have built and have them >> integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch >> or even in the 5.x branch as needed by the community. >> >> Pros: >> >> By doing the above, you will be able to be in sync with the latest and greatest developments >> happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a >> read as one would think of but we are working on it. Yesterday we had comments about the >> code not being properly commented, we are working on that right now even as I type this post. >> So, the idea I am conveying is that we are not perfect but are listening to the comments and >> taking actions too. Hence, please do keep the faith. >> >> Cons: >> >> By maintaining your own code bases, you lose out on the community benefits like >> identifying bugs, feature integration, new ideas, etc. >> >> We welcome your contributions. >> >> Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise >> the folly. Let us get on with it and make vtiger a success. >> I have learnt from my past mistakes. Join the team, come on board. >> >> Richie >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > __________ NOD32 1.1661 (20060714) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f0af863c/attachment.html From sergiokessler at gmail.com Mon Jul 17 09:36:39 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 10:36:39 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak From dgrant at accuratetechnologies.com Mon Jul 17 09:51:45 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Mon, 17 Jul 2006 09:51:45 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG From richie at vtiger.com Mon Jul 17 10:48:07 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:48:07 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> Message-ID: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Hi Team! Let us take a step back and review what is happening. As the case stands, the intent is to provide an ideal vtiger architecture which needs almost everyones needs. It is plain that as of now, there are only 2 "strong/loud" arguments. I am sure you all will agree that both of them are not overly subscribed by any majority yet. Let us get some more ideas- however radical they be- into this list and then we will vote the good ideas in. By being too strongly worded on any particular idea, it will only stop short the other guys to put forth their ideas however miniscule/insignificant that might appear to be. I have myself faced this situations many times and I wish that the same does not happen here. Let us target 2 weeks from today as the time within which we should get all the ideas in. We can always short list as we have quite some experienced hands on board. vtigercrm-5.0.0 will be out within that time. Good to see some emotion here but I am sure we will hold to the rules of basic etiquettes and only wrt the point in concern. Thank You, Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9af843db/attachment-0002.html From richie at vtiger.com Mon Jul 17 10:57:28 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:57:28 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> Message-ID: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/d71cb2dd/attachment.html From richie at vtiger.com Mon Jul 17 11:43:10 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 08:43:10 -0700 Subject: [Vtigercrm-developers] automated tests update Message-ID: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f783fc2f/attachment-0002.html From richie at vtiger.com Mon Jul 17 12:01:27 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:01:27 -0700 Subject: [Vtigercrm-developers] have a go at the demo Message-ID: <10c7d3878ee.-2525705299028808692.-7798707862789036512@@vtiger.com> Dear Team, Kindly have a go at the demo so that we can identify the bugs and fix them. We are planning to freeze taking up any new bug-fixing post this week. Needless to say, if there be any pressing bugs, we will have to re-consider else we stick to this plan. We would like to take into consideration all the bugs that we get by this week alone. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/05c6f7c8/attachment.html From richie at vtiger.com Mon Jul 17 12:04:40 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:04:40 -0700 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 Message-ID: <10c7d3b68c9.-1733958150241885349.-2381377074013605034@@vtiger.com> Ken asked me a question in my blogs about how we can have a better documentation for v5. I honestly do not know if any setup is available which can help us achieve the same other than that of a wiki. Any new ideas are welcome. It will be nice to have a distributed effort on for the documentation as well. Let us get some working backbone for collaborative documentation up and running fast. Any ideas/suggestions? Any experienced documentor on board, please raise hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/effef8f7/attachment-0002.html From richie at vtiger.com Mon Jul 17 12:24:59 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:24:59 -0700 Subject: [Vtigercrm-developers] Help Needed Feature Message-ID: <10c7d4e0030.-6478902657238423422.8728970723888816495@@vtiger.com> Is there any Help Needed feature available in the forge? Ken asked me this and I could not answer the query. Please find the link to the blog post for contextual reference: http://blogs.vtiger.com/weblog_entry.php?p=28125#28125 I think what Ken is referring is to have a more vertically-distributed setup something like Help Needed in Leads Module Bug-fixing Help Needed in Leads Module Docs Help Needed in Leads Module Automation of test cases etc. Matt/Fathi, can we have this for all the projects in the forge please or does it already exist? I just checked the forge and did not find any links. Am I missing something? Probably, we can have a link to the vtigercrm-5.0.0 live source in the vtigerforge too. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/1c9b7dca/attachment.html From richie at vtiger.com Mon Jul 17 12:31:34 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:31:34 -0700 Subject: [Vtigercrm-developers] automated trac registration Message-ID: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9e1e63d7/attachment-0002.html From richie at vtiger.com Mon Jul 17 12:34:57 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:34:57 -0700 Subject: [Vtigercrm-developers] Fwd: error Message-ID: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> ----j.ruisz at ruisz.com wrote ---- ============Forwarded Mail============ >From : j.ruisz at ruisz.com To : richie at vtiger.com Date :Fri, 14 Jul 2006 08:11:36 +0200 Subject : error ============Forwarded Mail============ Hello , trying to test the online demo of vtiger 5 i got this result: *Fatal error*: Call to a member function on a non-object in */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* on line *431* with best regards, mit freundlichen Gr??en, Joachim Ruisz Werbegrafik, Bildagentur, Webagentur Softwareentwicklung Joachim Ruisz A 8940 Liezen +43 664 312 4830 j.ruisz at ruisz.com http://www.ruisz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/332ceeeb/attachment.html From richie at vtiger.com Mon Jul 17 12:35:17 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:35:17 -0700 Subject: [Vtigercrm-developers] Fwd: Translations Message-ID: <10c7d576ed5.6497289794643483356.-5939067564803299625@@vtiger.com> ----webmaster at vtigerfacile.com wrote ---- ============Forwarded Mail============ >From : webmaster at vtigerfacile.com To : richie at vtiger.com Date :Mon, 17 Jul 2006 02:31:42 +0200 Subject : Translations ============Forwarded Mail============ Vanakkam Shankar, i have made a little test for translation. I have added few line in app_strings file. And like for module customview, all dropdown in all editviews (Call/Meeting inclued) are translated. If we can have the same things in listview & detailview, the translation will be perfect, and vtiger 5 can be used in multilang without problem. I want to mention the value of select box is keep in english () Best regards, A?ssa Find the added strings in /include/languages/fr_fr.lang.php below //activities 'Planned'=>'Plannifi?', 'Held'=>'A eu lieu', 'Not Held'=>'N\'a pas eu lieu', 'Medium'=>'Normale', 'Private'=>'Priv?', 'Public'=>'Public', 'Daily'=>'Quotidienne', 'Weekly'=>'Hebdomadaire', 'Monthly'=>'Mensuelle', 'Yearly'=>'Annuelle', 'Completed'=>'Termin?', 'Deferred'=>'Report?', //Campaigns 'Excellent'=>'Excellent', 'Good'=>'Bonne', 'Average'=>'Moyenne', 'Poor'=>'Faible', 'Conference'=>'Conf?rence', 'Webinar'=>'S?minaire', 'Trade Show'=>'Salon', 'Public Relations'=>'Relations Publique', 'Partners'=>'Partenaires', 'Referral Program'=>'Programme', 'Advertisement'=>'Publicit?', 'Banner Ads'=>'Banni?re web', 'Direct Mail'=>'Email direct', 'Email'=>'Email', 'Telemarketing'=>'T?l?marketing', 'Others'=>'Autre', 'Planning'=>'Plannifi?', 'Complete'=>'Termin?', 'Cancelled'=>'Annul?', //Accounts //Industry list 'Apparel'=>'Appareillage', 'Banking'=>'Banque', 'Biotechnology'=>'Biotechnologie', 'Chemicals'=>'Industrie chimique', 'Communications'=>'Communications', 'Construction'=>'BTP', 'Consulting'=>'Conseil', 'Education'=>'Education', 'Electronics'=>'Electronique', 'Energy'=>'Energie', 'Engineering'=>'Engineering', 'Entertainment'=>'Divertissement', 'Environmental'=>'Environnement', 'Finance'=>'Finance', 'Food & Beverage'=>'Agro alimentaire', 'Government'=>'Secteur public', 'Healthcare'=>'Sant?', 'Hospitality'=>'Hopitaux', 'Insurance'=>'Assurances', 'Machinery'=>'', 'Manufacturing'=>'Manufacture', 'Media'=>'M?dia', 'Not For Profit'=>'But non lucratif', 'Recreation'=>'Amusement', 'Retail'=>'D?taillant', 'Shipping'=>'Livreur', 'Technology'=>'Technologie', 'Telecommunications'=>'T?l?communications', 'Transportation'=>'Voyage', 'Utilities'=>'D\'utilit? publique', 'Other'=>'Autre', //accounts type 'Analyst'=>'Analyste', 'Competitor'=>'Concurrent', 'Customer'=>'Client', 'Integrator'=>'Int?grateur', 'Investor'=>'Investisseur', 'Partner'=>'Partenaire', 'Press'=>'Presse', 'Prospect'=>'Prospect', 'Reseller'=>'Revendeur', 'Other'=>'Autre', 'Existing Business'=>'Client existant', 'New Business'=>'Nouveau client', 'Cold Call'=>'Appel direct', 'Existing Customer'=>'Client existant', 'Self Generated'=>'Auto g?n?r?', 'Employee'=>'Employ?', 'Partner'=>'Partenaire', 'Public Relations'=>'Relation publique', 'Direct Mail'=>'Email direct', 'Conference'=>'Conf?rence', 'Trade Show'=>'Salon', 'Web Site'=>'Site web', 'Word of mouth'=>'Bouche ? oreille', 'Other'=>'Autre', 'Prospecting'=>'Prospection', 'Qualification'=>'Qualification', 'Needs Analysis'=>'Requiert analyse', 'Value Proposition'=>'Proposition', 'Id. Decision Makers'=>'Attente d?cision', 'Perception Analysis'=>'Anallyse', 'Proposal/Price Quote'=>'Devis', 'Negotiation/Review'=>'N?gociation', 'Closed Won'=>'Clos gagn?', 'Closed Lost'=>'Clos perdu', 'Attempted to Contact'=>'Attente contact', 'Cold'=>'Froid', 'Contact in Future'=>'A recontacter', 'Contacted'=>'Contact?', 'Hot'=>'Chaud', 'Junk Lead'=>'Corbeille', 'Lost Lead'=>'Perdu', 'Not Contacted'=>'Non contact?', 'Pre Qualified'=>'Pr? qualifi?', 'Qualified'=>'Qualifi?', 'Warm'=>'Brulant', 'Acquired'=>'Acquis', 'Active'=>'Actif', 'Market Failed'=>'March? perdu', 'Project Cancelled'=>'Projet annul?', 'Shutdown'=>'Eteint', 'Open'=>'Ouvert', 'In Progress'=>'En cours', 'Wait For Response'=>'Attente de r?ponse', 'Closed'=>'Clos', 'General'=>'G?n?ral', 'Low'=>'Basse', 'Normal'=>'Normale', 'High'=>'Haute', 'Urgent'=>'Urgent', 'Minor'=>'Mineure', 'Major'=>'Majeur', 'Feature'=>'Fonctionnalit?', 'Critical'=>'Critique', 'Big Problem'=>'Gros probl?me', 'Small Problem'=>'Petit probl?me', 'Other Problem'=>'Autre probl?me', 'Hardware'=>'Mat?riel', 'Software'=>'Logiciel', 'CRM Applications'=>'Application CRM', 'Box'=>'Boite', 'Carton'=>'Carton', 'Dozen'=>'Douzaine', 'Each'=>'Pi?ce', 'Hours'=>'Heure', 'Impressions'=>'Impression', 'Lb'=>'Lb', 'M'=>'M', 'Pack'=>'Pack', 'Pages'=>'Pages', 'Pieces'=>'Pi?ces', 'Quantity'=>'Quantit?', 'Reams'=>'Rames', 'Sheet'=>'Pages', 'Spiral Binder'=>'Reliure', 'Sq Ft'=>'Sq Ft', 'Created'=>'Cr??', 'Delivered'=>'Livr?', 'Reviewed'=>'Corrig?', 'Accepted'=>'Accept?', 'Rejected'=>'Rejett?', 'Approved'=>'Approuv?', 'Sent'=>'Envoy?', 'Credit Invoice'=>'Avoir', 'Paid'=>'Sold?', 'Received Shipment'=>'Commande re?ue', 'Call'=>'Appel', 'Meeting'=>'Rendez-vous', 'Task'=>'T?che', '--None--'=>'Aucun', -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9ad522c6/attachment-0002.html From gopals at vtiger.com Mon Jul 17 13:58:01 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 10:58:01 -0700 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Message-ID: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Hi, If there is automate option, it is better to notify user id and password to the correct email ids. I am already struggling with free forums and wiki registration process. People register with junk mail ids and spam our bug tracker as well. My be we can create a group mail id and alias to admin users, who can create trac users ids so that load is shared among developer community. Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/c36beaeb/attachment.html From mmbrich at fosslabs.com Mon Jul 17 14:18:22 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:18:22 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Message-ID: <1153160302.5582.73.camel@localhost.localdomain> > It is plain that as of now, there are only 2 "strong/loud" arguments. > I am sure you all will agree that both of them are not overly > subscribed by any majority yet. Yes but there is only one idea on the table, and 1 set of criticisms followed by absolutely no suggestions on how to better the first idea. This was really my bitch about the first set of posts. > > Let us get some more ideas- however radical they be- into this list > and then we will vote the good ideas in. This is a great idea. I have been looking forward to someone else posting some ideas to get the ball rolling. I for one welcome radical ideas if anyone has any. > By being too strongly worded on any particular idea, it will only stop > short the other guys to put forth their ideas however > miniscule/insignificant that might appear to be. I certainly don't mean to scare off any developers that are going to actually bring some ideas to the table, quite the contrary. If someone has been playing around in 5.x and said to themselves "wouldn't it be easier if this was done like this..." then please tell us what you are thinking, even if it doesn't involve a full change to the architecture and only covers some small area of the code. > > I have myself faced this situations many times and I wish that the > same does not happen here. > > Let us target 2 weeks from today as the time within which we should > get all the ideas in. Lets not rush this, or pile on top of the workload that many vtiger devels are probably already experiencing. The only reason I brought my idea to the table this soon is because you and I had discussed this off list and I thought it needed to be in front of the community. > We can always short list as we have quite some experienced hands on > board. > vtigercrm-5.0.0 will be out within that time. But after 5.0.0 is out is when I think we'll start to see the most interesting ideas. Many devels may still be in 4.x and haven't had a chance yet to start playing with 5.x. Lets let them get their hands dirty in the new code first. > > Good to see some emotion here but I am sure we will hold to the rules > of basic etiquettes and only wrt the point in concern. I know I am a blunt person and sometimes that catches people off guard :), I rarely mean to come off as rude unless someone fully deserves it. Anyways, bring on the ideas for improving vtiger! Matt From mmbrich at fosslabs.com Mon Jul 17 14:22:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:22:49 -0600 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Message-ID: <1153160569.5582.79.camel@localhost.localdomain> I can't think of a great way to do automated sign-up without using captcha or something similar, and we all know there are ways around those systems. I like your ideas of an admin list that people can request access from. And BTW, which interface are you guys using to give developers trac accounts? There is the trac module which was installed or there is the service page that I created to manage SVN and trac. The reason I ask is because the service page may be out of date now that we've upgraded trac a couple times since I wrote it. Matt On Mon, 2006-07-17 at 10:58 -0700, Gopal wrote: > Hi, > > If there is automate option, it is better to notify user id and > password to the correct email ids. I am already struggling with free > forums and wiki registration process. People register with junk mail > ids and spam our bug tracker as well. > > My be we can create a group mail id and alias to admin users, who can > create trac users ids so that load is shared among developer > community. > > Gopal > --- > S.S.G.Gopal > skype: sripadag > ph: +1 877 788 4437 > blog: http://gopal.vtiger.com > > > > > ----richie at vtiger.com wrote ---- > > > Hi! > Team, is there any way we can have an automated trac registration? I can do the registrations > till a point and the current mechanism is too crude. > > Jeff/Matt any ideas please? > > Richie _______________________________________________ > Get started with creating presentations online - > http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Mon Jul 17 14:24:20 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:24:20 -0600 Subject: [Vtigercrm-developers] Fwd: error In-Reply-To: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> References: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> Message-ID: <1153160660.5582.81.camel@localhost.localdomain> I'll upgrade the demo sometime this afternoon, I still haven't had a chance to sit down and write an automation system for this since. I plan to create something along the lines of Jeff's suggestion and automate it with post-commit hooks. Anyone who wants to help, just say the word. Matt On Mon, 2006-07-17 at 09:34 -0700, Richie wrote: > > > > > ----j.ruisz at ruisz.com wrote ---- > > ============Forwarded Mail============ > From : j.ruisz at ruisz.com > To : richie at vtiger.com > Date :Fri, 14 Jul 2006 08:11:36 +0200 > Subject : error > ============Forwarded Mail============ > > Hello , > > trying to test the online demo of vtiger 5 i got this result: > > *Fatal error*: Call to a member function on a non-object in > */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* > on line *431* > > > > with best regards, > mit freundlichen Gr??en, > > Joachim Ruisz > > Werbegrafik, Bildagentur, Webagentur > Softwareentwicklung > > Joachim Ruisz > A 8940 Liezen > +43 664 312 4830 > j.ruisz at ruisz.com > http://www.ruisz.com > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From gopals at vtiger.com Mon Jul 17 14:37:05 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 11:37:05 -0700 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> References: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Message-ID: <10c7dc6f0c9.-5230172439552086929.-6694355083648319934@@vtiger.com> Hi Richie, I am aware of that currently we are using AdventNet QEngine for automating some of the test cases. But I am not clear, how can our external developer community use this tool in their local environment. Do you have any plans to get some more licenses for the sake of vtiger developer community? Thanks, Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/8b304edc/attachment-0002.html From jtk at yahoo.com Mon Jul 17 15:01:00 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 15:01:00 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: Gopal wrote: > I am aware of that currently we are using AdventNet QEngine for > automating some of the test cases. But I am not clear, how can our > external developer community use this tool in their local environment. > Do you have any plans to get some more licenses for the sake of vtiger > developer community? I'm glad to see regression tests on the agenda, but we don't need non-free tools to get this done. Selenium, which I've mentioned before, runs recorded tests in a browser, giving the most/only realistic test environment for javascript, etc. Selenium tests can be recorded by a firefox plugin, and the test source can be checked into subversion like any other source. This is what we should use, IMHO. http://openqa.org/selenium/ As far as running 'continuous integration testing'; some testing experts have used buildbot and vmware/vnc integration to continuously and automatically run unit and integration tests in a headless environment. http://www.google.com/search?q=buildbot+selenium http://agile.idyll.org/wiki/BuildBotTechnologyNarrative http://agile.idyll.org/buildbot/ All this testing technology uses free software. From mmbrich at fosslabs.com Mon Jul 17 17:25:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 15:25:52 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: <1153171552.5582.166.camel@localhost.localdomain> I haven't looked into Selenium yet but with JS does it work at the source level only, does it use gecko to actually execute and evaluate the JS or can it check for changes in the DOM like it does the source? In 5.x there are quite a few places where the DOM is being manipulated directly or indirectly and I don't think a source level verification tool will catch most of those. Maybe augmenting it with the scriptactulous unit test lib would work? http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Matt On Mon, 2006-07-17 at 15:01 -0400, Jeff Kowalczyk wrote: > Gopal wrote: > > I am aware of that currently we are using AdventNet QEngine for > > automating some of the test cases. But I am not clear, how can our > > external developer community use this tool in their local environment. > > Do you have any plans to get some more licenses for the sake of vtiger > > developer community? > > I'm glad to see regression tests on the agenda, but we don't need non-free > tools to get this done. > > Selenium, which I've mentioned before, runs recorded tests in a browser, > giving the most/only realistic test environment for javascript, etc. > > Selenium tests can be recorded by a firefox plugin, and the test source > can be checked into subversion like any other source. This is what we > should use, IMHO. > > http://openqa.org/selenium/ > > As far as running 'continuous integration testing'; some testing experts > have used buildbot and vmware/vnc integration to continuously and > automatically run unit and integration tests in a headless environment. > > http://www.google.com/search?q=buildbot+selenium > > http://agile.idyll.org/wiki/BuildBotTechnologyNarrative > > http://agile.idyll.org/buildbot/ > > All this testing technology uses free software. > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Mon Jul 17 18:53:33 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 18:53:33 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: Matthew Brichacek wrote: > I haven't looked into Selenium yet but with JS does it work at the > source level only, does it use gecko to actually execute and evaluate > the JS or can it check for changes in the DOM like it does the source? > In 5.x there are quite a few places where the DOM is being manipulated > directly or indirectly and I don't think a source level verification > tool will catch most of those. Selenium directly drives the browser as if the user were clicking it. The demo http://www.openqa.org/selenium-core/demos.html illustrates the concept. > Maybe augmenting it with the scriptactulous unit test lib would work? > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Unit tests in the client and server-side source would be enhancements, to be sure. However, I am skeptical about trying to retrofit unit test coverage to a large code base. The community would have a hard time achieving useful code coverage unless there were tests for *everything*, starting from early in the project. Selenium's end-result testing, and the fact that such tests can be recorded for submission by even novice users, would be an efficient use of limited community resources. If the testing fever strikes the community, perhaps all new code could be required to have unit tests, and so on. From sergiokessler at gmail.com Mon Jul 17 19:14:20 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 20:14:20 -0300 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 In-Reply-To: <8091387652950704133@unknownmsgid> References: <8091387652950704133@unknownmsgid> Message-ID: <49216030607171614g2a47b5di900e13b06c4810f6@mail.gmail.com> richie, a wiki is the best aproach for this, don't worry... (of course, then you need people that do collaborate) /sak On 7/17/06, Richie wrote: > > Ken asked me a question in my blogs about how we can have > a better documentation for v5. > I honestly do not know if any setup is available which > can help us achieve the same other than > that of a wiki. > Any new ideas are welcome. > > It will be nice to have a distributed effort on for > the documentation as well. > Let us get some working backbone for > collaborative documentation up and running > fast. > > Any ideas/suggestions? > Any experienced documentor on board, please raise hands! > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From mmbrich at fosslabs.com Mon Jul 17 20:13:46 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 18:13:46 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: <1153181627.5582.194.camel@localhost.localdomain> On Mon, 2006-07-17 at 18:53 -0400, Jeff Kowalczyk wrote: > Matthew Brichacek wrote: > > I haven't looked into Selenium yet but with JS does it work at the > > source level only, does it use gecko to actually execute and evaluate > > the JS or can it check for changes in the DOM like it does the source? > > In 5.x there are quite a few places where the DOM is being manipulated > > directly or indirectly and I don't think a source level verification > > tool will catch most of those. > > Selenium directly drives the browser as if the user were clicking it. The > demo http://www.openqa.org/selenium-core/demos.html illustrates the > concept. I tried this out and did a little digging in the Core and IDE. From the looks of it, Selenium can handle a _lot_ of the javascript testing we would need, if not all of it. > > > Maybe augmenting it with the scriptactulous unit test lib would work? > > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting > > Unit tests in the client and server-side source would be enhancements, to > be sure. However, I am skeptical about trying to retrofit unit test > coverage to a large code base. The community would have a hard time > achieving useful code coverage unless there were tests for *everything*, > starting from early in the project. > > Selenium's end-result testing, and the fact that such tests can be > recorded for submission by even novice users, would be an efficient use of > limited community resources. If the testing fever strikes the community, > perhaps all new code could be required to have unit tests, and so on. I had thought of this before too but my experience in requiring unit tests has not been good :). In the CGL project we tried to enforce a rule like this and it was shot down almost before it left the ground. In a PoC environment like that it's understandable but I think even in the case of vtiger the fever would have to be HOT to get everyone on board. Matt From richie at vtiger.com Tue Jul 18 01:40:42 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 22:40:42 -0700 Subject: [Vtigercrm-developers] XTemplate removed Message-ID: <10c80267f98.3578777089016548574.3997907602755987476@@vtiger.com> This is to inform that we have removed XTemplate dependency in vtigercrm5.0.0. XTemplate has been removed from the source as well. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9fe2c2d6/attachment.html From webmaster at vtigerfacile.com Tue Jul 18 05:18:43 2006 From: webmaster at vtigerfacile.com (=?ISO-8859-1?Q?A=EFssa?=) Date: Tue, 18 Jul 2006 11:18:43 +0200 Subject: [Vtigercrm-developers] Idea for future Message-ID: <44BCA773.9050506@vtigerfacile.com> Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa From richie at vtiger.com Tue Jul 18 06:20:36 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:20:36 -0700 Subject: [Vtigercrm-developers] need helping hands Message-ID: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> I am quoting Gopal's bug report. " As per discussion. I am testing product on the following setup: OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a-installer.exe php settings: error_reporting = E_ALL display_errors = On display_startup_errors = On log_errors = On After completion of installation 1.2 mb error log is generated in Apache error.log file. It is better to fix some of the notices and warnings, which will definitely improve the performance of the product. Thanks, Gopal " Need helping hands who can dig into this and give the fixes. We are held up with validation over here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/071764bc/attachment-0002.html From richie at vtiger.com Tue Jul 18 06:21:42 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:21:42 -0700 Subject: [Vtigercrm-developers] Idea for future In-Reply-To: <44BCA773.9050506@vtigerfacile.com> References: <44BCA773.9050506@vtigerfacile.com> Message-ID: <10c8127c4e2.-191772016694368201.-7661796100973677084@@vtiger.com> Hello! I do agree with that. I wanted it to be part of vtigercrm-5.0.0 but it was a feature so dropped it. It does not require too much effort actually. Will be taken up as part of 5.0.1 Richie ---- A?ssa<webmaster at vtigerfacile.com> wrote ---- Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/c3cec421/attachment.html From richie at vtiger.com Tue Jul 18 08:13:08 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 05:13:08 -0700 Subject: [Vtigercrm-developers] need helping hands-2 Message-ID: <10c818dc9b0.-7967502206826138398.-2571256210646174921@@vtiger.com> We are getting quite some javascript issues in IE browsers. Any one out there game to test it in IE and help us by giving the fixes will be great. Please ensure that the fix does not break the Firefox/Mozilla support. Kindly post the fix in the trac and a blurb here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/a6b94bf0/attachment-0002.html From developer at infointegrated.com Tue Jul 18 08:33:39 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Tue, 18 Jul 2006 07:33:39 -0500 Subject: [Vtigercrm-developers] need helping hands In-Reply-To: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> References: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> Message-ID: <9160DA4D-DAAA-4C0D-B458-E401E03C5E49@infointegrated.com> Sounds like quite the challenge. I just started doing some more thorough testing of vtiger 5.0. I have created 3 new tickets on it. I was able to create patches for the first two. #1531 is to reset the Quick Create menu to Quick Create... after selecting an item (with a patch). #1532 cleans up the formatting of the AllMenu: putting headers on all columns, keeping the length more consistent (with a patch). #1533 is a bug when resizing the window too small. the HomePage Dashboard looks horrible. There needs to be some resize code, but I've not had time to look into patching this one. If I have time, I will also look for solutions to some of the error logs and IE JavaScript Issues. Not sure how much free time I'll have... Brian On Jul 18, 2006, at 5:20 AM, Richie wrote: > I am quoting Gopal's bug report. > " > As per discussion. I am testing product on the following setup: > OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a- > installer.exe php settings: > error_reporting = E_ALL display_errors = On display_startup_errors > = On log_errors = On > After completion of installation 1.2 mb error log is generated in > Apache error.log file. > It is better to fix some of the notices and warnings, which will > definitely improve the performance of the product. > Thanks, Gopal > " > > > Need helping hands who can dig into this and give the fixes. > We are held up with validation over here. > > Richie > _______________________________________________ > Get started with creating presentations online - http:// > zohoshow.com?vt From dgrant at accuratetechnologies.com Tue Jul 18 08:58:03 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 18 Jul 2006 08:58:03 -0400 Subject: [Vtigercrm-developers] vtiger arch going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090C@exch.accuratetechnologies.com> >> It is plain that as of now, there are only 2 "strong/loud" arguments. >> I am sure you all will agree that both of them are not overly >> subscribed by any majority yet. > Yes but there is only one idea on the table, and 1 set of criticisms > followed by absolutely no suggestions on how to better the first idea. > This was really my bitch about the first set of posts. Then frankly, you misread. 1) All code must be commented. Ideally, this would be a priority such that commenting existing code would be an actual project, but realistically, the goal of "all NEW code must be commented" or perhaps "every time you touch the code, a comment must be inserted" is doable. 2) The current (4.x) architecture uses a number of "common" functions (so identified by virtue of living in the include directory) that are not really common. An easy test is that if at any time a soi-disant "common" function tests to see what module it was called from and then acts differently based on the result of that test, it ain't common. Those functions should be broken out of the include directory and moved into the appropriate module directory - perhaps something like modules/Foo/UI.php (although this naming convention is definitely open for discussion) 3) Any time you go to the database, the actual SQL should be exposed; it helps integrators understand the layout and function of the database and makes extending the database much easier. It's OK to streamline db functions somewhat though - something like: $query = 'SOME SQL'; @2D_array = query_db($query) or handle_db_error; Is OK. 3) All modules must be atomic. At no time is it EVER permissible that changing the code in module FOO *changes* the functionality of module BAR - with one exception; if module FOO ever *calls* module BAR, and a code change to BAR has broken the interface, then it is understood that FOO calling BAR will break (and shame on whoever changed BAR's interface) In some cases, this will actually move functionality INTO common code, and that's a good thing. For example, currently HelpDesk calls code in Emails to do its email notification stuff (HORROR!) This would be better served by a function in utils.php that called some sort of generic email API: $result = send_email($to, $from, $cc, $bcc, $subject, $body, $flags); 4) There are two major challenges facing the vtiger architecture, independent of code structure: a) Per-user localization, which in turn is broken down into: i) User language of choice; and ii) User operating currency (which may be a function of what office the user is working out of) b) Per-user security (a user cannot edit someone else's Quote, for example) Both of these are ABSOLUTE MUSTS going forward, and there's a lot of heavy lifting there. No matter what the code structure is, these two design structures must be part of the arch. I'm hoping that 5.0 has support for this already... >> Let us get some more ideas- however radical they be- into this list >> and then we will vote the good ideas in. > This is a great idea. I have been looking forward to someone else > posting some ideas to get the ball rolling. I for one welcome radical > ideas if anyone has any. Hrm, well, let's see how welcoming you *really* are. DG From jens at Strawberry.COM Tue Jul 18 09:16:35 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 15:16:35 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] Message-ID: <20060718151635.D16513@Strawberry.COM> -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- An embedded message was scrubbed... From: Jens Hamisch Subject: Patches required for PostgreSQL 8.1.4 Date: Tue, 18 Jul 2006 09:02:01 +0200 Size: 27774 Url: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/efd557cc/attachment-0002.mht From allan.bush+vtiger_dev at gmail.com Tue Jul 18 10:14:27 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 07:14:27 -0700 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <20060718151635.D16513@Strawberry.COM> References: <20060718151635.D16513@Strawberry.COM> Message-ID: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> I have given up on getting postgres support into 5.0 because I got tired of having my changes reverted and the database changing on me. The last straw was when all the database table names were changed without warning. If someone else wants to continue the effect feel free to take a look at this patch and take over the effort. On 7/18/06, Jens Hamisch wrote: > > -- > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > > ---------- Forwarded message ---------- > From: Jens Hamisch > To: vtigercrm-developers at lists.vtigercrm.com > Date: Tue, 18 Jul 2006 09:02:01 +0200 > Subject: Patches required for PostgreSQL 8.1.4 > Hi, > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > database. Compared to mySQL this database seems to require some code > changes. I've located and fixed the following problems: > > 1. SELECT count(*) count FROM ... won't work. > The AS clause is missing: SELECT count(*) AS count FROM ... > > 2. Referring table columns in case of joined tables in the > SELECT or ORDER BY clause requires the columns also to be > listed in a GROUP BY clause. > > 3. tablename.* won't work in a GROUP BY clause > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > LIMIT and OFFSET clause. > > 5. PostgreSQL supports transactions. However the current coding > results in transaction failures. > > I've attached my patches to this mail. Those patches at a first glance > address the problems 1-4. The transaction problem is not yet fixed. > I want to clean up the "simple" SQL statements first, before analyzing > such complex things. > > I'm not a 100% satisfied with the patches, because they introduce some > dbType dependencies into the "high level" vtiger code. Also structural > information is required in the function which expands the queries by > the required GROUP BY clause. I was thinking of moving those things > to a more abstract layer, but stopped doing this, because a generic > solution would either result in parsing and fixing each entire SQL statement > (including all its features and possibilities) or a redesign of the > affected SQL queries itsself. > > In most cases (especially the LIMIT changes) my patches might also work > for mySQL, so the database dependency possibly could be removed. This > might also apply to some of the GROUP BY patches. > > > Hope those changes will find their way to the vtigercrm5 mainline. > > Kind regards > -- Jens > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > From jens at Strawberry.COM Tue Jul 18 11:12:13 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 17:12:13 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com>; from Allan Bush on Tue, Jul 18, 2006 at 07:14:27AM -0700 References: <20060718151635.D16513@Strawberry.COM> <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> Message-ID: <20060718171213.F16513@Strawberry.COM> Hi Allan, hi *, most changes I did seem not to be related to postgres only. So it would help a lot (and remove dbType dependencies) from the code if smb. could check if my changes will also be valid for mySQL ... Jens On Tue, Jul 18, 2006 at 07:14:27AM -0700, Allan Bush wrote: > I have given up on getting postgres support into 5.0 because I got > tired of having my changes reverted and the database changing on me. > The last straw was when all the database table names were changed > without warning. > > If someone else wants to continue the effect feel free to take a look > at this patch and take over the effort. > > On 7/18/06, Jens Hamisch wrote: > > > > -- > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > > > ---------- Forwarded message ---------- > > From: Jens Hamisch > > To: vtigercrm-developers at lists.vtigercrm.com > > Date: Tue, 18 Jul 2006 09:02:01 +0200 > > Subject: Patches required for PostgreSQL 8.1.4 > > Hi, > > > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > > database. Compared to mySQL this database seems to require some code > > changes. I've located and fixed the following problems: > > > > 1. SELECT count(*) count FROM ... won't work. > > The AS clause is missing: SELECT count(*) AS count FROM ... > > > > 2. Referring table columns in case of joined tables in the > > SELECT or ORDER BY clause requires the columns also to be > > listed in a GROUP BY clause. > > > > 3. tablename.* won't work in a GROUP BY clause > > > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > > LIMIT and OFFSET clause. > > > > 5. PostgreSQL supports transactions. However the current coding > > results in transaction failures. > > > > I've attached my patches to this mail. Those patches at a first glance > > address the problems 1-4. The transaction problem is not yet fixed. > > I want to clean up the "simple" SQL statements first, before analyzing > > such complex things. > > > > I'm not a 100% satisfied with the patches, because they introduce some > > dbType dependencies into the "high level" vtiger code. Also structural > > information is required in the function which expands the queries by > > the required GROUP BY clause. I was thinking of moving those things > > to a more abstract layer, but stopped doing this, because a generic > > solution would either result in parsing and fixing each entire SQL statement > > (including all its features and possibilities) or a redesign of the > > affected SQL queries itsself. > > > > In most cases (especially the LIMIT changes) my patches might also work > > for mySQL, so the database dependency possibly could be removed. This > > might also apply to some of the GROUP BY patches. > > > > > > Hope those changes will find their way to the vtigercrm5 mainline. > > > > Kind regards > > -- Jens > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From allan.bush+vtiger_dev at gmail.com Tue Jul 18 11:21:46 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 08:21:46 -0700 Subject: [Vtigercrm-developers] Commit list is broken Message-ID: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> I haven't received any email from the commit/ticket list (vtigercrm-commits at lists.vtigercrm.com) since the 16th. I just made a couple changes which should have triggered emails and they haven't been received either so I'm fairly certain the list is down. From mmbrich at fosslabs.com Tue Jul 18 14:28:48 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 18 Jul 2006 12:28:48 -0600 Subject: [Vtigercrm-developers] Commit list is broken In-Reply-To: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> References: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> Message-ID: <1153247328.5582.214.camel@localhost.localdomain> This is probably from the SVN upgrade, the version we are on now moved all hook scripts to a diff area and I probably missed one. I'll see if I can fix it ASAP. Matt On Tue, 2006-07-18 at 08:21 -0700, Allan Bush wrote: > I haven't received any email from the commit/ticket list > (vtigercrm-commits at lists.vtigercrm.com) since the 16th. > > I just made a couple changes which should have triggered emails and > they haven't been received either so I'm fairly certain the list is > down. > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jens at Strawberry.COM Tue Jul 18 14:44:48 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 20:44:48 +0200 Subject: [Vtigercrm-developers] Yet another postgres8 patch Message-ID: <20060718204448.D29275@Strawberry.COM> Hi, yet another patch addressing postgres8 Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- *** vtiger_crm/include/database/Postgres8.php.rev8092 Tue Jul 18 20:37:05 2006 --- vtiger_crm/include/database/Postgres8.php Tue Jul 18 20:38:50 2006 *************** *** 122,127 **** --- 122,131 ---- elseif( $table == "vtiger_profile2field") $subfields = array ( "profileid", "tabid", "fieldid", "visible", "readonly"); + //vtiger_field + elseif( $table == "vtiger_field") + $subfields = array ( "tabid", "fieldid", "columnname", "tablename", "generatedtype", "uitype", "fieldname", "fieldlabel", "readonly", "presence", "selected", "maximumlength", "sequence", "block", "displaytype", "typeofdata", "quickcreate", "quickcreatesequence", "info_type"); + //fields of the requested array still undefined else $log->info("function expandRecord: please add structural information for table '".$table."'"); *** vtiger_crm/include/utils/CommonUtils.php.rev8092 Tue Jul 18 20:25:23 2006 --- vtiger_crm/include/utils/CommonUtils.php Tue Jul 18 20:36:01 2006 *************** *** 960,971 **** { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in $blockid_list and vtiger_field.displaytype in (1,2,4) order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and vtiger_field.displaytype in (1,2,4) and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." group by vtiger_field.fieldid order by block,sequence"; } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); --- 960,974 ---- { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN $blockid_list AND vtiger_field.displaytype IN (1,2,4) ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND vtiger_field.displaytype IN (1,2,4) AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); *************** *** 976,987 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list ." and ".$display_type_check." and info_type = '".$info_type."' order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and info_type = '".$info_type."' and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } else --- 979,993 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list ." AND ".$display_type_check." AND info_type = '".$info_type."' ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND info_type = '".$info_type."' AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } else *************** *** 988,999 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } $result = $adb->query($sql); --- 994,1008 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } $result = $adb->query($sql); *************** *** 1789,1796 **** } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and quickcreate=0 and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." order by quickcreatesequence"; } $category = getParentTab(); --- 1798,1808 ---- } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND quickcreate=0 AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." ORDER BY quickcreatesequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $quickcreate_query = fixPostgresQuery( $quickcreate_query, $log, 0); } $category = getParentTab(); *** vtiger_crm/modules/Users/Authenticate.php.rev8092 Tue Jul 18 19:55:38 2006 --- vtiger_crm/modules/Users/Authenticate.php Tue Jul 18 19:57:24 2006 *************** *** 40,47 **** { //Inserting entries for audit trail during login ! $date_var = date('YmdHis'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,$date_var)"; $adb->query($query); --- 40,47 ---- { //Inserting entries for audit trail during login ! $date_var = date('Y-m-d H:i:s'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,'$date_var')"; $adb->query($query); From libregeek at gmail.com Wed Jul 19 01:07:25 2006 From: libregeek at gmail.com (Manilal K M) Date: Wed, 19 Jul 2006 10:37:25 +0530 Subject: [Vtigercrm-developers] Something happened with forums.vtiger.com Message-ID: <2315046d0607182207k577376efv69026d9ce7e887c2@mail.gmail.com> Hi Team, Today Morning I got the reminder for the forum topic given below. How this happened? There are mo updates on this thread and it's almost 4 months old. Please look into it. regards Manilal ---------- Forwarded message ---------- From: webmaster at vtiger.com Date: 19-Jul-2006 07:38 Subject: New Topic Notification for forum "Announcements" - vtiger CRM 5 Alpha 5 Released To: Hello ! Sai has posted a new topic called "vtiger CRM 5 Alpha 5 Released" in the "Announcements" forum at vtiger. You can use the following link to view the topic: http://forums.vtiger.com/viewtopic.php?p=23074#23074 ----------------------------------------------- Posted text: Hi, We are pleased to announce the vtiger [b:7141f7c5eb]CRM 5.0 Alpha 5 release[/b:7141f7c5eb]. The intent of this release is to showcase to the vtiger community, the significant changes made after v5 Alpha 4 release i.e., changes since Mar 31, 06\' . We have conducted performance testing for some of the modules using a popular [b:7141f7c5eb]Web Based Testing Software (AdventNet QEngine 6.0),[/b:7141f7c5eb] which helped us to identify some of the bottlenecks in performance. We will publish the performance reports soon. We thank AdventNet for permitting us to make use of this interesting software and we gladly recommend it to everyone too, not because AdventNet allowed us to use it but because it is really good. We are also pleased to release the downloadable version of the [b:7141f7c5eb]vtiger CRM PHP API Documentation.[/b:7141f7c5eb] The demo of vtigerCRM 5 alpha 5 is available at http://vtiger.com/products/crm/demo_5alpha/index.php You can download the [b:7141f7c5eb]EXE, BIN, or tar.gz[/b:7141f7c5eb] from Sourceforge.net. [b:7141f7c5eb]NOTE:[/b:7141f7c5eb] We strongly recommend CRM community NOT to USE vtiger CRM 5 Alpha 5 for real-time deployment. In case you are looking for an immediate CRM solution for your business, please consider using the vtiger CRM 4.2.3 (latest stable version) or 4.2.4 which will be out shortly. [b:7141f7c5eb]Important URLs:[/b:7141f7c5eb] [b:7141f7c5eb]Download:[/b:7141f7c5eb] http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=186641 [b:7141f7c5eb]Report Bugs[/b:7141f7c5eb] @: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Note: Please refer to the reported bugs before submitting a new bug. [b:7141f7c5eb]Release Notes:[/b:7141f7c5eb] * Smarty template applied to Currency Configuration Feature * List View feature database queries are optimized for all the modules * PHP API documentation for some of the major function * New module called Marketing is added. Campaigns module is now part of Marketing primary module. * AJAXified Notification Schedulers * AJAXified Inventory Notifications * AJAXified Picklist Settings * AJAXified Assign Module Owners * New UI for Integration of Mail Merge Templates * New UI for Company Information * New UI for Outgoing Mail Server * New UI for Backup Server Configuration * New UI for Terms and Conditions * New UI for Announcements * New UI for RSS module Thanks & Regards, Don ----------------------------------------------- You are receiving this email because you are watching the forum, "Announcements" at vtiger. If you no longer wish to watch this forum you can either click the "Stop watching this forum link" found at the bottom of the "Announcements" forum, or by clicking the following link: http://forums.vtiger.com/viewforum.php?f=1&unwatch=forum -- Thanks, The Management -- I would rather be a serf in a poor man's house and be above ground than reign among the dead From dgrant at accuratetechnologies.com Wed Jul 19 08:58:46 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 19 Jul 2006 08:58:46 -0400 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Simple question: when is the next (Beta?) release of V5.0 due out? DG From richie at vtiger.com Wed Jul 19 09:22:20 2006 From: richie at vtiger.com (Richie) Date: Wed, 19 Jul 2006 06:22:20 -0700 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? In-Reply-To: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Message-ID: <10c86f3829c.5523764322808677804.-2671785383507032457@@vtiger.com> Simpler answer :-): No betas. Expect RC1 in 10 days or so. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Simple question: when is the next (Beta?) release of V5.0 due out? DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/e1ba94eb/attachment-0002.html From Matjaz.Slak at atol.si Wed Jul 19 10:45:49 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Wed, 19 Jul 2006 16:45:49 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Message-ID: Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment.bin From developer at infointegrated.com Thu Jul 20 00:45:03 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Wed, 19 Jul 2006 23:45:03 -0500 Subject: [Vtigercrm-developers] Categories / Sub-Categories, Too Much In-Reply-To: References: Message-ID: If you haven't looked at the current collection of categories and subcategories, take a look. I think that it is becoming too much. Here's the current layout: My Home Page Home Activities Calendar Emails Marketing Campaigns Accounts Contacts Emails Leads Activities Calendar Notes Sales Leads Accounts Contacts Potentials Quotes Sales Order Invoice Products PriceBooks Notes Activities Calendar Support HelpDesk FAQ Accounts Contacts Products Notes Emails Activities Calendar Analytics Dashboard Reports Inventory Products Vendors PriceBooks Purchase Order Sales Order Quotes Invoice Tools RSS My Sites Notes Settings Settings I know the list is long and hard to read, but that's my point. I know and understand that different people will want their sub-modules in different places. As long as the method for changing this is documented, I think that is ok. The default configuration, though, should be simpler. This current layout is almost scary. At least for an end-user it would be. I feel this change should be made before 5.0 GA. To simplify, each item should only appear in one category. I have an updated proposal below that is the closest to meeting most of my customer's needs. With the All Menu, Quick Create, Related Items, and Tag Cloud, it shouldn't matter much if some modules are on different categories. I hope that there are still plans on combining activities and calendar into one item as well (I believe this was put off until after 5.0 GA). I think that an interface for managing these should also be planned post 5.0 GA. I also think the order of the items is important and (where relevant) the order should remain consistent. For example, the sub categories should remain in the same order under the category as it shows in the All Menu. What does everyone else think? Anyone else show this to existing clients and get questions about why the same module appears in many places? That's what got me started thinking of improvements. Any better ideas? My Home Page Home Emails Activities Calendar Contacts Notes Marketing Campaigns Leads Sales Accounts Potentials Quotes Sales Order Invoice Support HelpDesk FAQ Inventory Products Vendors PriceBooks Purchase Order Analytics Dashboard Reports Tools Settings My Sites RSS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/50687ed3/attachment.html From richie at vtiger.com Thu Jul 20 04:06:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:06:18 -0700 Subject: [Vtigercrm-developers] unable to add users to trac Message-ID: <10c8af88631.-2915976287139770639.-215398406965928840@@vtiger.com> Hi Matt! Could you please have a look at the issue please? I am unable to add users to the trac anymore. I am using the following url. vtiger.fosslabs.com/service Do have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/02abcafe/attachment-0002.html From richie at vtiger.com Thu Jul 20 04:17:10 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:17:10 -0700 Subject: [Vtigercrm-developers] trac down? Message-ID: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Hi! The trac seems to be down. Matt, kindly have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/df8c96af/attachment.html From mmbrich at fosslabs.com Thu Jul 20 04:24:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 20 Jul 2006 02:24:10 -0600 Subject: [Vtigercrm-developers] trac down? In-Reply-To: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> References: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Message-ID: <1153383850.5617.0.camel@localhost.localdomain> I was doing some work and had to give it a quick reboot. Should be back up and working now. Matt On Thu, 2006-07-20 at 01:17 -0700, Richie wrote: > Hi! > > The trac seems to be down. > Matt, kindly have a look please. > > Thanks, > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Thu Jul 20 05:47:37 2006 From: crm at email.si (Ales Petric) Date: Thu, 20 Jul 2006 10:47:37 +0100 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44AE643B.1040800@vtigerfacile.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> Message-ID: <44BF5139.9050402@email.si> Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Ai"ssa wrote: > Hi Richie, > i have a login for track, but not the right to submit ticket. > thanks, > Ai"ssa (very busy !) > > Richie a ?crit : > >> Hello! >> >> I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. >> Please cross-check if you have received the relevant mails in the id from which you had made the access >> request. >> >> Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. >> >> richie at vtiger dot com >> >> Richie >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/f47f9233/attachment-0002.html From richie at vtiger.com Thu Jul 20 04:58:46 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:58:46 -0700 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44BF5139.9050402@email.si> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> <44BF5139.9050402@email.si> Message-ID: <10c8b2890c0.2475106285347017844.4336268421121807772@@vtiger.com> Hi Ales! I have granted permission to the trac to all those who have asked for it. Not even 1 single request has been denied. Why should it be? The product is as much yours as mine just that someone has to be in some hiearchy somewhere does not mean that we have a monopoly over it. This is the first time I have got your request and I have granted access to you too. The 1 minute that I spend giving permission saves hours to the community as a whole. You are important, not only to me but to the community as well. I am sure you will do well. Richie ---- Ales Petric<crm at email.si> wrote ---- Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Aïssa wrote: Hi Richie, i have a login for track, but not the right to submit ticket. thanks, Aïssa (very busy !) Richie a ?crit : Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie ------------------------------------------------------------------------ _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/aeeddad4/attachment.html From richie at vtiger.com Thu Jul 20 11:30:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 08:30:05 -0700 Subject: [Vtigercrm-developers] permissions revoked Message-ID: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Dear Team, I have revoked permissions for checkin in the main 5.0 trunk. Only the following have permission to checkin now into the 5.0 trunk. core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj All checkins have to be thru these guys alone. The permissions will be restored once the 5.0 is released. Requesting your understanding, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/0cea747a/attachment-0002.html From tgironnay at lexsi.com Thu Jul 20 11:54:15 2006 From: tgironnay at lexsi.com (GIRONNAY Thibault) Date: Thu, 20 Jul 2006 17:54:15 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi all, Matjaz I'll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It's too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we'll have others hands up cabugs ________________________________ De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: * debugging (fixing parts that either don't work at all and/or work incorrectly) * improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: * multilanguage support (simply get rid of any and all hard-coded strings) * full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/fdd85202/attachment.html From nolan at peaceworks.ca Thu Jul 20 13:50:43 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Thu, 20 Jul 2006 13:50:43 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: References: Message-ID: <44BFC273.5060604@peaceworks.ca> Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Thu Jul 20 13:47:54 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 20 Jul 2006 13:47:54 -0400 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE4@exch.accuratetechnologies.com> Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection My vtigercrm.log is full of these. Where are they coming from and what can I do to stop it? DG From jens at Strawberry.COM Fri Jul 21 02:34:10 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Fri, 21 Jul 2006 08:34:10 +0200 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com>; from Richie on Thu, Jul 20, 2006 at 08:30:05AM -0700 References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Message-ID: <20060721083410.A22106@Strawberry.COM> Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From Matjaz.Slak at atol.si Fri Jul 21 03:04:48 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 09:04:48 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi! I agree completly. Security should be on the list of to-dos. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "GIRONNAY Thibault" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 17:54 Please respond to vtigercrm-developers at lists.vtigercrm.com To cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Matjaz I?ll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It?s too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we?ll have others hands up cabugs De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment.bin From Matjaz.Slak at atol.si Fri Jul 21 07:36:00 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 13:36:00 +0200 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <44BFC273.5060604@peaceworks.ca> Message-ID: Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Nolan Andres Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment.bin From jtk at yahoo.com Fri Jul 21 09:09:10 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Fri, 21 Jul 2006 09:09:10 -0400 Subject: [Vtigercrm-developers] permissions revoked References: <20060721083410.A22106@Strawberry.COM> Message-ID: Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. From richie at vtiger.com Fri Jul 21 10:11:25 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:11:25 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <20060721083410.A22106@Strawberry.COM> References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916d296e.5312358042738553104.8864199634924158691@@vtiger.com> Hi Jens! Currently, we are working on fixing the breakages that we have committed. Let these stabilize, then we can integrate this together. ok? I do not want to add one more variable now. Hence the precaution. Richie ---- Jens Hamisch<jens at strawberry.com> wrote ---- Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/ed49a8d5/attachment-0002.html From richie at vtiger.com Fri Jul 21 10:12:10 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:12:10 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: References: <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916dd6be.-546019034062113847.-6787520244753134675@@vtiger.com> Yes, you are right. We will take this into consideration before vtigercrm-5.0.0 is out. In other words, postgres is going to be part of this very release. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/51fe5c86/attachment.html From richie at vtiger.com Fri Jul 21 10:13:48 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:13:48 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: References: Message-ID: <10c916f5716.-3447470126087516421.7834933168012625785@@vtiger.com> Matjaz, you already would have got the access mail for the trac. About the TRAC Wiki, Matt will do the needful. Let us know if you need anything else. Richie ---- Matjaz.Slak at atol.si<Matjaz.Slak at atol.si> wrote ---- Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 Nolan Andres <nolan at peaceworks.ca> Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned        Plea        froma        VTiger        Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > >   > > Matjaz I’ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It’s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > >   > > Hope we’ll have others hands up > >   > > cabugs > >   > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > >   > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > >     * debugging (fixing parts that either don't work at all and/or work >       incorrectly) >     * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > >     * multilanguage support (simply get rid of any and all hard-coded >       strings) >     * full per user or at least per-system localization support (number >       format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 > > *Richie <richie at vtiger.com>* > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > >                   > > To > >                   > > vtigercrm-developers at lists.vtigercrm.com > > cc > >                   > > vtigercrm-developers at lists.vtigercrm.com > > Subject > >                   > > Re: [Vtigercrm-developers] An Impassioned Plea from a        VTiger     >    Integrator > >   > >   > >                   > >   > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: >> >>  Hi! >> >>  If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > <http://zohoshow.com?vt/> _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7be12bf9/attachment-0002.html From allan.bush+vtiger_dev at gmail.com Fri Jul 21 11:32:23 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 21 Jul 2006 08:32:23 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <-8603876167918116646@unknownmsgid> References: <-8603876167918116646@unknownmsgid> Message-ID: <3bec26390607210832x65ed46eo60856d8e2972c110@mail.gmail.com> This is the page we should be using to keep track of everything to be done for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=new&status=assigned&status=reopened&milestone=4.2.5 It would be nice to have a 4.2.6 (or 4.2 future) milestone to keep the list realistic though. Fell free to organize, add and prioritize the things in that list. On the same note you here is the page of everything already accomplished for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=closed&milestone=4.2.5 On 7/21/06, Richie wrote: > > Matjaz, you already would have got the access mail for the trac. > About the TRAC Wiki, Matt will do the needful. > > > Let us know if you need anything else. > > Richie > > > > > ---- Matjaz.Slak at atol.si wrote ---- > > > > Hi! > > Thank you! > > I hope I'll be able to finish up some of my other tasks within a week or > so and then I'll start posting ideas about what to work on here. > > *If anybody has any general wishes and/or requests about which item(s) you > would like to have fixed in 4.2.x, post them here.* By this I mean areas > perceived by vTiger users. Try to fit them in the following categories: > > - debugging (fixing user-perceived functions that either don't work > at all and/or work incorrectly) > - improving usability (based on feedback from users) > - improving security (let us know of possible security holes) > - multilanguage support (simply get rid of any and all hard-coded > strings) > - localization support (number format, date format, currency support > etc - per user or at least per-system) > - other (we can create aditional categories if the need arises) > > > For example: > > - Private Custom Views - allow for a custom view to be marked as > private and only be visible to the user that created it (usability) > - All View columns sortable - allow a user to click on any column > and sort it (usability) > - Repeating calls/meetings - don't work at all? (debugging) > - etc... > > > I'll be collecting them and posting them somewhere - the TRAC Wiki comes > to mind as an appropriate place. We can the priorithise them and look into > required work - and then create tickets for developers (us, again :) to work > on. > > *Richie, Jeff, Matt and/or others:* would it me possible for me to have > acces to post some content to the TRAC Wiki? I would create a document like > "vTiger 4.2.x to-do area" that would include these items we wish to work > on - and specific goals for them. Tickets would then be created based on > these. This document would represent the general guideline. > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > *Nolan Andres * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 20.07.2006 19:50 Please respond to > vtigercrm-developers at lists.vtigercrm.com > > To > vtigercrm-developers at lists.vtigercrm.com cc > > Subject > Re: [Vtigercrm-developers] An Impassioned Plea froma > VTiger Integrator > > > > > > > Hi all, > > Although I'd really love to be able to just contribute features without > having to re-integrate (into v5,) I agree with priorities and I'll > second the addition of security to the list. Security through obscurity > is bad enough, but with open source projects, it simply becomes security > through ignorance. I certainly wouldn't trust vTiger's security in an > environment where the data is actually confidential and a malicious or > competitive party would stand to gain by accessing it illicitly. > > I don't have the availability to co-ordinate things, but you can count > on me for some quantity of bug-fixes, security patches, etc. > > peace, > nokes > > GIRONNAY Thibault wrote: > > Hi all, > > > > > > > > Matjaz I'll be with you and your team in your enterprise, I agree with > > your priorities and have one another to add : the security. The > > organisation sharing privileges for example is indeed totally an > > illusion. It's too easy too change those settings while not being admin > > or to see all records even if the privileges are private. I think this > > is very harmful to offer such buggy features and can discredit Vtiger > > for the people who have interests in security. > > > > > > > > Hope we'll have others hands up > > > > > > > > cabugs > > > > > > > > ------------------------------------------------------------------------ > > > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > > de* Matjaz.Slak at atol.si > > *Envoy? :* mercredi 19 juillet 2006 16:46 > > *? :* vtigercrm-developers at lists.vtigercrm.com > > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > > Integrator > > > > > > > > > > Hi Richie and the rest of the team! > > > > You address me correctly, Matjaz is my name :) > > > > > > As I belive the 4.2.x stream is the current "production" vTiger > > environment for most of the users, my primary goal would be to focus on: > > > > * debugging (fixing parts that either don't work at all and/or work > > incorrectly) > > * improving usability (based on feedback from users) > > > > > > I would also like to try and get the following not-quite-features, maybe > > > bugs? implemented/fixed: > > > > * multilanguage support (simply get rid of any and all hard-coded > > strings) > > * full per user or at least per-system localization support (number > > format, date format, currency support etc) > > > > > > These two last items are - in my opinion - somewhere between debugging > > and new features. vTiger is already supposed to support multiple > > languages, however this support is not well implemented. The same can be > > > said for localization - vTiger is supposed to be able to support > > per-user date format, but again there are areas where the implementation > > > is not as good as it could be. > > > > Also, based on my researches into existing vTiger deployments, I see > > there are a lot of non-english users, but they probably are using forked > > > code, as due to these two issues they cannot use the "official" 4.2.x > > stream code. I would like to get these users back on the team, and I > > know they might return only if we provide them with a 100% localisable > > product. This will enable them to post the patches they make back to the > > > community or at least give them an opportunity to work with us on > > resolving them. > > > > I would try and keep us on this track, rather than go try implement new > > features and make large changes to UI - the place for these is v5. > > > > > > To achieve this, I would first gather any and all contributions > > currently lying around (in the forum, as provided by other people here > > etc.) - matching the categories above - and start the process of getting > > > them in the code. *I would like to see a show of hands* from people that > > > would be prepared to devote some time to debugging/updating tthese > > contributions - as some might need an update. I know me and my > > colleagues in our company will. > > > > If all goes well, we could try and implement a regular timeline (say > > every month) when we would be releasing point versions. If I get at > > least two or three people to help, I guess we could have our first > > result (4.2.5 I guess) in two months. > > > > I think there will be people using the 4.2.x stream for at least a year > > after v5 is released, and that if we as a team show them we are > > supporting them, than they will upgrade to v5 -> if we don't they might > > start looking elsewhere. > > > > > > *Thoughts, anyone?* > > > > > > Matjaz Slak > > matjaz.slak at atol.si > > > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > > *Richie * > > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > > > 17.07.2006 16:57 > > > > Please respond to > > vtigercrm-developers at lists.vtigercrm.com > > > > > > > > To > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > cc > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > Subject > > > > > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > > Integrator > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matjaz! > > I hope I am addressing you properly if not please forgive me and direct > > to the proper mode of addressing. > > > > If you are game then great! > > Welcome to the club. > > Please select your stand-in helper so that at least we have a backup for > > > Linus Matjaz. Let me know and I will grant you the relevant access. > > > > It would be nice if you could briefly state how you plan to address the > > disparate contributions. This is just to get an idea as there are lots > > of data floating around in the code contributions and mailing lists; > > wanted to know if you have any specific plan. I will be busy with the v5 > > > release and will not be able to help you much so the query. > > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > > page which reflects the status of the contributions. I am not sure if > > that is updated till the 4.2.4 release though. > > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > > > > Allan, any tips from you will be nice. > > > > Richie > > > > > > > > > > ---- Sergio A. Kessler wrote ---- > > > > On 7/14/06, Matjaz.Slak at atol.si wrote: > >> > >> Hi! > >> > >> If there's no one else, I volunteer to be the v4 Linus. > > > > just do it. ;-) > > > > > > /sak > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > -- > > > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/411ae3e6/attachment.html From don at vtiger.com Fri Jul 21 12:31:48 2006 From: don at vtiger.com (don) Date: Fri, 21 Jul 2006 09:31:48 -0700 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <10c91edb0e4.-4543952587404481040.-9186935435207679906@@vtiger.com> Hi DG, The logs given below are generated from the include/database/PearDatabase.php file. To avoid this kindly do the following: Edit the include/database/PearDatabase.php file and comment the following lines: -- $this->println("TRANS creating new connection"); in the function checkConnection -- $this->println("ADODB fetchByAssoc return null"); in the function function fetchByAssoc Hope this helps you. Kindly contact us for any further clarifications. Thanks & Regards, Don Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7714d42a/attachment-0002.html From jens at Strawberry.COM Tue Jul 18 03:02:14 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 07:02:14 -0000 Subject: [Vtigercrm-developers] Patches required for PostgreSQL 8.1.4 Message-ID: <20060718090201.B15699@Strawberry.COM> Hi, I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 database. Compared to mySQL this database seems to require some code changes. I've located and fixed the following problems: 1. SELECT count(*) count FROM ... won't work. The AS clause is missing: SELECT count(*) AS count FROM ... 2. Referring table columns in case of joined tables in the SELECT or ORDER BY clause requires the columns also to be listed in a GROUP BY clause. 3. tablename.* won't work in a GROUP BY clause 4. LIMIT #,# is not supported. PostgreSQL requires a single LIMIT and OFFSET clause. 5. PostgreSQL supports transactions. However the current coding results in transaction failures. I've attached my patches to this mail. Those patches at a first glance address the problems 1-4. The transaction problem is not yet fixed. I want to clean up the "simple" SQL statements first, before analyzing such complex things. I'm not a 100% satisfied with the patches, because they introduce some dbType dependencies into the "high level" vtiger code. Also structural information is required in the function which expands the queries by the required GROUP BY clause. I was thinking of moving those things to a more abstract layer, but stopped doing this, because a generic solution would either result in parsing and fixing each entire SQL statement (including all its features and possibilities) or a redesign of the affected SQL queries itsself. In most cases (especially the LIMIT changes) my patches might also work for mySQL, so the database dependency possibly could be removed. This might also apply to some of the GROUP BY patches. Hope those changes will find their way to the vtigercrm5 mainline. Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- A non-text attachment was scrubbed... Name: postgres-patches.tgz Type: application/octet-stream Size: 18385 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/e9b482c8/attachment.obj From richie at vtiger.com Tue Jul 4 07:02:55 2006 From: richie at vtiger.com (Richie) Date: Tue, 04 Jul 2006 04:02:55 -0700 Subject: [Vtigercrm-developers] update bleeding edge svn Message-ID: <10c393477d3.4701894980957041264.-7646275652836694714@@vtiger.com> Hi Matt! Wanted to confirm if we have a script in place for updating the latest code in the vtiger-demo.fosslabs.com site? There have been forum queries if the updates are happening in the first place. Kindly inform. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060704/3631a295/attachment-0003.html From saint at vtiger.com Tue Jul 4 14:40:33 2006 From: saint at vtiger.com (Saint) Date: Wed, 05 Jul 2006 00:10:33 +0530 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings Message-ID: <44AAB621.8080701@vtiger.com> Folks, The following are the new "Settings" icons getting into vtiger 5. *Module * *Icon * Users Roles Privilege Profiles Groups Modules Access Fields Access Module Owners Announcements Custom Fields Picklist Editor Email Templates Mail Merge Tempaltes Notification Schedulers Inventory Notifications Inventory Terms & Conditions Company Details Mail Server Settings Backup Server Settings Proxy Server Settings System Information Invoice Configuration Audit Trail Tax Configuration Currency Settings Migration -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1968 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0073.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1951 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0074.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2197 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0075.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2328 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0076.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2134 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0077.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2319 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0078.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1925 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0079.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2267 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0080.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1883 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0081.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1957 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0082.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2160 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0083.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2175 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0084.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1975 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0085.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2264 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0086.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2370 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0087.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1732 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0088.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2121 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0089.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1972 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0090.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2182 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0091.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2492 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0092.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2546 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0093.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1796 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0094.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2441 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0095.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2451 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0096.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: set-IcoMigration.gif Type: image/gif Size: 2187 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0097.gif From sergiokessler at gmail.com Tue Jul 4 15:09:33 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 4 Jul 2006 16:09:33 -0300 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings In-Reply-To: <44AAB621.8080701@vtiger.com> References: <44AAB621.8080701@vtiger.com> Message-ID: <49216030607041209h171b32d1w9b6e737e1c65a5a8@mail.gmail.com> wow, beautiful ! /sak On 7/4/06, Saint wrote: > > > Folks, > > The following are the new "Settings" icons getting into vtiger 5. > > > Module > Icon > > Users > > > Roles > > > Privilege Profiles > > > Groups > > > Modules Access > > > Fields Access > > > Module Owners > > > Announcements > > > Custom Fields > > > Picklist Editor > > > Email Templates > > > Mail Merge Tempaltes > > > Notification Schedulers > > > Inventory Notifications > > > Inventory Terms & Conditions > > > Company Details > > > Mail Server Settings > > > Backup Server Settings > > > Proxy Server Settings > > > System Information > > > Invoice Configuration > > > Audit Trail > > > Tax Configuration > > > Currency Settings > > > Migration > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From don at vtiger.com Wed Jul 5 11:59:39 2006 From: don at vtiger.com (don) Date: Wed, 05 Jul 2006 08:59:39 -0700 Subject: [Vtigercrm-developers] vtiger CRM 5.0 Beta2 Released Message-ID: <10c3f6a8177.-9001623588305850621.-4297454805191080021@@vtiger.com> Hi All, We are pleased to announce the release of vtigerCRM 5.0 Beta 2. In this release the main focus is on the quality front and we have fixed most of the major bugs that were in the vtigerCRM 5.0 Beta. We have also incorporated most of the feedbacks/suggestions given by the community over 5.0 Beta. In the UI front, the Settings UI has been totally revamped. This release will depict the developments done after vtiger CRM 5.0 Beta. You can give it a try and let us know your valuable feedbacks and suggestions. The live demo of vtigerCRM 5.0 Beta is available at http://vtiger.com/products/crm/demo_5beta/index.php You can download the vtiger CRM 5.0 Beta2 from the following URL : http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=196218&release_id=429844 You can post your feed backs and suggestions at http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Thanks & Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/59d438e1/attachment-0001.html From nico.gnauck at googlemail.com Thu Jul 6 13:12:58 2006 From: nico.gnauck at googlemail.com (Nico Gnauck) Date: Thu, 6 Jul 2006 19:12:58 +0200 Subject: [Vtigercrm-developers] Merge with OpenOffice documents Message-ID: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Hello, I'm currently working on a Mail Merge for version 5.0 with Open Office Dokuments based on the rtf Merge for version 4.2.3. You can find the thread and the Merge skripts for Accounts and Contacts in this thread: http://forums.vtiger.com/viewtopic.php?t=7223. If anybody has time to test this, please do so and give me feedback. Thanks, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/776050fd/attachment-0003.html From mmbrich at fosslabs.com Thu Jul 6 13:32:44 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 06 Jul 2006 11:32:44 -0600 Subject: [Vtigercrm-developers] Merge with OpenOffice documents In-Reply-To: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> References: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Message-ID: <1152207165.22922.96.camel@localhost.localdomain> Hi Nico, I haven't had a chance to test yet but I did merge this into my vtiger5 branch in the branches/ directory of the SCM system. I will get it tested as soon as I can, from there the other developers can decide if it should be merged into trunk/. If you find/fix issues in this branch please post the patches here and I will get them merged in. If you have enough issues and would like, I can set you up with commit access to my branch. Thanks for your contribution! Matt On Thu, 2006-07-06 at 19:12 +0200, Nico Gnauck wrote: > Hello, > > I'm currently working on a Mail Merge for version 5.0 with Open Office > Dokuments based on the rtf Merge for version 4.2.3. > You can find the thread and the Merge skripts for Accounts and > Contacts in this thread: > http://forums.vtiger.com/viewtopic.php?t=7223. > If anybody has time to test this, please do so and give me feedback. > > Thanks, Nico > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Thu Jul 6 16:17:20 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Thu, 06 Jul 2006 16:17:20 -0400 Subject: [Vtigercrm-developers] Trac 0.9.6 released Message-ID: Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. From richie at vtiger.com Fri Jul 7 01:22:12 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:22:12 -0700 Subject: [Vtigercrm-developers] trac account Message-ID: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/f616fb9d/attachment-0001.html From richie at vtiger.com Fri Jul 7 01:25:43 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:25:43 -0700 Subject: [Vtigercrm-developers] update svn-version Message-ID: <10c4772d440.733718465091492167.4729172311574536110@@vtiger.com> Hi! Got this mail in the forums. Can someone do the needful please? Jeff, what do you say? "Hi forum users and especially vtiger admins, im not quite sure, if this is the right place to post, but i think you guys should really consider updating your subversion server to > 1.2.x. For us developers using eclipse it's painstaking to get it to work well, because the svn plugin (subclipse.tigris.org) only supports the old svn servers (< 1.2.0) only if you choose to install a very old version of the plugin (< 0.9.3.0). Unfortunately, this version of the plugin is very buggy, and i can't get it to work properly in my env, especially with eclipse 3.1. It maybe a little selfish to request an update, just because of me not getting my setup to work, but svn has improved so much from 1.1.x to 1.2.x so it might be usefull for everyone. Regards Benjamin" Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/606fa218/attachment-0003.html From richie at vtiger.com Fri Jul 7 01:28:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:28:56 -0700 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com Message-ID: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Hi! Is the vtiger-demo.fosslabs.com updated with the bleeding edge code please? Matt, I guess, we are putting a lot of stress on you alone and it is not fair. Do you think you require some guys from the community to assist you? My main concern is that not any single individual be overloaded. vtiger is team-work and it should be that way. Everyone should prosper. Dedicated volunteers please raise their hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/4782857f/attachment-0001.html From richie at vtiger.com Fri Jul 7 01:31:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:31:56 -0700 Subject: [Vtigercrm-developers] Trac 0.9.6 released In-Reply-To: References: Message-ID: <10c47788588.1738553798220722432.6769330270375144874@@vtiger.com> Let us get this upgraded then. Jeff, would you take ownership for all the 3rd party upgrades please. I know you are already tracking the 3rd party packages but what I am stating is to take ownership for all upgrades for the s/w used to keep track of vtiger? If you need assistants, give a shout in the mailing list. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/1aaf8fb0/attachment-0003.html From webmaster at vtigerfacile.com Fri Jul 7 09:40:11 2006 From: webmaster at vtigerfacile.com (=?UTF-8?B?QcOvc3Nh?=) Date: Fri, 07 Jul 2006 15:40:11 +0200 Subject: [Vtigercrm-developers] trac account In-Reply-To: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Message-ID: <44AE643B.1040800@vtigerfacile.com> Hi Richie, i have a login for track, but not the right to submit ticket. thanks, A?ssa (very busy !) Richie a ?crit : > Hello! > > I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. > Please cross-check if you have received the relevant mails in the id from which you had made the access > request. > > Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. > > richie at vtiger dot com > > Richie > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Fri Jul 7 23:23:02 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 21:23:02 -0600 Subject: [Vtigercrm-developers] New communications system Message-ID: <1152328983.32174.36.camel@localhost.localdomain> I wrote a new CommSystem module in my 5.0.2-MMBRICH branch. The comm system is a full replacement for the chat system from RC1 and also adds a host of API's to manipulate it from your favorite external system or vtiger module :). Here is a short list of features, any testers or patches to help move it along are appreciated. Features: 1) Full P2P chat 2) Session/Off-line messaging capabilities (ie: if a new message comes in right when you click on a link in the system, when the new page loads you will see the message that appeared as the page was being reloaded). 3) Follows your window focus. If you have multiple tabs open in the CRM, you will only get new messages and status messages in the focused window. All messages are cached when there is no focus on a CRM window. 4) Alert/Event messages. An "MSN like" status box that appears at the bottom of your browser to alert about new emails, voicemails, incoming calls, etc. It has pretty effects to make it slide in and out for alerts :). 5) "User is typing" status messages. 6) Email messages from either periodic checks via JSON or can also be injected via scripts. (Ie: incoming emails to helpdesk at domain.com could be announced to users x,y and z) 7) Simple CommSystem.php and CommSystem.js classes to manipulate the alerts and chat system. CommSystem.js is wrote to follow prototype standards as much as I could get it to. ToDo: 1) Finish the group IM feature. 2) Lots of ugly, needs UI work. 3) Support Portal integration ("Chat with Live Help" links in the portal) 4) Message archives so that old messages can be deleted from the CRM (maybe a monthly cron script to backup and delete the messages from the DB). 5) Asterisk AGI Script and SOAP functions to inject Voicemail or Incoming call alerts 6) Cron scripts to populate email alerts? 7) Fix annoying bugs (Ie: '\n\r' breaks sending messages) 8) Internationalization 9) Test, test, test 10) Jabber connector? Drawbacks to this system: 1) Makes a request to the server every N milliseconds to check for new messages, alerts or status updates. This gets heavy on the server. One way to take load off the server is with the focus tracking mentioned above. Un-focused windows will not make requests back to the server. Another way is to create a decay timer like the one used in the prototype Ajax.PeriodicalUpdater() class. This basically checks the last output status and compares it to the current output status. If they are the same then N = (N*) and if the current output status is diff than the last output status N=(N). 2) The whole system is one large timer loop and global references to the CommSystem.js class have to be created to access the class within the loop. This is a memory usage issue but shouldn't be too noticeable for most. 3) Probably a 70% client side and 30% server side system. Thats a lot of javascript. If you get a chance to check it out, let me know what you think and if you'd like to see something like this in vt5 going forward. Matt From mmbrich at fosslabs.com Sat Jul 8 00:15:14 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 22:15:14 -0600 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com In-Reply-To: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> References: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Message-ID: <1152332114.32174.40.camel@localhost.localdomain> On Thu, 2006-07-06 at 22:28 -0700, Richie wrote: > Hi! > > Is the vtiger-demo.fosslabs.com updated with the bleeding edge code > please? I updated it the day RC1 came out but haven't since then. It is currently not automated. > Matt, I guess, we are putting a lot of stress on you alone and it is not fair. > Do you think you require some guys from the community to assist you? > > My main concern is that not any single individual be overloaded. vtiger is team-work and > it should be that way. Everyone should prosper. The workload isn't too bad yet but any help is more than welcomed! > Dedicated volunteers please raise their hands! Matt From richie at vtiger.com Mon Jul 10 08:36:35 2006 From: richie at vtiger.com (Richie) Date: Mon, 10 Jul 2006 05:36:35 -0700 Subject: [Vtigercrm-developers] move to trac-0.9.6 Message-ID: <10c58706195.1364243099676550119.-2686427800793695304@@vtiger.com> Hi! Anyone game to help us move to trac-0.9.6 so that we can utilize the latest and greatest features? Matt, send me a mail with the access to the machine. Also let me know what steps to follow to upgrade. If no one does it, I will have it done. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/cc4fdd2a/attachment-0001.html From mmbrich at fosslabs.com Mon Jul 10 17:09:03 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 15:09:03 -0600 Subject: [Vtigercrm-developers] UI help Message-ID: <1152565743.32174.120.camel@localhost.localdomain> In case no one noticed in the past I suck @ UI design so I figured we would see who wants to step up to the plate on this one. Right now I need the following things, if you want to take one just say so that way no one else duplicates your work. 1) De-Duplication system for settings module. I want this to be able to delete/merge/etc records that can be matched based on certain criteria. I'll write the search engine and logic system to merge/de-dup if someone wants to take on the UI :). I was thinking about having this work in steps. Step 1: select search criteria. Step 2: display duplicate results that are candidates for merge/delete, un-select records from the list via checkbox. Step 3: Select fields to merge or other action to take (delete). Step 4: Execute actions. There was a bounty on this in the forums. If that pans out you'll get a chunk, let me know what you think is fair for your time/effort. 2) Geolocation/Action tracking for email campaigns. This will be a simple popup window that should show a list of the commands from that email (ie: open, followed link, unsubscribed, etc) in one html tab and then the google map to show the actual locations those commands were executed at in another tab. Most likely I will just push one XML descriptor up to google maps to display the country/state/town the email was opened in, but I want to be able to push multiple XML descriptors to google in cases where more than one location is tracked. These extra descriptors can be used to mark possible forwards for that email. Along with this feature we'll need a simple settings area to input your google maps key. 3) Default email unsubscription page. This is a simple page that is visited when a user clicks on the 'unsubscribe' link in emails. The page should have a nice header, a hello message or something, give the user a choice to unsubscribe from that campaign or from all lists in the CRM and then display a success or failure message depending on the result from the CRM's attempt to remove them. If the unsubscribe fails the page should display the company info from the DB so that the user can write in or call to have their information removed. 4) Workflow module? I thought I saw a post that the vtiger crew was going to take this on. If thats the case then this one is void and we don't need to worry about it. Otherwise, go check out the bounty, let me know what you think is a fair cut for your work, then submit me your ideas. If the bounty pans out you'll get a cut of course. 5) Communications system. This is built and ready enough for beta. I need a p2p chat window, group chat window, right hand 'slider' (to show who is online, etc) and we should probably do something with the alert slider as well, it's very plain. The fun part about the chat windows is that none of them are built with HTML so you'll have to do most of the design in CSS. You can also look into the scriptaculous Builder() function for more info on how I create the chat windows, there is flexibility in how you can design them so you're not necessarily restricted to css only. Also could use a chat window for the customer portal if you're up to it :). 6) Direct Mail Designer. This is still on the drawing board but it would be super cool. The idea is to have a list of templates in the "Direct Mail" campaigns that could be merged with the campaign records. Sounds familiar right? Well it would build off of the current merge system by allowing .rtf and .odt files to be merge templates but would also make use of a 'packaging' standard. Basically this packaging (a tarball or zip file) would have a templatename.xml file that would have things like params and thumbnail images and other useful information for merging, etc. This has the ability to have services packaged around it (like we could define an API for designers to make their designs available for pre-set prices and also printing companies to actually do the printing.) Lots of possibilities, if you decide this one is interesting, email me on or off list and we can start a discussion about how this could work. This is candidate for a forge project so if there is enough interest I might just open one. All of this stuff is being created in my branch. I'll give you access to my sandbox area on vtiger-demo.fosslabs.com so you can track stuff and help out. I have every intention of doing these myself if no one takes them, but I can say that I have no skill in UI design whatsoever :). Matt From mmbrich at fosslabs.com Mon Jul 10 23:58:53 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 21:58:53 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590333.16985.2.camel@localhost.localdomain> This is an example screen of what I would like to do for managing campaign actions. If there is a way to tell the campaign type, even when using a diff language or changing the picklist, then I wouldn't have to show every single action. Opinions? Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-24.png Type: image/png Size: 66134 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/86b7c2be/attachment-0001.png From mmbrich at fosslabs.com Tue Jul 11 00:02:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 22:02:49 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590570.16985.4.camel@localhost.localdomain> Here is a screenie of the current comm system if anyone wants to give suggestions. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-25.png Type: image/png Size: 77505 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/854ed82e/attachment-0001.png From dgrant at accuratetechnologies.com Tue Jul 11 14:12:38 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 11 Jul 2006 14:12:38 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG From jtk at yahoo.com Tue Jul 11 17:12:32 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Tue, 11 Jul 2006 17:12:32 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone From sergiokessler at gmail.com Tue Jul 11 18:37:23 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 11 Jul 2006 19:37:23 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> dennis, On 7/11/06, Dennis Grant wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak From mmbrich at fosslabs.com Tue Jul 11 21:58:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 19:58:10 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <1152669490.16985.122.camel@localhost.localdomain> > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt From mmbrich at fosslabs.com Wed Jul 12 00:06:12 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:06:12 -0600 Subject: [Vtigercrm-developers] 5.x webmail changes Message-ID: <1152677172.16985.144.camel@localhost.localdomain> I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt From mmbrich at fosslabs.com Wed Jul 12 00:20:56 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:20:56 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152590570.16985.4.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> Message-ID: <1152678056.16985.149.camel@localhost.localdomain> I'm going to keep posting these hoping that someone will finally get fed up with the ugly and help out ;). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-26.png Type: image/png Size: 90999 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-27.png Type: image/png Size: 67631 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-28.png Type: image/png Size: 90831 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0005.png From saint at vtiger.com Wed Jul 12 02:09:35 2006 From: saint at vtiger.com (Saint) Date: Wed, 12 Jul 2006 11:39:35 +0530 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152678056.16985.149.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> Message-ID: <44B4921F.8020402@vtiger.com> Matt.. I am aware that, the campaigns module is fairly attended in the UI front. I am in the middle of other works. So give me a few more days.. I will hop in and check it out :-) -Saint Matthew Brichacek wrote: > I'm going to keep posting these hoping that someone will finally get fed > up with the ugly and help out ;). > > Matt > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90999 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0009.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 67631 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0010.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90831 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0011.png From dgrant at accuratetechnologies.com Wed Jul 12 09:41:28 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 12 Jul 2006 09:41:28 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) { bar; } vice if ($foo) { bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG From sergiokessler at gmail.com Wed Jul 12 09:48:28 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Wed, 12 Jul 2006 10:48:28 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From jtk at yahoo.com Wed Jul 12 10:06:57 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Wed, 12 Jul 2006 10:06:57 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). From mmbrich at fosslabs.com Wed Jul 12 11:16:41 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:16:41 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <1152717401.16985.280.camel@localhost.localdomain> On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt From mmbrich at fosslabs.com Wed Jul 12 11:48:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:48:52 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <1152719332.16985.289.camel@localhost.localdomain> I have started doing the query part as I run into them in my branch. I'm also moving the query strings out of functions like get_leads() and putting it in get_related_leads_query() instead. This way the query can be used for other things.. like for example if you want mostly the same output of get_leads() but without the HTML that manged to find its way out of the presentation layer and into the data layer... don't get me started on that. Anyways, with the HUGE db query strings that are used in the system, breaking them into separate short lines is a great suggestion for manageability and if it makes merges easier it's like getting your cake and eating it too :). Matt On Wed, 2006-07-12 at 10:06 -0400, Jeff Kowalczyk wrote: > Dennis Grant wrote: > > Actually, I think with VTiger you are going to see a lot of private > > forks, because individual businesses have their own needs and wants that > > are supersets of core VTiger functionality that simply don't apply to > > other businesses. > > This is one of the reasons why I care about making the source more > merge-friendly (particularly short, vertically formatted SQL statement > string lines). > > If we can get the codebase to the point where branching and merging is a > manageable burden, customization branches have a fighting chance to be > maintained in the repository. Or use a distributed repository such as > bazaar-ng can be used (bzr has a trac backend now). > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 13:16:13 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 11:16:13 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <44B4921F.8020402@vtiger.com> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> <44B4921F.8020402@vtiger.com> Message-ID: <1152724573.16985.290.camel@localhost.localdomain> Gracias, in the mean time I will keep working on the back-end and breaking stuff. Matt On Wed, 2006-07-12 at 11:39 +0530, Saint wrote: > Matt.. > > I am aware that, the campaigns module is fairly attended in the UI > front.I am in the middle of other works. So give me a few more days.. > I will hop in and check it out :-) > > -Saint > > > > > Matthew Brichacek wrote: > > I'm going to keep posting these hoping that someone will finally get fed > > up with the ugly and help out ;). > > > > Matt > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > ____________________________________________________________________ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 23:39:08 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 21:39:08 -0600 Subject: [Vtigercrm-developers] vtiger.fosslabs.com maint Message-ID: <1152761948.16985.311.camel@localhost.localdomain> I am going to shut the vtiger.fosslabs.com machine down this weekend for hardware upgrades. When I bring it back up I plan to snapshot and upgrade SVN. Expect the access to the system to be spotty over the weekend. I am tentatively scheduled to do the work on Saturday evening @ 11PM MST but that may change depending on other upgrades being done at the same time. Matt From richie at vtiger.com Thu Jul 13 04:43:03 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:43:03 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670da880.830325448603459473.-9072372394275150906@@vtiger.com> Hi DG! Your comments are well taken. These will be in place at the earliest. I know that this will be a quick fix but instructions have been sent across to have the code properly commented from now on for any future development/bug fixes. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/488cba6b/attachment-0001.html From richie at vtiger.com Thu Jul 13 04:44:36 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:44:36 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670f131a.7768422503650913231.-7005067799642887197@@vtiger.com> I am game for it . Any takers? What is the procedure and how do we guarantee that there are no breakages? Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f2aae45a/attachment-0003.html From richie at vtiger.com Thu Jul 13 04:46:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:46:05 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <10c67107064.-1678188602298141788.6045287401021222103@@vtiger.com> I second /sak. Contribute your code and we will have it in the 4.2.x branch and then have it subsequently ported to the 5.x too. We could have done it much earlier but it is far too late to get any contributions into 5.x at this stage. As far as possible, keep your changes in separate files so that they can be function invoked from the core code. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- dennis, On 7/11/06, Dennis Grant <dgrant at accuratetechnologies.com> wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/8bd60cb5/attachment-0001.html From richie at vtiger.com Thu Jul 13 04:49:51 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:49:51 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <10c6713e13e.2152742122979094039.4943172801070965118@@vtiger.com> I agree with Matt. We have just started to work on a API-basis. The APIs will be difficult to use initially no doubt. I expect the APIs to be APIs like by 5.2 only as it is a huge change in mindset. Moreover, whatever APIs we have now, have to be properly documented and made much more usable. Matt has pointed out quite a few lacunaes and I do assure you that we do intend to fix them. Guidance and direction on the implementation toward achieving the same are welcome. To all System Integrators, yes, I do understand your pain. But, please understand getting rid of legacy code is much easier said than done. As of now, we will have to live with what we have. Post 5.0, we will make appropriate changes. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/889d7c68/attachment-0003.html From richie at vtiger.com Thu Jul 13 04:51:01 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:51:01 -0700 Subject: [Vtigercrm-developers] 5.x webmail changes In-Reply-To: <1152677172.16985.144.camel@localhost.localdomain> References: <1152677172.16985.144.camel@localhost.localdomain> Message-ID: <10c6714f425.4775035562108243105.2718638484930626999@@vtiger.com> No probs Matt. If it does not work, let us give what works the best way we can. We will revisit this later. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/23b5e029/attachment-0001.html From richie at vtiger.com Thu Jul 13 04:54:53 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:54:53 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c67187bff.-5041963494012382301.4384583989565056693@@vtiger.com> I take all your comments with eyes closed. Kindly expect the changes asap. Please do refer to my prev mail. Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless. So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now. The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) {  bar; } vice if ($foo) {  bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/6f714b17/attachment-0003.html From richie at vtiger.com Thu Jul 13 04:56:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:18 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <10c6719c9f2.-6173366446330663734.-8914245299430889257@@vtiger.com> Well, well, /sak, hold on! We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)! Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/609744b4/attachment-0001.html From richie at vtiger.com Thu Jul 13 04:56:58 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:58 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c671a6747.4209201887890377357.8473992930050161702@@vtiger.com> Ok Jeff. This is new to me. Guide me on this. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/1901e1ee/attachment-0003.html From richie at vtiger.com Thu Jul 13 04:58:39 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:58:39 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152717401.16985.280.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> <1152717401.16985.280.camel@localhost.localdomain> Message-ID: <10c671bf103.1188771339393133750.-7786000437306059540@@vtiger.com> I agree with you Matt. I will post a separate mail to have the private forkers to have their codes submitted for integration to whichever trunk needed. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/dca318ca/attachment-0001.html From richie at vtiger.com Thu Jul 13 06:46:19 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 03:46:19 -0700 Subject: [Vtigercrm-developers] Calling all private 4.x development owners Message-ID: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Hi! This is a call to all the 4.x private development owners. Many of you would have been working on your own version of vtiger as you would have customized it to your own needs. This is a call for those guys. The intent is to aggregate most of the common features that you have built and have them integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch or even in the 5.x branch as needed by the community. Pros: By doing the above, you will be able to be in sync with the latest and greatest developments happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a read as one would think of but we are working on it. Yesterday we had comments about the code not being properly commented, we are working on that right now even as I type this post. So, the idea I am conveying is that we are not perfect but are listening to the comments and taking actions too. Hence, please do keep the faith. Cons: By maintaining your own code bases, you lose out on the community benefits like identifying bugs, feature integration, new ideas, etc. We welcome your contributions. Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise the folly. Let us get on with it and make vtiger a success. I have learnt from my past mistakes. Join the team, come on board. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/65c2edda/attachment-0003.html From dgrant at accuratetechnologies.com Thu Jul 13 10:47:52 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 10:47:52 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... Yeah, but is it worth it? The 4.x codebase is really - sorry guys, I don't mean to take shots at you - but let's face it; it's really very nasty. Some of it is a good deal better than others... but there are three or four different coding paradigms all mixed together just on database queries alone, never mind display models and modularity and whatnot. It *works* great, but it's a serious bitch to maintain. As I mentioned earlier, I haven't looked at the 5.0 codebase, but it is my hope and expectation that it is a lot better. > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, No kidding.... > and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > I mean, if you are going to fork, then fork in all it's glory... Dude, I *NEVER* wanted to fork. I'd be *MUCH, MUCH* happier if I could run a vanilla install of VTiger with zero custom code in it. I was forced into forking by a lack of response from the core dev team, yes - but more so by the fact that I had users who wanted features and I needed to get them done NOW. > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Ahem. I tried to get patches into the core. I tried to get the dev team to do stuff by reporting bugs and providing detailed debug info. But there are limits as to how much time in a day I can burn trying to get an unresponsive dev team to fix my bug. "Why is this still broken?" "Well, I reported it to VTiger last month, and they haven't fixed it yet....." That just doesn't cut it. > My point was that we should find > a way to welcome these wayward forks back to the fold. How? I dunno.. Well, the way I'm going to do it is to roll all my features into 5.0 (which is a huge job, but so it goes) and then cut a patch set for merging into the main core. My expectation is that VTiger's version of Linus (or Alan Cox, or whoever) will then go through the patch set, and then either merge or reject patches based on merit - just like in the kernel. I will then work on trying to address concerns with my rejected patches, so as to get them accepted, except in cases where the patch is clearly local in scope - and those I will maintain myself. BTW, who is the local Linus? > So after the wind clears.. my point really comes down to getting all > these folks who are working on private forks to come back to the > community project, regardless of their justification (or lack of) for > the fork. In an OSS project your most valuable resource is your > developers and if we can find a way to get them back it will be well > worth it IMHO. I agree - and the best way to do that is to be RESPONSIVE. I understand that *my* problem may not be the top priority. I understand that core dev team members are NOT going to just drop everything and look after me. But I *do* expect a response, and to get into the pipeline, and to be given reasonably regular status updates on the status of my problem. And if I submit a patch, I expect it to be reviewed and either accepted or rejected in a reasonable timeframe. I don't know how many of you were/are involved in Linux kernel development, but I used to get help from people like Alan Cox and Linus on a regular basis. If a particular bit of hardware wasn't working, and it looked like a bug in Linux kernel code, we'd trade emails on a daily basis to debug the problem. That's the level of service we're talking about. And this is a good start: > Your comments are well taken. These will be in place at the earliest. > I know that this will be a quick fix but instructions have been sent > across to have the code properly commented from now on for any future > development/bug fixes. Thanks! DG From sergiokessler at gmail.com Thu Jul 13 11:40:25 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Thu, 13 Jul 2006 12:40:25 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> Message-ID: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak From allan.bush+vtiger_dev at gmail.com Thu Jul 13 11:59:48 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Thu, 13 Jul 2006 08:59:48 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From dgrant at accuratetechnologies.com Thu Jul 13 12:10:09 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 12:10:09 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CD8@exch.accuratetechnologies.com> > > BTW, who is the local Linus? > unfortunely, there is no local linus, Who is in charge of V5? Who is the core dev team leader? > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) Uh... thanks, but I'm going to have to pass. At this point, with V5 (seemingly) approaching completion, V4 is a dead end. I intend to move forward on V5 and get away from V4 as fast as I can. DG From jeri at vtiger.com Thu Jul 13 21:04:37 2006 From: jeri at vtiger.com (Jeri John) Date: Thu, 13 Jul 2006 18:04:37 -0700 Subject: [Vtigercrm-developers] Latest Docs updated Message-ID: <10c6a904f47.6172353167700401689.-5432537231218327818@@vtiger.com> Dear team, The latest Docs for vtigerCRM 5.0 beta 2 is updated, and it is available in the following url. http://vtiger.com/products/crm/phpdocs/index.php Thanks & Regards, Jerry. ------------------------------------------ D.Jeri John Skype: jerijohn_vtiger Toll Free: +1 877 788 4437 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f9eb2259/attachment-0001.html From mmbrich at fosslabs.com Thu Jul 13 21:16:45 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 19:16:45 -0600 Subject: [Vtigercrm-developers] Custom fields for activities Message-ID: <1152839806.16985.560.camel@localhost.localdomain> Does anyone have plans to implement custom fields in the activities module? Matt From mmbrich at fosslabs.com Thu Jul 13 22:16:38 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 20:16:38 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <1152843399.16985.611.camel@localhost.localdomain> I have some ideas for cleaning up the structure of vtiger as we move forward. I am just going to lay them out here, let me know what you think. My basic idea comes down to writing wrapper classes that are used to abstract most of the unnecessary functions from developers and instead provides a uniform API to access modules, permissions, input, etc. The idea comes in three pieces. Common UI classes, most of which is already done with the new UI. A "mainframe" engine similar to the joomla $mainframe. And last but certainly not least is an entity engine that would abstract most of the entity details from developers and truly provide the unified API. Lets start with the big one, Entity Engine: The entity engine would be accomplished in three steps. The first step is to move all common variables and functions into the EntityEngine class (which extends CRMEntity). The entity engine would go into the DB to populate these with the correct info. For example tab_name, tab_name_index and all the other most common variables would be stored in the db and populated when the entity engine has a request for that module. The next step would be to create common set of functions in this class that would be exposed to the developer. The initial functions I can think of are things like get/set functions for different field values, etc. The last step to the entity engine would be an XML install system. If a developer came along and wanted to create a simple data collection module, like the current campaigns module, they would simply create an XML file that defines all the fields to be displayed, what relationship types are allowed, etc. The entity engine would then create the correct tables, populate the needed tables for the entity engine (the ones holding tab_name, etc) and register the new entity type with the system. This leads into the UI system because if the developer is just creating the XML file, how are common views displayed (list, detail, edit, relatedlists)? The UI system would be a set of classes to extend smarty and again abstract the gory details of the internal workings from the developer. VTigerUI::DetailView($entity) would follow a flow: 1) Display all common elements (header, etc): $this->createTigerHeader(); 2) Display the common 2 tab display for edit/detail/related views $this->getCommonUI("DetailView"); 3) Create a block for each block type in the DB, and create the fields for it as well. $this->assign("NUM_BLOCKS",sizeof($entity->blocks)); foreach($entity->blocks as $blockid=>$fields) { $block_fields = array(); foreach($fields as $fieldname=>$field_data) { $block_fields = $this->CreateEditField($fieldname,$field_values); // creates new edit fields based on uitype and returns an array as $array[sequence_number] = "HTML output" } $this->assign("BLOCK_".$blockid,$this->addBlock($blockid, $block_fields)); } 4) Display data :) And just like magic, the ListView, DetailView, EditView and CallRelatedList files can all go away and these common views can be managed in a much easier way. Next, the mainframe. In joomla (as far as I understand) the mainframe is meant to handle all GET, POST, REQUEST and SESSSION variables and it also sanitizes that input before giving it to the developer ($mainframe->get_input("REQUEST","data")). On top of this it handles some user security and other things. In vtiger I could see it being used for many similar things. Take for example the CreateDetailField() function call above. Inside of this call would be: if($mainframe->is_allowed("Detail",$field->id)) { stuff.. else return; There are still other details to be worked out, but you see that this isn't a _really_ large change for the flexibility it will give you in the system. After it's all said and done you should have two sets of documents that a developer would have access to, the module developers document that would be a document outlining the three pieces discussed above and then the core developer document that would document all the core back-end functions (everything in utils/). Of course there would be a way to overwrite these methods so that developers can still create non-entity based modules (webmails, calendar, rss, etc), but it should make life much easier for module developers who follow the entity structure in vtiger. What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well. Matt From Matjaz.Slak at atol.si Fri Jul 14 02:42:52 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:42:52 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: Hi! If there's no one else, I volunteer to be the v4 Linus. I have the exact same position as a lot of other people wrote about here - basically my own fork of v4.2.3, and I'm now working to get my patches compatible with v4.2.4 so as to get back to the main trunk. And it's a lot of work, which I need to trade with my basic task - which is supporting several customers we have on vTiger. I hope I will have my set of patches (there might be up to 100 of them, as it's looking right now :) ready in a week or so. I belive we as vTiger Dev team should provide more support for 4.2.x stream -> I guess that almost ALL of vTiger's "real world" users use that right now. And they might go for v5 when it's stable, but that won't be (in my experience) for at least 6 months after it's released. If you want me, I'm here. Just give me a direction to start in, and I (and my three colleagues here) can be reviewing submitted work in no time. And discussing it with you the team here to get decissions on include/reject. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Sergio A. Kessler" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:40 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0001.bin From Matjaz.Slak at atol.si Fri Jul 14 02:43:51 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:43:51 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> Message-ID: Hi! Allan, if you need any help, let me know (see my previous post). Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Allan Bush" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:59 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0001.bin From dgrant at accuratetechnologies.com Fri Jul 14 09:24:34 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 09:24:34 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG From allan.bush+vtiger_dev at gmail.com Fri Jul 14 10:32:02 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 07:32:02 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Proper use of a OO design would solves this for both of you. All the common code and default module behavior should be moved into the a set of default classes or "engines" as Matthew is calling them. Then for each module we inherit the classes and make a couple method calls (ideally this is abstracted as well so to create a module all you do is create a class which inherits the base class) which generates the required database actions / html page. If you want something different then the default, like Dennis describes, you simply extent the required method in your inherited class. This way the common code is abstracted and only needs to exist once while the module specific code is in the module for easy modification. The code is already partly structured this way (it's just not used properly). There's already a base class CRMentity which every module inherits from. What needs to be done is to clean up the CRMentity - module relationship so that only methods common to all modules and their default behavior is defined in CRMentity and only things which need to be changed are defined in the module class. Then we need to create a class for each page type (again some of this already exists. ala inculdes/Listview.php, but here it isn't used at all) with the default behaviors of each page type. Now we have an option, either we have each module inherit these page type classes (making changes as needed ala CRMentity) and have a common set of calls to render each page type or we create a SMALL file in each module with a couple of calls to the page type class to render the page and we substitute new functions as needed for customizations. Personally I think the first option here is the better design, but unless you get it right it could become difficult to modify the parts of the page you want without re-witting a lot of the base class (should be avoided at all cost or we're right back in the mess we are in now). That was a bit of a long winded explanation, let me know if anyone requires clarification. On 7/14/06, Dennis Grant wrote: > > > My basic idea comes down to writing wrapper classes that are used to > > abstract most of the unnecessary functions from developers and instead > > provides a uniform API to access modules, permissions, input, etc. > > Oooh. > > > The idea comes in three pieces. Common UI classes, most of which is > > already done with the new UI. A "mainframe" engine similar to the > > joomla $mainframe. And last but certainly not least is an entity > engine > > that would abstract most of the entity details from developers and > truly > > provide the unified API. > > To be honest, I think this is moving in the wrong direction. > > If everybody used the same vanilla VTiger installation, this would make > a lot of sense - one common UI for the entire set of users, and a much > cleaner codebase for developers. Happy happy for everybody. > > Unfortunately, a lot of us are NOT using vanilla VTiger; we have to > customize the application to meet the needs of our user base. And a lot > of the time, our users really really want changes that may seem utterly > trivial from a developer standpoint, but for whatever reason, they > REALLY want it that way. > > And the customer is always right, so we have to do it. > > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. > > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. > > Yes, it makes changing common code more difficult, 'cause now I have to > drill down into each submodule and make the same change over and over > again, and I can certainly see where modularizing and sharing code makes > that job a lot easier. But the assumption it is based on, while true of > a vanilla install, is NOT true in a customized install environment. > > I'd prefer to see every module live in its own subdirectory of the > modules directory, much as is does in 4.x, but more rigorously (ie, > separate Sales Orders from Purchase Orders, don't group them in Orders) > and each module should have its own, atomic codebase. > > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. > > I'd like to see some standardization on the module file structure > though: > > modules/Foo/EditView.php for the edit UI for the module object > modules/Foo/DetailView.php for the detailed view of the object > modules/Foo/Save.php for saving the object to the DB > modules/Foo/CreatePDF.php for creating a PDF version of the object > modules/Foo/UIElements.php for the common UI functions (that are now > stuffed in include/utils.php > modules/Foo/BarPopup.php if there is a popup window to select associated > Bar objects > > etc. > > It makes dealing with modules easier if we know where the various > functions are kept. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From isimpkins at premierrealm.com Fri Jul 14 11:10:32 2006 From: isimpkins at premierrealm.com (Ivar Simpkins) Date: Fri, 14 Jul 2006 17:10:32 +0200 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: Sorry DG this doesn?t wear with me. 'The price of programmability' is what it's about. There is the short term solution and it has its merits, but planning a structured API can only have its long term benefits. Where does vTiger want to be in the future, this has to be answered. If it wants to be in the top ratings, then I think every effort has to be made, to reconsolidate and then plan for the future. Sure the learning curve is steep but the rewards are enormous. Would it not be better to prefect a generic function, in an OO structure which does all you want, one entrance, one exit and away you go. A well documented code base that automatically builds your API documentation gives you a valuable toolbox, now concentrate the communities efforts on pulling together and raising the lowest common denominator and you have a work the progresses moving a an incredible rate. And as Matt said: 'What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well.' NO, you are not nuts, it gives you the long term ability to use ones creativity to best avail without (always) having to worry about the nuts & bolts. I think this is a courageous step in the right direction, where, after surviving the learning curve, all will benefit, creating a homogeneous standardised kernel, with the ability of Plug 'n Play ala Joomla and probably much more. 'The price of programmability' is high but seeing the caliber of work produced so far, I am convinced Matt is on the right track to creating a new dimension in CRM. Please excuse the tone but its hard to see the same mistake been made over and again. Ivar > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 From mmbrich at fosslabs.com Fri Jul 14 12:54:21 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:21 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Message-ID: <1152896061.16985.648.camel@localhost.localdomain> On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > Proper use of a OO design would solves this for both of you. > > All the common code and default module behavior should be moved into > the a set of default classes or "engines" as Matthew is calling them. > Then for each module we inherit the classes and make a couple method > calls (ideally this is abstracted as well so to create a module all > you do is create a class which inherits the base class) which > generates the required database actions / html page. If you want > something different then the default, like Dennis describes, you > simply extent the required method in your inherited class. This way > the common code is abstracted and only needs to exist once while the > module specific code is in the module for easy modification. I think we're right on the same page here, but if you take for example the Campaign.php class, it should not be needed. All of the functions and variables it defines are generic and do not need to be re-created for each module that does simple data collection and display. If you want to write a module that does more than this, and will need it's own class, by all means, extend the EntityEngine class (or CRMEntity if it becomes the engine) and then continue on your way. > > The code is already partly structured this way (it's just not used > properly). There's already a base class CRMentity which every module > inherits from. What needs to be done is to clean up the CRMentity - > module relationship so that only methods common to all modules and > their default behavior is defined in CRMentity and only things which > need to be changed are defined in the module class. But even things that need to be changed, may not need to be changed and defined in separate module classes. For example all the get_leads, get_contacts, etc functions can be standardized and instead use a set of DB keys to track relationship_types allowed for a module. function get_leads($id,$entity) { if($this->is_relationship_type($entity->module,"Leads")) { stuff.. } else return false; } > Then we need to > create a class for each page type (again some of this already exists. > ala inculdes/Listview.php, but here it isn't used at all) with the > default behaviors of each page type. Now we have an option, either we > have each module inherit these page type classes (making changes as > needed ala CRMentity) and have a common set of calls to render each > page type or we create a SMALL file in each module with a couple of > calls to the page type class to render the page and we substitute new > functions as needed for customizations. Personally I think the first > option here is the better design, but unless you get it right it could > become difficult to modify the parts of the page you want without > re-witting a lot of the base class (should be avoided at all cost or > we're right back in the mess we are in now). Correct, and I think if you created the correct UI classes you could very easily overwrite the functions you want to customize and _only_ the functions you want to customize (like AddBlock() for example). > That was a bit of a long winded explanation, let me know if anyone > requires clarification. I think we're pretty close to being in the same school of though but maybe I needed to explain my thoughts in a bit more detail. I really just laid out a very high level overview of what I think should be done. Matt From mmbrich at fosslabs.com Fri Jul 14 12:54:58 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:58 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <1152896098.16985.650.camel@localhost.localdomain> > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. So in these cases you could over-ride the system DetailView by creating /Accounts/DetailView.html.php for your actual HTML stuff, and /Accounts/Detailview.php if you want to change the logic flow. If you are only changing the look/feel, then re-declare the AddBlock() function with your new special sauce inside of it and off you go. > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. See above, the correct separation of these layers in the system can still give you the flexibility you need. > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > To create new field types it would just be a matter of creating a new UIType, populating the DB fields you want to have that uitype (via XML), and then creating the base HTML for it in the UIType.tpl file. {if {$uitype} == "230"} your_new_html {/if} On top of this you could just over-ride the system UI creator and replace it with your own display classes. > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. I actually think the entity engine will need to have a query builder in it so that the queries can be built dynamically depending on the type of data you are going for. A true entity engine (like the one in ofbiz.org) will not ever let you see a query, nor should you need to if the entity engine is doing it's job correctly. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. i hate utils.php :). But the examples you lay out above would not at all be impossible. You would simply tell the entity engine (via an XML file) that you want a seqno and header value assigned to each entity of type=Quotes, and then in the query builder it will check for seqno and if it find it, ORDER BY seqno will be appended to the query string. Really what I am trying to accomplish is to make your life easier in the long run than what it currently is, even when diverging from the standard way of doing it with-in vtiger. There is a learning curve that will come along with this but correct documentation and developer support via this mailing list should help you get past any of that. Matt From allan.bush+vtiger_dev at gmail.com Fri Jul 14 13:13:28 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 10:13:28 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <1152896061.16985.648.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> Message-ID: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> I'm pretty sure we're on the same page Matt, my reply was more of an attempt to convince Dennis then an attempt to disagree with anything you said. In your example though I'm not sure how much I like having a function called "get_leads" in the base class. I think there's way too much coupling between "modules" right now and I'd like to get away from that, however I'm not sure what the best way to do that is without losing any of the control we currently have. That's probably another discussion though. I agree with your design, I could probably argue all day over the implementation of the details, but as long as it's constant and logical I don't care too much. On 7/14/06, Matthew Brichacek wrote: > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > Proper use of a OO design would solves this for both of you. > > > > All the common code and default module behavior should be moved into > > the a set of default classes or "engines" as Matthew is calling them. > > Then for each module we inherit the classes and make a couple method > > calls (ideally this is abstracted as well so to create a module all > > you do is create a class which inherits the base class) which > > generates the required database actions / html page. If you want > > something different then the default, like Dennis describes, you > > simply extent the required method in your inherited class. This way > > the common code is abstracted and only needs to exist once while the > > module specific code is in the module for easy modification. > I think we're right on the same page here, but if you take for example > the Campaign.php class, it should not be needed. All of the functions > and variables it defines are generic and do not need to be re-created > for each module that does simple data collection and display. > If you want to write a module that does more than this, and will need > it's own class, by all means, extend the EntityEngine class (or > CRMEntity if it becomes the engine) and then continue on your way. > > > > > The code is already partly structured this way (it's just not used > > properly). There's already a base class CRMentity which every module > > inherits from. What needs to be done is to clean up the CRMentity - > > module relationship so that only methods common to all modules and > > their default behavior is defined in CRMentity and only things which > > need to be changed are defined in the module class. > But even things that need to be changed, may not need to be changed and > defined in separate module classes. For example all the get_leads, > get_contacts, etc functions can be standardized and instead use a set of > DB keys to track relationship_types allowed for a module. > function get_leads($id,$entity) { > if($this->is_relationship_type($entity->module,"Leads")) { > stuff.. > } else > return false; > } > > > Then we need to > > create a class for each page type (again some of this already exists. > > ala inculdes/Listview.php, but here it isn't used at all) with the > > default behaviors of each page type. Now we have an option, either we > > have each module inherit these page type classes (making changes as > > needed ala CRMentity) and have a common set of calls to render each > > page type or we create a SMALL file in each module with a couple of > > calls to the page type class to render the page and we substitute new > > functions as needed for customizations. Personally I think the first > > option here is the better design, but unless you get it right it could > > become difficult to modify the parts of the page you want without > > re-witting a lot of the base class (should be avoided at all cost or > > we're right back in the mess we are in now). > Correct, and I think if you created the correct UI classes you could > very easily overwrite the functions you want to customize and _only_ the > functions you want to customize (like AddBlock() for example). > > > > That was a bit of a long winded explanation, let me know if anyone > > requires clarification. > I think we're pretty close to being in the same school of though but > maybe I needed to explain my thoughts in a bit more detail. I really > just laid out a very high level overview of what I think should be done. > > Matt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From mmbrich at fosslabs.com Fri Jul 14 13:18:54 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 11:18:54 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> Message-ID: <1152897535.16985.654.camel@localhost.localdomain> On Fri, 2006-07-14 at 10:13 -0700, Allan Bush wrote: > I'm pretty sure we're on the same page Matt, my reply was more of an > attempt to convince Dennis then an attempt to disagree with anything > you said. > > In your example though I'm not sure how much I like having a function > called "get_leads" in the base class. I think there's way too much > coupling between "modules" right now and I'd like to get away from > that, however I'm not sure what the best way to do that is without > losing any of the control we currently have. That's probably another > discussion though. I'm not a big fan of how this is done either but you're right, this falls into another discussion about how to clean up current practices going forward with a new structure. > > I agree with your design, I could probably argue all day over the > implementation of the details, but as long as it's constant and > logical I don't care too much. Plenty of details that are yet to be worked out ;). Matt > > > On 7/14/06, Matthew Brichacek wrote: > > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > > Proper use of a OO design would solves this for both of you. > > > > > > All the common code and default module behavior should be moved into > > > the a set of default classes or "engines" as Matthew is calling them. > > > Then for each module we inherit the classes and make a couple method > > > calls (ideally this is abstracted as well so to create a module all > > > you do is create a class which inherits the base class) which > > > generates the required database actions / html page. If you want > > > something different then the default, like Dennis describes, you > > > simply extent the required method in your inherited class. This way > > > the common code is abstracted and only needs to exist once while the > > > module specific code is in the module for easy modification. > > I think we're right on the same page here, but if you take for example > > the Campaign.php class, it should not be needed. All of the functions > > and variables it defines are generic and do not need to be re-created > > for each module that does simple data collection and display. > > If you want to write a module that does more than this, and will need > > it's own class, by all means, extend the EntityEngine class (or > > CRMEntity if it becomes the engine) and then continue on your way. > > > > > > > > The code is already partly structured this way (it's just not used > > > properly). There's already a base class CRMentity which every module > > > inherits from. What needs to be done is to clean up the CRMentity - > > > module relationship so that only methods common to all modules and > > > their default behavior is defined in CRMentity and only things which > > > need to be changed are defined in the module class. > > But even things that need to be changed, may not need to be changed and > > defined in separate module classes. For example all the get_leads, > > get_contacts, etc functions can be standardized and instead use a set of > > DB keys to track relationship_types allowed for a module. > > function get_leads($id,$entity) { > > if($this->is_relationship_type($entity->module,"Leads")) { > > stuff.. > > } else > > return false; > > } > > > > > Then we need to > > > create a class for each page type (again some of this already exists. > > > ala inculdes/Listview.php, but here it isn't used at all) with the > > > default behaviors of each page type. Now we have an option, either we > > > have each module inherit these page type classes (making changes as > > > needed ala CRMentity) and have a common set of calls to render each > > > page type or we create a SMALL file in each module with a couple of > > > calls to the page type class to render the page and we substitute new > > > functions as needed for customizations. Personally I think the first > > > option here is the better design, but unless you get it right it could > > > become difficult to modify the parts of the page you want without > > > re-witting a lot of the base class (should be avoided at all cost or > > > we're right back in the mess we are in now). > > Correct, and I think if you created the correct UI classes you could > > very easily overwrite the functions you want to customize and _only_ the > > functions you want to customize (like AddBlock() for example). > > > > > > > That was a bit of a long winded explanation, let me know if anyone > > > requires clarification. > > I think we're pretty close to being in the same school of though but > > maybe I needed to explain my thoughts in a bit more detail. I really > > just laid out a very high level overview of what I think should be done. > > > > Matt > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From nolan at peaceworks.ca Fri Jul 14 13:44:55 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Fri, 14 Jul 2006 13:44:55 -0400 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Message-ID: <1152899095.32568.49.camel@rockcrusher> As one of the mentioned 4.2 developers mostly lurking on this list... Like others have mentioned, I've got 2 classes of modifications: 1. those _I think_ others may be interested in 2. those _I think_ others will not be interested in What I want to know is...is what _I think_ in any way connected with reality? More to the point... How do I know whether or not I *should* submit a given patch to the current tree for 4.2.5? In my previous (though admittedly minimal) exploration, I got the sense that 4.2.x was essentially "feature frozen" and that bug/security fixes and deployment/installation/maintenance stuff were fair game. For myself (and others like me), is 4.2 open for new features? If so, should we just continue to take it on ourselves to self-select those things _we think_ are more universal in nature? Should we try the shotgun approach (submit everything to 'Code Contributions' and see what gets picked up)? Is there a "proper place" to provide a list of changes we've made and give others the opportunity to speak for/against including them (or give a 'vTiger Linus' the opportunity to accept/reject them)? I think once I have a clear idea of how best to contribute, particularly to 4.2, I'll be more able to do so effectively. By the way, I think Matt's v5 architecture ideas are great, but they do muddy the waters for me a bit. Seeing those ideas, I have hope that something along those lines may be implemented, but it also makes me question *when* the right time will be to port some of my changes and additions to v5...I'd rather just do it once. peace, nokes On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > Hi! > This is a call to all the 4.x private development owners. > > Many of you would have been working on your own version of vtiger as you would have > customized it to your own needs. This is a call for those guys. > > The intent is to aggregate most of the common features that you have built and have them > integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch > or even in the 5.x branch as needed by the community. > > Pros: > > By doing the above, you will be able to be in sync with the latest and greatest developments > happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a > read as one would think of but we are working on it. Yesterday we had comments about the > code not being properly commented, we are working on that right now even as I type this post. > So, the idea I am conveying is that we are not perfect but are listening to the comments and > taking actions too. Hence, please do keep the faith. > > Cons: > > By maintaining your own code bases, you lose out on the community benefits like > identifying bugs, feature integration, new ideas, etc. > > We welcome your contributions. > > Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise > the folly. Let us get on with it and make vtiger a success. > I have learnt from my past mistakes. Join the team, come on board. > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Fri Jul 14 15:37:08 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 15:37:08 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> > Really what I am trying to accomplish is to make your life easier in the > long run than what it currently is, even when diverging from the > standard way of doing it with-in vtiger. There is a learning curve that > will come along with this but correct documentation and developer > support via this mailing list should help you get past any of that. Except that you're killing me with your good intentions. The life of an integrator doesn't permit steep learning curves and heavy abstractions; there just isn't time to do so. I've got a dozen different systems to get to play together, a boss screaming at me to get this stuff done yesterday, and no time to devote to learning whatever abstraction layer you've decided to implement. And Murphy's Law being what it is, if your abstraction model has one flaw, that will be the thing that my boss wants as his top priority. "Perfect is the enemy of good enough" I don't want "perfect"; I want "good enough" I want to be able to dive into the source and start modifying how the thing works *right now* without having to trace back a billion functions or wrap my brain around your object model. I don't have time to do so, because I'm simultaneously trying to play with a dozen other pieces of the puzzle. Guys, I have been playing this game for a LONG time. I have written major applications to perform mission-critical business functions.(At one time, if my code broke DaimlerChrysler stopped building cars) I have seen and dealt with thousands of software projects, both as a participant and as an observer, and almost without fail, every time somebody sets out to do the "perfect" object-based, extensible, customizable framework, it just leads to tears. I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. If you write code that any decent developer can pick up, find his bearings in a couple of seconds, and then comprehend *without* the benefit of having read the thousand-page project definition in advance, then you are doing well. The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator - because if your code is so illegible (or so heavily abstracted, or has such a steep learning curve, or whatever) that I cannot figure it out on my own in a few minutes and so have to drop everything until I can get some assistance... well then, you've burned up my precious, precious time. That code might be sheer genius. It might be, once you have tackled the learning curve, breathtakingly beautiful. But if I can't just fire up vi and dive in, then it is WRONG. Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. The big problem with the current state of Vtiger 4.x is that it straddles both worlds. There are parts of the code that are fairly straightforward and out in plain sight, and only lack comments to make them "good enough". Then there are parts that want to be object-oriented with an API, but really depend on a couple of heavily-overloaded megafunctions buried deep in the depths of util.php (also uncommented) so you have to play API detective to figure out just what the hell is happening where. And then there's parts of the code that mix both. It'd be SO much easier to maintain if all the code that related to a module (less some *basic* toolkit functions that could reside in a common include) just lived in that module. Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility. DG From dan.means at teamsrs.com Fri Jul 14 16:25:56 2006 From: dan.means at teamsrs.com (Dan Means) Date: Fri, 14 Jul 2006 13:25:56 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <44B7FDD4.4080009@teamsrs.com> I couldn't have said this better than Dennis.... -- Dan Means Mission Viejo, CA www.dkmeansonline.com www.teamsrs.com From crm at email.si Fri Jul 14 17:34:37 2006 From: crm at email.si (Ales Petric) Date: Fri, 14 Jul 2006 22:34:37 +0100 Subject: [Vtigercrm-developers] What's with 4.2.x future ? Message-ID: <44B80DED.4010808@email.si> HI EVERYONE This is my first post to 'vTiger' developers mailing list About me: My native environment is development environment (around C/C++, VB, HTML, CSS, PHP, ASP, Python). My home system environment is 'Linux' based desktop os. like 'Debian' and 'Debian' based (my latest is 'Ubuntu') For my business server system I use 'Debian' stable. Like all I had to do some system tunning and other stuff related for system to work properly and live. I worked for small and big companies, within groups and on solo projects. My favorite project is project that is more to an end oriented that other. I had worked on lost project to but I had learned something from that, hope you to. Project called 'vTIger': Yes, 'vTiger' :), I am working with this great free source project for some time now (let me think back, 1 year and 6 month it is, sounds like my birthday :) Reason is that I am involved with business that uses 'CRM' software and solution for them 'vTiger' was the answer, from me to them :) Yes, it sells good if support is guaranteed and signed in contract (like must be included); Yes what's new :) What is new? That was my question looking 'vTiger' community. Let's get serious. In my business we had implemented over 150 issues, or tickets related, not features. We have less then 10 serious stuff implemented, tested and deployed. I believe, and some of you will confirm that this is big step back for community when stuff is included in 'vTiger' and not updated on live track inside community. As we now, there are many companys that offers hosting with 'vTiger' CRM, and many are just keeping one eye on 4.2.x. I belive that 'vTiger' is under 'GPL' and much more, there is community above that is responsible for maintaining the project. Community: Let's face it. There should be readable state and mission, end oriented leadership, free participation, known business model of 'vTiger CRM', useful documents on-line, tutorials, subgroups with a roles like module manager, testers, and many more beautiful stuff, ..I yes there is many but not enough. I have read that someone was begging not for himself for some other guy that they should give him some type of account that he can post code 'not(anonymous)' Question is. Can community afford that kind of behaviour, that no actions are taken. Many are complaining about non activity that is going on right now. Proposal: Let's build team of project/module managers and sys-admin guys to do some steeps needed to put out htp://new.vtiger.com/ based on latest release of 4.2.x thread. On the same portal if it is possible ? Within the same community if it is possible ? We can invite all existing groups that are using 4.2.x thread and join forces and merge existing sources and fixed issues. We need that, and more we need all help we can get within testing activities that are needed when new release comes out. With future plans of what's included in first build and what in next. Yes we can plan what features and build them in future within subgroups of module managers responsible to finish what was started. 4.2.x future to be when 4.3 and then 5.0, isn't that the way ? If there is comment, I now there is, and I now there is the way we can bring action into 'vTiger' community. What do ya say? Respect, Ales Petric From carylt at gmail.com Fri Jul 14 17:47:03 2006 From: carylt at gmail.com (Caryl Takvorian) Date: Fri, 14 Jul 2006 22:47:03 +0100 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <8075d1e0607141447y1b5a878at5321bb42dafcd01b@mail.gmail.com> Just for the sake of it, let me say that I whole heartedly agree with Dennis. I'm not unfortunately convinced that his (our) opinion will change anything, but I find the arguments truthfully compelling. Caryl On 7/14/06, Dennis Grant wrote: > > > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/02f2875a/attachment-0003.html From mmbrich at fosslabs.com Fri Jul 14 18:29:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 16:29:30 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <1152916171.16985.800.camel@localhost.localdomain> OK, so I am going to highlight and comment on some of my favorite quotes from DG so far, this way when I start ignoring his emails you will all understand why. 1) It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules. This has to be hands-down the stupidest thing I have ever heard in my life and I can't believe that anyone who claims the experience you do actually posts this drivel on a public mailing list. 2) I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. I am utterly convinced that anyone who argues that 95% code similarities in vtiger modules is a "good enough" method is utterly stupid. 3) The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator ... well then, you've burned up my precious, precious time So your 'job' as an OSS systems integrator has never included needing to RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing question on a mailing list? 4) That code might be sheer genius. But if I can't just fire up vi and dive in, then it is WRONG. I'm starting to see the picture now.. you're lazy, and rather than do something about the current problems in the system you are going to whine about it. Sergio was right, my apologies Sergio. 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. I think I've made it clear that simple, concise and logical are all design goals of the system. And you sir have made it clear that you have no intention of helping move this project forward by displaying your willingness to fork instead of work with a _real_ design structure that a _real_ OSS systems integrator would be very happy to have. Matt On Fri, 2006-07-14 at 15:37 -0400, Dennis Grant wrote: > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From brian at awnow.com Fri Jul 14 21:48:13 2006 From: brian at awnow.com (Brian Laughlin) Date: Fri, 14 Jul 2006 18:48:13 -0700 Subject: [Vtigercrm-developers] Poorly written code is poorly written code. Message-ID: <27CABE0A5EFD714EA5B2F9B47EE5CB855BCFA2@svawmc1.awnow.local> 'Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility.' This is not really a fair statement. OO code done well is a gem. The statement above automatically implies that it will be written poorly. OO code, procedure code or a sql query written badly is poorly written code - period. No method can overcome poor coding. It seems reasonable that v5 is about the future, one that creates better code base that is more reusable and it encourages more development talent to improve, iterate and integrate. With some effort I think we can mature this process so that the core product can continue to benefit from the community's contributions. There seems to be a simple fix to the debate that is ensuing. If you want to keep it as it is then support the 4.2.x branch, otherwise help to mature the code for v5. One last comment. There is a large class of developers that don't really care how the code was written or how it works as long as it works and works well. If you can extend its functionality or easily call it when you need it then for the most part they are happy. That doesn't stop those that want to dig deeper and tweak it at that level. More power to you. Regards, Brian Laughlin From mmbrich at fosslabs.com Sun Jul 16 23:31:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 21:31:30 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight Message-ID: <1153107090.5582.9.camel@localhost.localdomain> I wasn't able to get all the upgrades done last night, expect some more spotty access tonight as I try to finish up the list of to-dos Matt From mmbrich at fosslabs.com Mon Jul 17 00:31:29 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 22:31:29 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight In-Reply-To: <1153107090.5582.9.camel@localhost.localdomain> References: <1153107090.5582.9.camel@localhost.localdomain> Message-ID: <1153110689.5582.17.camel@localhost.localdomain> Upgraded SVN to 1.2.3 from backports.org. Let me know if you have problems with it. There is a backup of both the forge repo and the main repo from just before the upgrade. Matt On Sun, 2006-07-16 at 21:31 -0600, Matthew Brichacek wrote: > I wasn't able to get all the upgrades done last night, expect some more > spotty access tonight as I try to finish up the list of to-dos > > Matt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Mon Jul 17 05:18:50 2006 From: crm at email.si (Ales Petric) Date: Mon, 17 Jul 2006 10:18:50 +0100 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <1152899095.32568.49.camel@rockcrusher> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> <1152899095.32568.49.camel@rockcrusher> Message-ID: <44BB55FA.4050909@email.si> Ok As private developer owner of 4.2.x I would like to be involved 'actively' in planning, maintaining and updating the 4.2.x. With what can I contribute: 1- I can bug fix (ticket solve) 2- I can suggest & plan with others what's to be in next release (4.2.X) and help with coding to achieve that 3- I can define groups for managing individual modules (maintainers) that will togather with other involved in 4.2.x deceide what's needed to build as add-on 4- I can do the functional analyse of current 4.2.x and publish .pdf, like system & user help (for developers and others related) 5- I can built three of functionality, like dir structure (for UseCase, TestCase and other related) 6- I can define which ticket/issue goes with X module or X functionality (for quick issue solving and other related) 7- I can help sync with other anonymous/private developers what was solved/debugged and help to merge existing code into next to be released 8 .. and many other stuff that I had have already done and not published...I can decode that for other users... What do I need: 1- Account with permissions to do something, I don't want to be anonymous updater. Now it's 8 vs 1 :( I it would be great to be involved with when to release and what's included in next 4.2.x. Ales Nolan Andres wrote: > As one of the mentioned 4.2 developers mostly lurking on this list... > > Like others have mentioned, I've got 2 classes of modifications: > > 1. those _I think_ others may be interested in > 2. those _I think_ others will not be interested in > > What I want to know is...is what _I think_ in any way connected with > reality? > > More to the point... > > How do I know whether or not I *should* submit a given patch to the > current tree for 4.2.5? In my previous (though admittedly minimal) > exploration, I got the sense that 4.2.x was essentially "feature frozen" > and that bug/security fixes and deployment/installation/maintenance > stuff were fair game. > > For myself (and others like me), is 4.2 open for new features? If so, > should we just continue to take it on ourselves to self-select those > things _we think_ are more universal in nature? Should we try the > shotgun approach (submit everything to 'Code Contributions' and see what > gets picked up)? Is there a "proper place" to provide a list of changes > we've made and give others the opportunity to speak for/against > including them (or give a 'vTiger Linus' the opportunity to > accept/reject them)? > > I think once I have a clear idea of how best to contribute, particularly > to 4.2, I'll be more able to do so effectively. > > By the way, I think Matt's v5 architecture ideas are great, but they do > muddy the waters for me a bit. Seeing those ideas, I have hope that > something along those lines may be implemented, but it also makes me > question *when* the right time will be to port some of my changes and > additions to v5...I'd rather just do it once. > > peace, > nokes > > > > On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > >> Hi! >> This is a call to all the 4.x private development owners. >> >> Many of you would have been working on your own version of vtiger as you would have >> customized it to your own needs. This is a call for those guys. >> >> The intent is to aggregate most of the common features that you have built and have them >> integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch >> or even in the 5.x branch as needed by the community. >> >> Pros: >> >> By doing the above, you will be able to be in sync with the latest and greatest developments >> happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a >> read as one would think of but we are working on it. Yesterday we had comments about the >> code not being properly commented, we are working on that right now even as I type this post. >> So, the idea I am conveying is that we are not perfect but are listening to the comments and >> taking actions too. Hence, please do keep the faith. >> >> Cons: >> >> By maintaining your own code bases, you lose out on the community benefits like >> identifying bugs, feature integration, new ideas, etc. >> >> We welcome your contributions. >> >> Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise >> the folly. Let us get on with it and make vtiger a success. >> I have learnt from my past mistakes. Join the team, come on board. >> >> Richie >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > __________ NOD32 1.1661 (20060714) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f0af863c/attachment-0001.html From sergiokessler at gmail.com Mon Jul 17 09:36:39 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 10:36:39 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak From dgrant at accuratetechnologies.com Mon Jul 17 09:51:45 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Mon, 17 Jul 2006 09:51:45 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG From richie at vtiger.com Mon Jul 17 10:48:07 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:48:07 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> Message-ID: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Hi Team! Let us take a step back and review what is happening. As the case stands, the intent is to provide an ideal vtiger architecture which needs almost everyones needs. It is plain that as of now, there are only 2 "strong/loud" arguments. I am sure you all will agree that both of them are not overly subscribed by any majority yet. Let us get some more ideas- however radical they be- into this list and then we will vote the good ideas in. By being too strongly worded on any particular idea, it will only stop short the other guys to put forth their ideas however miniscule/insignificant that might appear to be. I have myself faced this situations many times and I wish that the same does not happen here. Let us target 2 weeks from today as the time within which we should get all the ideas in. We can always short list as we have quite some experienced hands on board. vtigercrm-5.0.0 will be out within that time. Good to see some emotion here but I am sure we will hold to the rules of basic etiquettes and only wrt the point in concern. Thank You, Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9af843db/attachment-0003.html From richie at vtiger.com Mon Jul 17 10:57:28 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:57:28 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> Message-ID: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/d71cb2dd/attachment-0001.html From richie at vtiger.com Mon Jul 17 11:43:10 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 08:43:10 -0700 Subject: [Vtigercrm-developers] automated tests update Message-ID: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f783fc2f/attachment-0003.html From richie at vtiger.com Mon Jul 17 12:01:27 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:01:27 -0700 Subject: [Vtigercrm-developers] have a go at the demo Message-ID: <10c7d3878ee.-2525705299028808692.-7798707862789036512@@vtiger.com> Dear Team, Kindly have a go at the demo so that we can identify the bugs and fix them. We are planning to freeze taking up any new bug-fixing post this week. Needless to say, if there be any pressing bugs, we will have to re-consider else we stick to this plan. We would like to take into consideration all the bugs that we get by this week alone. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/05c6f7c8/attachment-0001.html From richie at vtiger.com Mon Jul 17 12:04:40 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:04:40 -0700 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 Message-ID: <10c7d3b68c9.-1733958150241885349.-2381377074013605034@@vtiger.com> Ken asked me a question in my blogs about how we can have a better documentation for v5. I honestly do not know if any setup is available which can help us achieve the same other than that of a wiki. Any new ideas are welcome. It will be nice to have a distributed effort on for the documentation as well. Let us get some working backbone for collaborative documentation up and running fast. Any ideas/suggestions? Any experienced documentor on board, please raise hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/effef8f7/attachment-0003.html From richie at vtiger.com Mon Jul 17 12:24:59 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:24:59 -0700 Subject: [Vtigercrm-developers] Help Needed Feature Message-ID: <10c7d4e0030.-6478902657238423422.8728970723888816495@@vtiger.com> Is there any Help Needed feature available in the forge? Ken asked me this and I could not answer the query. Please find the link to the blog post for contextual reference: http://blogs.vtiger.com/weblog_entry.php?p=28125#28125 I think what Ken is referring is to have a more vertically-distributed setup something like Help Needed in Leads Module Bug-fixing Help Needed in Leads Module Docs Help Needed in Leads Module Automation of test cases etc. Matt/Fathi, can we have this for all the projects in the forge please or does it already exist? I just checked the forge and did not find any links. Am I missing something? Probably, we can have a link to the vtigercrm-5.0.0 live source in the vtigerforge too. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/1c9b7dca/attachment-0001.html From richie at vtiger.com Mon Jul 17 12:31:34 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:31:34 -0700 Subject: [Vtigercrm-developers] automated trac registration Message-ID: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9e1e63d7/attachment-0003.html From richie at vtiger.com Mon Jul 17 12:34:57 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:34:57 -0700 Subject: [Vtigercrm-developers] Fwd: error Message-ID: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> ----j.ruisz at ruisz.com wrote ---- ============Forwarded Mail============ >From : j.ruisz at ruisz.com To : richie at vtiger.com Date :Fri, 14 Jul 2006 08:11:36 +0200 Subject : error ============Forwarded Mail============ Hello , trying to test the online demo of vtiger 5 i got this result: *Fatal error*: Call to a member function on a non-object in */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* on line *431* with best regards, mit freundlichen Gr??en, Joachim Ruisz Werbegrafik, Bildagentur, Webagentur Softwareentwicklung Joachim Ruisz A 8940 Liezen +43 664 312 4830 j.ruisz at ruisz.com http://www.ruisz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/332ceeeb/attachment-0001.html From richie at vtiger.com Mon Jul 17 12:35:17 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:35:17 -0700 Subject: [Vtigercrm-developers] Fwd: Translations Message-ID: <10c7d576ed5.6497289794643483356.-5939067564803299625@@vtiger.com> ----webmaster at vtigerfacile.com wrote ---- ============Forwarded Mail============ >From : webmaster at vtigerfacile.com To : richie at vtiger.com Date :Mon, 17 Jul 2006 02:31:42 +0200 Subject : Translations ============Forwarded Mail============ Vanakkam Shankar, i have made a little test for translation. I have added few line in app_strings file. And like for module customview, all dropdown in all editviews (Call/Meeting inclued) are translated. If we can have the same things in listview & detailview, the translation will be perfect, and vtiger 5 can be used in multilang without problem. I want to mention the value of select box is keep in english () Best regards, A?ssa Find the added strings in /include/languages/fr_fr.lang.php below //activities 'Planned'=>'Plannifi?', 'Held'=>'A eu lieu', 'Not Held'=>'N\'a pas eu lieu', 'Medium'=>'Normale', 'Private'=>'Priv?', 'Public'=>'Public', 'Daily'=>'Quotidienne', 'Weekly'=>'Hebdomadaire', 'Monthly'=>'Mensuelle', 'Yearly'=>'Annuelle', 'Completed'=>'Termin?', 'Deferred'=>'Report?', //Campaigns 'Excellent'=>'Excellent', 'Good'=>'Bonne', 'Average'=>'Moyenne', 'Poor'=>'Faible', 'Conference'=>'Conf?rence', 'Webinar'=>'S?minaire', 'Trade Show'=>'Salon', 'Public Relations'=>'Relations Publique', 'Partners'=>'Partenaires', 'Referral Program'=>'Programme', 'Advertisement'=>'Publicit?', 'Banner Ads'=>'Banni?re web', 'Direct Mail'=>'Email direct', 'Email'=>'Email', 'Telemarketing'=>'T?l?marketing', 'Others'=>'Autre', 'Planning'=>'Plannifi?', 'Complete'=>'Termin?', 'Cancelled'=>'Annul?', //Accounts //Industry list 'Apparel'=>'Appareillage', 'Banking'=>'Banque', 'Biotechnology'=>'Biotechnologie', 'Chemicals'=>'Industrie chimique', 'Communications'=>'Communications', 'Construction'=>'BTP', 'Consulting'=>'Conseil', 'Education'=>'Education', 'Electronics'=>'Electronique', 'Energy'=>'Energie', 'Engineering'=>'Engineering', 'Entertainment'=>'Divertissement', 'Environmental'=>'Environnement', 'Finance'=>'Finance', 'Food & Beverage'=>'Agro alimentaire', 'Government'=>'Secteur public', 'Healthcare'=>'Sant?', 'Hospitality'=>'Hopitaux', 'Insurance'=>'Assurances', 'Machinery'=>'', 'Manufacturing'=>'Manufacture', 'Media'=>'M?dia', 'Not For Profit'=>'But non lucratif', 'Recreation'=>'Amusement', 'Retail'=>'D?taillant', 'Shipping'=>'Livreur', 'Technology'=>'Technologie', 'Telecommunications'=>'T?l?communications', 'Transportation'=>'Voyage', 'Utilities'=>'D\'utilit? publique', 'Other'=>'Autre', //accounts type 'Analyst'=>'Analyste', 'Competitor'=>'Concurrent', 'Customer'=>'Client', 'Integrator'=>'Int?grateur', 'Investor'=>'Investisseur', 'Partner'=>'Partenaire', 'Press'=>'Presse', 'Prospect'=>'Prospect', 'Reseller'=>'Revendeur', 'Other'=>'Autre', 'Existing Business'=>'Client existant', 'New Business'=>'Nouveau client', 'Cold Call'=>'Appel direct', 'Existing Customer'=>'Client existant', 'Self Generated'=>'Auto g?n?r?', 'Employee'=>'Employ?', 'Partner'=>'Partenaire', 'Public Relations'=>'Relation publique', 'Direct Mail'=>'Email direct', 'Conference'=>'Conf?rence', 'Trade Show'=>'Salon', 'Web Site'=>'Site web', 'Word of mouth'=>'Bouche ? oreille', 'Other'=>'Autre', 'Prospecting'=>'Prospection', 'Qualification'=>'Qualification', 'Needs Analysis'=>'Requiert analyse', 'Value Proposition'=>'Proposition', 'Id. Decision Makers'=>'Attente d?cision', 'Perception Analysis'=>'Anallyse', 'Proposal/Price Quote'=>'Devis', 'Negotiation/Review'=>'N?gociation', 'Closed Won'=>'Clos gagn?', 'Closed Lost'=>'Clos perdu', 'Attempted to Contact'=>'Attente contact', 'Cold'=>'Froid', 'Contact in Future'=>'A recontacter', 'Contacted'=>'Contact?', 'Hot'=>'Chaud', 'Junk Lead'=>'Corbeille', 'Lost Lead'=>'Perdu', 'Not Contacted'=>'Non contact?', 'Pre Qualified'=>'Pr? qualifi?', 'Qualified'=>'Qualifi?', 'Warm'=>'Brulant', 'Acquired'=>'Acquis', 'Active'=>'Actif', 'Market Failed'=>'March? perdu', 'Project Cancelled'=>'Projet annul?', 'Shutdown'=>'Eteint', 'Open'=>'Ouvert', 'In Progress'=>'En cours', 'Wait For Response'=>'Attente de r?ponse', 'Closed'=>'Clos', 'General'=>'G?n?ral', 'Low'=>'Basse', 'Normal'=>'Normale', 'High'=>'Haute', 'Urgent'=>'Urgent', 'Minor'=>'Mineure', 'Major'=>'Majeur', 'Feature'=>'Fonctionnalit?', 'Critical'=>'Critique', 'Big Problem'=>'Gros probl?me', 'Small Problem'=>'Petit probl?me', 'Other Problem'=>'Autre probl?me', 'Hardware'=>'Mat?riel', 'Software'=>'Logiciel', 'CRM Applications'=>'Application CRM', 'Box'=>'Boite', 'Carton'=>'Carton', 'Dozen'=>'Douzaine', 'Each'=>'Pi?ce', 'Hours'=>'Heure', 'Impressions'=>'Impression', 'Lb'=>'Lb', 'M'=>'M', 'Pack'=>'Pack', 'Pages'=>'Pages', 'Pieces'=>'Pi?ces', 'Quantity'=>'Quantit?', 'Reams'=>'Rames', 'Sheet'=>'Pages', 'Spiral Binder'=>'Reliure', 'Sq Ft'=>'Sq Ft', 'Created'=>'Cr??', 'Delivered'=>'Livr?', 'Reviewed'=>'Corrig?', 'Accepted'=>'Accept?', 'Rejected'=>'Rejett?', 'Approved'=>'Approuv?', 'Sent'=>'Envoy?', 'Credit Invoice'=>'Avoir', 'Paid'=>'Sold?', 'Received Shipment'=>'Commande re?ue', 'Call'=>'Appel', 'Meeting'=>'Rendez-vous', 'Task'=>'T?che', '--None--'=>'Aucun', -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9ad522c6/attachment-0003.html From gopals at vtiger.com Mon Jul 17 13:58:01 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 10:58:01 -0700 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Message-ID: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Hi, If there is automate option, it is better to notify user id and password to the correct email ids. I am already struggling with free forums and wiki registration process. People register with junk mail ids and spam our bug tracker as well. My be we can create a group mail id and alias to admin users, who can create trac users ids so that load is shared among developer community. Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/c36beaeb/attachment-0001.html From mmbrich at fosslabs.com Mon Jul 17 14:18:22 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:18:22 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Message-ID: <1153160302.5582.73.camel@localhost.localdomain> > It is plain that as of now, there are only 2 "strong/loud" arguments. > I am sure you all will agree that both of them are not overly > subscribed by any majority yet. Yes but there is only one idea on the table, and 1 set of criticisms followed by absolutely no suggestions on how to better the first idea. This was really my bitch about the first set of posts. > > Let us get some more ideas- however radical they be- into this list > and then we will vote the good ideas in. This is a great idea. I have been looking forward to someone else posting some ideas to get the ball rolling. I for one welcome radical ideas if anyone has any. > By being too strongly worded on any particular idea, it will only stop > short the other guys to put forth their ideas however > miniscule/insignificant that might appear to be. I certainly don't mean to scare off any developers that are going to actually bring some ideas to the table, quite the contrary. If someone has been playing around in 5.x and said to themselves "wouldn't it be easier if this was done like this..." then please tell us what you are thinking, even if it doesn't involve a full change to the architecture and only covers some small area of the code. > > I have myself faced this situations many times and I wish that the > same does not happen here. > > Let us target 2 weeks from today as the time within which we should > get all the ideas in. Lets not rush this, or pile on top of the workload that many vtiger devels are probably already experiencing. The only reason I brought my idea to the table this soon is because you and I had discussed this off list and I thought it needed to be in front of the community. > We can always short list as we have quite some experienced hands on > board. > vtigercrm-5.0.0 will be out within that time. But after 5.0.0 is out is when I think we'll start to see the most interesting ideas. Many devels may still be in 4.x and haven't had a chance yet to start playing with 5.x. Lets let them get their hands dirty in the new code first. > > Good to see some emotion here but I am sure we will hold to the rules > of basic etiquettes and only wrt the point in concern. I know I am a blunt person and sometimes that catches people off guard :), I rarely mean to come off as rude unless someone fully deserves it. Anyways, bring on the ideas for improving vtiger! Matt From mmbrich at fosslabs.com Mon Jul 17 14:22:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:22:49 -0600 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Message-ID: <1153160569.5582.79.camel@localhost.localdomain> I can't think of a great way to do automated sign-up without using captcha or something similar, and we all know there are ways around those systems. I like your ideas of an admin list that people can request access from. And BTW, which interface are you guys using to give developers trac accounts? There is the trac module which was installed or there is the service page that I created to manage SVN and trac. The reason I ask is because the service page may be out of date now that we've upgraded trac a couple times since I wrote it. Matt On Mon, 2006-07-17 at 10:58 -0700, Gopal wrote: > Hi, > > If there is automate option, it is better to notify user id and > password to the correct email ids. I am already struggling with free > forums and wiki registration process. People register with junk mail > ids and spam our bug tracker as well. > > My be we can create a group mail id and alias to admin users, who can > create trac users ids so that load is shared among developer > community. > > Gopal > --- > S.S.G.Gopal > skype: sripadag > ph: +1 877 788 4437 > blog: http://gopal.vtiger.com > > > > > ----richie at vtiger.com wrote ---- > > > Hi! > Team, is there any way we can have an automated trac registration? I can do the registrations > till a point and the current mechanism is too crude. > > Jeff/Matt any ideas please? > > Richie _______________________________________________ > Get started with creating presentations online - > http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Mon Jul 17 14:24:20 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:24:20 -0600 Subject: [Vtigercrm-developers] Fwd: error In-Reply-To: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> References: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> Message-ID: <1153160660.5582.81.camel@localhost.localdomain> I'll upgrade the demo sometime this afternoon, I still haven't had a chance to sit down and write an automation system for this since. I plan to create something along the lines of Jeff's suggestion and automate it with post-commit hooks. Anyone who wants to help, just say the word. Matt On Mon, 2006-07-17 at 09:34 -0700, Richie wrote: > > > > > ----j.ruisz at ruisz.com wrote ---- > > ============Forwarded Mail============ > From : j.ruisz at ruisz.com > To : richie at vtiger.com > Date :Fri, 14 Jul 2006 08:11:36 +0200 > Subject : error > ============Forwarded Mail============ > > Hello , > > trying to test the online demo of vtiger 5 i got this result: > > *Fatal error*: Call to a member function on a non-object in > */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* > on line *431* > > > > with best regards, > mit freundlichen Gr??en, > > Joachim Ruisz > > Werbegrafik, Bildagentur, Webagentur > Softwareentwicklung > > Joachim Ruisz > A 8940 Liezen > +43 664 312 4830 > j.ruisz at ruisz.com > http://www.ruisz.com > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From gopals at vtiger.com Mon Jul 17 14:37:05 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 11:37:05 -0700 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> References: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Message-ID: <10c7dc6f0c9.-5230172439552086929.-6694355083648319934@@vtiger.com> Hi Richie, I am aware of that currently we are using AdventNet QEngine for automating some of the test cases. But I am not clear, how can our external developer community use this tool in their local environment. Do you have any plans to get some more licenses for the sake of vtiger developer community? Thanks, Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/8b304edc/attachment-0003.html From jtk at yahoo.com Mon Jul 17 15:01:00 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 15:01:00 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: Gopal wrote: > I am aware of that currently we are using AdventNet QEngine for > automating some of the test cases. But I am not clear, how can our > external developer community use this tool in their local environment. > Do you have any plans to get some more licenses for the sake of vtiger > developer community? I'm glad to see regression tests on the agenda, but we don't need non-free tools to get this done. Selenium, which I've mentioned before, runs recorded tests in a browser, giving the most/only realistic test environment for javascript, etc. Selenium tests can be recorded by a firefox plugin, and the test source can be checked into subversion like any other source. This is what we should use, IMHO. http://openqa.org/selenium/ As far as running 'continuous integration testing'; some testing experts have used buildbot and vmware/vnc integration to continuously and automatically run unit and integration tests in a headless environment. http://www.google.com/search?q=buildbot+selenium http://agile.idyll.org/wiki/BuildBotTechnologyNarrative http://agile.idyll.org/buildbot/ All this testing technology uses free software. From mmbrich at fosslabs.com Mon Jul 17 17:25:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 15:25:52 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: <1153171552.5582.166.camel@localhost.localdomain> I haven't looked into Selenium yet but with JS does it work at the source level only, does it use gecko to actually execute and evaluate the JS or can it check for changes in the DOM like it does the source? In 5.x there are quite a few places where the DOM is being manipulated directly or indirectly and I don't think a source level verification tool will catch most of those. Maybe augmenting it with the scriptactulous unit test lib would work? http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Matt On Mon, 2006-07-17 at 15:01 -0400, Jeff Kowalczyk wrote: > Gopal wrote: > > I am aware of that currently we are using AdventNet QEngine for > > automating some of the test cases. But I am not clear, how can our > > external developer community use this tool in their local environment. > > Do you have any plans to get some more licenses for the sake of vtiger > > developer community? > > I'm glad to see regression tests on the agenda, but we don't need non-free > tools to get this done. > > Selenium, which I've mentioned before, runs recorded tests in a browser, > giving the most/only realistic test environment for javascript, etc. > > Selenium tests can be recorded by a firefox plugin, and the test source > can be checked into subversion like any other source. This is what we > should use, IMHO. > > http://openqa.org/selenium/ > > As far as running 'continuous integration testing'; some testing experts > have used buildbot and vmware/vnc integration to continuously and > automatically run unit and integration tests in a headless environment. > > http://www.google.com/search?q=buildbot+selenium > > http://agile.idyll.org/wiki/BuildBotTechnologyNarrative > > http://agile.idyll.org/buildbot/ > > All this testing technology uses free software. > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Mon Jul 17 18:53:33 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 18:53:33 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: Matthew Brichacek wrote: > I haven't looked into Selenium yet but with JS does it work at the > source level only, does it use gecko to actually execute and evaluate > the JS or can it check for changes in the DOM like it does the source? > In 5.x there are quite a few places where the DOM is being manipulated > directly or indirectly and I don't think a source level verification > tool will catch most of those. Selenium directly drives the browser as if the user were clicking it. The demo http://www.openqa.org/selenium-core/demos.html illustrates the concept. > Maybe augmenting it with the scriptactulous unit test lib would work? > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Unit tests in the client and server-side source would be enhancements, to be sure. However, I am skeptical about trying to retrofit unit test coverage to a large code base. The community would have a hard time achieving useful code coverage unless there were tests for *everything*, starting from early in the project. Selenium's end-result testing, and the fact that such tests can be recorded for submission by even novice users, would be an efficient use of limited community resources. If the testing fever strikes the community, perhaps all new code could be required to have unit tests, and so on. From sergiokessler at gmail.com Mon Jul 17 19:14:20 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 20:14:20 -0300 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 In-Reply-To: <8091387652950704133@unknownmsgid> References: <8091387652950704133@unknownmsgid> Message-ID: <49216030607171614g2a47b5di900e13b06c4810f6@mail.gmail.com> richie, a wiki is the best aproach for this, don't worry... (of course, then you need people that do collaborate) /sak On 7/17/06, Richie wrote: > > Ken asked me a question in my blogs about how we can have > a better documentation for v5. > I honestly do not know if any setup is available which > can help us achieve the same other than > that of a wiki. > Any new ideas are welcome. > > It will be nice to have a distributed effort on for > the documentation as well. > Let us get some working backbone for > collaborative documentation up and running > fast. > > Any ideas/suggestions? > Any experienced documentor on board, please raise hands! > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From mmbrich at fosslabs.com Mon Jul 17 20:13:46 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 18:13:46 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: <1153181627.5582.194.camel@localhost.localdomain> On Mon, 2006-07-17 at 18:53 -0400, Jeff Kowalczyk wrote: > Matthew Brichacek wrote: > > I haven't looked into Selenium yet but with JS does it work at the > > source level only, does it use gecko to actually execute and evaluate > > the JS or can it check for changes in the DOM like it does the source? > > In 5.x there are quite a few places where the DOM is being manipulated > > directly or indirectly and I don't think a source level verification > > tool will catch most of those. > > Selenium directly drives the browser as if the user were clicking it. The > demo http://www.openqa.org/selenium-core/demos.html illustrates the > concept. I tried this out and did a little digging in the Core and IDE. From the looks of it, Selenium can handle a _lot_ of the javascript testing we would need, if not all of it. > > > Maybe augmenting it with the scriptactulous unit test lib would work? > > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting > > Unit tests in the client and server-side source would be enhancements, to > be sure. However, I am skeptical about trying to retrofit unit test > coverage to a large code base. The community would have a hard time > achieving useful code coverage unless there were tests for *everything*, > starting from early in the project. > > Selenium's end-result testing, and the fact that such tests can be > recorded for submission by even novice users, would be an efficient use of > limited community resources. If the testing fever strikes the community, > perhaps all new code could be required to have unit tests, and so on. I had thought of this before too but my experience in requiring unit tests has not been good :). In the CGL project we tried to enforce a rule like this and it was shot down almost before it left the ground. In a PoC environment like that it's understandable but I think even in the case of vtiger the fever would have to be HOT to get everyone on board. Matt From richie at vtiger.com Tue Jul 18 01:40:42 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 22:40:42 -0700 Subject: [Vtigercrm-developers] XTemplate removed Message-ID: <10c80267f98.3578777089016548574.3997907602755987476@@vtiger.com> This is to inform that we have removed XTemplate dependency in vtigercrm5.0.0. XTemplate has been removed from the source as well. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9fe2c2d6/attachment-0001.html From webmaster at vtigerfacile.com Tue Jul 18 05:18:43 2006 From: webmaster at vtigerfacile.com (=?ISO-8859-1?Q?A=EFssa?=) Date: Tue, 18 Jul 2006 11:18:43 +0200 Subject: [Vtigercrm-developers] Idea for future Message-ID: <44BCA773.9050506@vtigerfacile.com> Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa From richie at vtiger.com Tue Jul 18 06:20:36 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:20:36 -0700 Subject: [Vtigercrm-developers] need helping hands Message-ID: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> I am quoting Gopal's bug report. " As per discussion. I am testing product on the following setup: OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a-installer.exe php settings: error_reporting = E_ALL display_errors = On display_startup_errors = On log_errors = On After completion of installation 1.2 mb error log is generated in Apache error.log file. It is better to fix some of the notices and warnings, which will definitely improve the performance of the product. Thanks, Gopal " Need helping hands who can dig into this and give the fixes. We are held up with validation over here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/071764bc/attachment-0003.html From richie at vtiger.com Tue Jul 18 06:21:42 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:21:42 -0700 Subject: [Vtigercrm-developers] Idea for future In-Reply-To: <44BCA773.9050506@vtigerfacile.com> References: <44BCA773.9050506@vtigerfacile.com> Message-ID: <10c8127c4e2.-191772016694368201.-7661796100973677084@@vtiger.com> Hello! I do agree with that. I wanted it to be part of vtigercrm-5.0.0 but it was a feature so dropped it. It does not require too much effort actually. Will be taken up as part of 5.0.1 Richie ---- A?ssa<webmaster at vtigerfacile.com> wrote ---- Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/c3cec421/attachment-0001.html From richie at vtiger.com Tue Jul 18 08:13:08 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 05:13:08 -0700 Subject: [Vtigercrm-developers] need helping hands-2 Message-ID: <10c818dc9b0.-7967502206826138398.-2571256210646174921@@vtiger.com> We are getting quite some javascript issues in IE browsers. Any one out there game to test it in IE and help us by giving the fixes will be great. Please ensure that the fix does not break the Firefox/Mozilla support. Kindly post the fix in the trac and a blurb here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/a6b94bf0/attachment-0003.html From developer at infointegrated.com Tue Jul 18 08:33:39 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Tue, 18 Jul 2006 07:33:39 -0500 Subject: [Vtigercrm-developers] need helping hands In-Reply-To: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> References: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> Message-ID: <9160DA4D-DAAA-4C0D-B458-E401E03C5E49@infointegrated.com> Sounds like quite the challenge. I just started doing some more thorough testing of vtiger 5.0. I have created 3 new tickets on it. I was able to create patches for the first two. #1531 is to reset the Quick Create menu to Quick Create... after selecting an item (with a patch). #1532 cleans up the formatting of the AllMenu: putting headers on all columns, keeping the length more consistent (with a patch). #1533 is a bug when resizing the window too small. the HomePage Dashboard looks horrible. There needs to be some resize code, but I've not had time to look into patching this one. If I have time, I will also look for solutions to some of the error logs and IE JavaScript Issues. Not sure how much free time I'll have... Brian On Jul 18, 2006, at 5:20 AM, Richie wrote: > I am quoting Gopal's bug report. > " > As per discussion. I am testing product on the following setup: > OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a- > installer.exe php settings: > error_reporting = E_ALL display_errors = On display_startup_errors > = On log_errors = On > After completion of installation 1.2 mb error log is generated in > Apache error.log file. > It is better to fix some of the notices and warnings, which will > definitely improve the performance of the product. > Thanks, Gopal > " > > > Need helping hands who can dig into this and give the fixes. > We are held up with validation over here. > > Richie > _______________________________________________ > Get started with creating presentations online - http:// > zohoshow.com?vt From dgrant at accuratetechnologies.com Tue Jul 18 08:58:03 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 18 Jul 2006 08:58:03 -0400 Subject: [Vtigercrm-developers] vtiger arch going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090C@exch.accuratetechnologies.com> >> It is plain that as of now, there are only 2 "strong/loud" arguments. >> I am sure you all will agree that both of them are not overly >> subscribed by any majority yet. > Yes but there is only one idea on the table, and 1 set of criticisms > followed by absolutely no suggestions on how to better the first idea. > This was really my bitch about the first set of posts. Then frankly, you misread. 1) All code must be commented. Ideally, this would be a priority such that commenting existing code would be an actual project, but realistically, the goal of "all NEW code must be commented" or perhaps "every time you touch the code, a comment must be inserted" is doable. 2) The current (4.x) architecture uses a number of "common" functions (so identified by virtue of living in the include directory) that are not really common. An easy test is that if at any time a soi-disant "common" function tests to see what module it was called from and then acts differently based on the result of that test, it ain't common. Those functions should be broken out of the include directory and moved into the appropriate module directory - perhaps something like modules/Foo/UI.php (although this naming convention is definitely open for discussion) 3) Any time you go to the database, the actual SQL should be exposed; it helps integrators understand the layout and function of the database and makes extending the database much easier. It's OK to streamline db functions somewhat though - something like: $query = 'SOME SQL'; @2D_array = query_db($query) or handle_db_error; Is OK. 3) All modules must be atomic. At no time is it EVER permissible that changing the code in module FOO *changes* the functionality of module BAR - with one exception; if module FOO ever *calls* module BAR, and a code change to BAR has broken the interface, then it is understood that FOO calling BAR will break (and shame on whoever changed BAR's interface) In some cases, this will actually move functionality INTO common code, and that's a good thing. For example, currently HelpDesk calls code in Emails to do its email notification stuff (HORROR!) This would be better served by a function in utils.php that called some sort of generic email API: $result = send_email($to, $from, $cc, $bcc, $subject, $body, $flags); 4) There are two major challenges facing the vtiger architecture, independent of code structure: a) Per-user localization, which in turn is broken down into: i) User language of choice; and ii) User operating currency (which may be a function of what office the user is working out of) b) Per-user security (a user cannot edit someone else's Quote, for example) Both of these are ABSOLUTE MUSTS going forward, and there's a lot of heavy lifting there. No matter what the code structure is, these two design structures must be part of the arch. I'm hoping that 5.0 has support for this already... >> Let us get some more ideas- however radical they be- into this list >> and then we will vote the good ideas in. > This is a great idea. I have been looking forward to someone else > posting some ideas to get the ball rolling. I for one welcome radical > ideas if anyone has any. Hrm, well, let's see how welcoming you *really* are. DG From jens at Strawberry.COM Tue Jul 18 09:16:35 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 15:16:35 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] Message-ID: <20060718151635.D16513@Strawberry.COM> -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- An embedded message was scrubbed... From: Jens Hamisch Subject: Patches required for PostgreSQL 8.1.4 Date: Tue, 18 Jul 2006 09:02:01 +0200 Size: 27774 Url: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/efd557cc/attachment-0003.mht From allan.bush+vtiger_dev at gmail.com Tue Jul 18 10:14:27 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 07:14:27 -0700 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <20060718151635.D16513@Strawberry.COM> References: <20060718151635.D16513@Strawberry.COM> Message-ID: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> I have given up on getting postgres support into 5.0 because I got tired of having my changes reverted and the database changing on me. The last straw was when all the database table names were changed without warning. If someone else wants to continue the effect feel free to take a look at this patch and take over the effort. On 7/18/06, Jens Hamisch wrote: > > -- > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > > ---------- Forwarded message ---------- > From: Jens Hamisch > To: vtigercrm-developers at lists.vtigercrm.com > Date: Tue, 18 Jul 2006 09:02:01 +0200 > Subject: Patches required for PostgreSQL 8.1.4 > Hi, > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > database. Compared to mySQL this database seems to require some code > changes. I've located and fixed the following problems: > > 1. SELECT count(*) count FROM ... won't work. > The AS clause is missing: SELECT count(*) AS count FROM ... > > 2. Referring table columns in case of joined tables in the > SELECT or ORDER BY clause requires the columns also to be > listed in a GROUP BY clause. > > 3. tablename.* won't work in a GROUP BY clause > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > LIMIT and OFFSET clause. > > 5. PostgreSQL supports transactions. However the current coding > results in transaction failures. > > I've attached my patches to this mail. Those patches at a first glance > address the problems 1-4. The transaction problem is not yet fixed. > I want to clean up the "simple" SQL statements first, before analyzing > such complex things. > > I'm not a 100% satisfied with the patches, because they introduce some > dbType dependencies into the "high level" vtiger code. Also structural > information is required in the function which expands the queries by > the required GROUP BY clause. I was thinking of moving those things > to a more abstract layer, but stopped doing this, because a generic > solution would either result in parsing and fixing each entire SQL statement > (including all its features and possibilities) or a redesign of the > affected SQL queries itsself. > > In most cases (especially the LIMIT changes) my patches might also work > for mySQL, so the database dependency possibly could be removed. This > might also apply to some of the GROUP BY patches. > > > Hope those changes will find their way to the vtigercrm5 mainline. > > Kind regards > -- Jens > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > From jens at Strawberry.COM Tue Jul 18 11:12:13 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 17:12:13 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com>; from Allan Bush on Tue, Jul 18, 2006 at 07:14:27AM -0700 References: <20060718151635.D16513@Strawberry.COM> <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> Message-ID: <20060718171213.F16513@Strawberry.COM> Hi Allan, hi *, most changes I did seem not to be related to postgres only. So it would help a lot (and remove dbType dependencies) from the code if smb. could check if my changes will also be valid for mySQL ... Jens On Tue, Jul 18, 2006 at 07:14:27AM -0700, Allan Bush wrote: > I have given up on getting postgres support into 5.0 because I got > tired of having my changes reverted and the database changing on me. > The last straw was when all the database table names were changed > without warning. > > If someone else wants to continue the effect feel free to take a look > at this patch and take over the effort. > > On 7/18/06, Jens Hamisch wrote: > > > > -- > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > > > ---------- Forwarded message ---------- > > From: Jens Hamisch > > To: vtigercrm-developers at lists.vtigercrm.com > > Date: Tue, 18 Jul 2006 09:02:01 +0200 > > Subject: Patches required for PostgreSQL 8.1.4 > > Hi, > > > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > > database. Compared to mySQL this database seems to require some code > > changes. I've located and fixed the following problems: > > > > 1. SELECT count(*) count FROM ... won't work. > > The AS clause is missing: SELECT count(*) AS count FROM ... > > > > 2. Referring table columns in case of joined tables in the > > SELECT or ORDER BY clause requires the columns also to be > > listed in a GROUP BY clause. > > > > 3. tablename.* won't work in a GROUP BY clause > > > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > > LIMIT and OFFSET clause. > > > > 5. PostgreSQL supports transactions. However the current coding > > results in transaction failures. > > > > I've attached my patches to this mail. Those patches at a first glance > > address the problems 1-4. The transaction problem is not yet fixed. > > I want to clean up the "simple" SQL statements first, before analyzing > > such complex things. > > > > I'm not a 100% satisfied with the patches, because they introduce some > > dbType dependencies into the "high level" vtiger code. Also structural > > information is required in the function which expands the queries by > > the required GROUP BY clause. I was thinking of moving those things > > to a more abstract layer, but stopped doing this, because a generic > > solution would either result in parsing and fixing each entire SQL statement > > (including all its features and possibilities) or a redesign of the > > affected SQL queries itsself. > > > > In most cases (especially the LIMIT changes) my patches might also work > > for mySQL, so the database dependency possibly could be removed. This > > might also apply to some of the GROUP BY patches. > > > > > > Hope those changes will find their way to the vtigercrm5 mainline. > > > > Kind regards > > -- Jens > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From allan.bush+vtiger_dev at gmail.com Tue Jul 18 11:21:46 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 08:21:46 -0700 Subject: [Vtigercrm-developers] Commit list is broken Message-ID: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> I haven't received any email from the commit/ticket list (vtigercrm-commits at lists.vtigercrm.com) since the 16th. I just made a couple changes which should have triggered emails and they haven't been received either so I'm fairly certain the list is down. From mmbrich at fosslabs.com Tue Jul 18 14:28:48 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 18 Jul 2006 12:28:48 -0600 Subject: [Vtigercrm-developers] Commit list is broken In-Reply-To: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> References: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> Message-ID: <1153247328.5582.214.camel@localhost.localdomain> This is probably from the SVN upgrade, the version we are on now moved all hook scripts to a diff area and I probably missed one. I'll see if I can fix it ASAP. Matt On Tue, 2006-07-18 at 08:21 -0700, Allan Bush wrote: > I haven't received any email from the commit/ticket list > (vtigercrm-commits at lists.vtigercrm.com) since the 16th. > > I just made a couple changes which should have triggered emails and > they haven't been received either so I'm fairly certain the list is > down. > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jens at Strawberry.COM Tue Jul 18 14:44:48 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 20:44:48 +0200 Subject: [Vtigercrm-developers] Yet another postgres8 patch Message-ID: <20060718204448.D29275@Strawberry.COM> Hi, yet another patch addressing postgres8 Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- *** vtiger_crm/include/database/Postgres8.php.rev8092 Tue Jul 18 20:37:05 2006 --- vtiger_crm/include/database/Postgres8.php Tue Jul 18 20:38:50 2006 *************** *** 122,127 **** --- 122,131 ---- elseif( $table == "vtiger_profile2field") $subfields = array ( "profileid", "tabid", "fieldid", "visible", "readonly"); + //vtiger_field + elseif( $table == "vtiger_field") + $subfields = array ( "tabid", "fieldid", "columnname", "tablename", "generatedtype", "uitype", "fieldname", "fieldlabel", "readonly", "presence", "selected", "maximumlength", "sequence", "block", "displaytype", "typeofdata", "quickcreate", "quickcreatesequence", "info_type"); + //fields of the requested array still undefined else $log->info("function expandRecord: please add structural information for table '".$table."'"); *** vtiger_crm/include/utils/CommonUtils.php.rev8092 Tue Jul 18 20:25:23 2006 --- vtiger_crm/include/utils/CommonUtils.php Tue Jul 18 20:36:01 2006 *************** *** 960,971 **** { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in $blockid_list and vtiger_field.displaytype in (1,2,4) order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and vtiger_field.displaytype in (1,2,4) and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." group by vtiger_field.fieldid order by block,sequence"; } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); --- 960,974 ---- { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN $blockid_list AND vtiger_field.displaytype IN (1,2,4) ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND vtiger_field.displaytype IN (1,2,4) AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); *************** *** 976,987 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list ." and ".$display_type_check." and info_type = '".$info_type."' order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and info_type = '".$info_type."' and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } else --- 979,993 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list ." AND ".$display_type_check." AND info_type = '".$info_type."' ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND info_type = '".$info_type."' AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } else *************** *** 988,999 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } $result = $adb->query($sql); --- 994,1008 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } $result = $adb->query($sql); *************** *** 1789,1796 **** } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and quickcreate=0 and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." order by quickcreatesequence"; } $category = getParentTab(); --- 1798,1808 ---- } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND quickcreate=0 AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." ORDER BY quickcreatesequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $quickcreate_query = fixPostgresQuery( $quickcreate_query, $log, 0); } $category = getParentTab(); *** vtiger_crm/modules/Users/Authenticate.php.rev8092 Tue Jul 18 19:55:38 2006 --- vtiger_crm/modules/Users/Authenticate.php Tue Jul 18 19:57:24 2006 *************** *** 40,47 **** { //Inserting entries for audit trail during login ! $date_var = date('YmdHis'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,$date_var)"; $adb->query($query); --- 40,47 ---- { //Inserting entries for audit trail during login ! $date_var = date('Y-m-d H:i:s'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,'$date_var')"; $adb->query($query); From libregeek at gmail.com Wed Jul 19 01:07:25 2006 From: libregeek at gmail.com (Manilal K M) Date: Wed, 19 Jul 2006 10:37:25 +0530 Subject: [Vtigercrm-developers] Something happened with forums.vtiger.com Message-ID: <2315046d0607182207k577376efv69026d9ce7e887c2@mail.gmail.com> Hi Team, Today Morning I got the reminder for the forum topic given below. How this happened? There are mo updates on this thread and it's almost 4 months old. Please look into it. regards Manilal ---------- Forwarded message ---------- From: webmaster at vtiger.com Date: 19-Jul-2006 07:38 Subject: New Topic Notification for forum "Announcements" - vtiger CRM 5 Alpha 5 Released To: Hello ! Sai has posted a new topic called "vtiger CRM 5 Alpha 5 Released" in the "Announcements" forum at vtiger. You can use the following link to view the topic: http://forums.vtiger.com/viewtopic.php?p=23074#23074 ----------------------------------------------- Posted text: Hi, We are pleased to announce the vtiger [b:7141f7c5eb]CRM 5.0 Alpha 5 release[/b:7141f7c5eb]. The intent of this release is to showcase to the vtiger community, the significant changes made after v5 Alpha 4 release i.e., changes since Mar 31, 06\' . We have conducted performance testing for some of the modules using a popular [b:7141f7c5eb]Web Based Testing Software (AdventNet QEngine 6.0),[/b:7141f7c5eb] which helped us to identify some of the bottlenecks in performance. We will publish the performance reports soon. We thank AdventNet for permitting us to make use of this interesting software and we gladly recommend it to everyone too, not because AdventNet allowed us to use it but because it is really good. We are also pleased to release the downloadable version of the [b:7141f7c5eb]vtiger CRM PHP API Documentation.[/b:7141f7c5eb] The demo of vtigerCRM 5 alpha 5 is available at http://vtiger.com/products/crm/demo_5alpha/index.php You can download the [b:7141f7c5eb]EXE, BIN, or tar.gz[/b:7141f7c5eb] from Sourceforge.net. [b:7141f7c5eb]NOTE:[/b:7141f7c5eb] We strongly recommend CRM community NOT to USE vtiger CRM 5 Alpha 5 for real-time deployment. In case you are looking for an immediate CRM solution for your business, please consider using the vtiger CRM 4.2.3 (latest stable version) or 4.2.4 which will be out shortly. [b:7141f7c5eb]Important URLs:[/b:7141f7c5eb] [b:7141f7c5eb]Download:[/b:7141f7c5eb] http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=186641 [b:7141f7c5eb]Report Bugs[/b:7141f7c5eb] @: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Note: Please refer to the reported bugs before submitting a new bug. [b:7141f7c5eb]Release Notes:[/b:7141f7c5eb] * Smarty template applied to Currency Configuration Feature * List View feature database queries are optimized for all the modules * PHP API documentation for some of the major function * New module called Marketing is added. Campaigns module is now part of Marketing primary module. * AJAXified Notification Schedulers * AJAXified Inventory Notifications * AJAXified Picklist Settings * AJAXified Assign Module Owners * New UI for Integration of Mail Merge Templates * New UI for Company Information * New UI for Outgoing Mail Server * New UI for Backup Server Configuration * New UI for Terms and Conditions * New UI for Announcements * New UI for RSS module Thanks & Regards, Don ----------------------------------------------- You are receiving this email because you are watching the forum, "Announcements" at vtiger. If you no longer wish to watch this forum you can either click the "Stop watching this forum link" found at the bottom of the "Announcements" forum, or by clicking the following link: http://forums.vtiger.com/viewforum.php?f=1&unwatch=forum -- Thanks, The Management -- I would rather be a serf in a poor man's house and be above ground than reign among the dead From dgrant at accuratetechnologies.com Wed Jul 19 08:58:46 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 19 Jul 2006 08:58:46 -0400 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Simple question: when is the next (Beta?) release of V5.0 due out? DG From richie at vtiger.com Wed Jul 19 09:22:20 2006 From: richie at vtiger.com (Richie) Date: Wed, 19 Jul 2006 06:22:20 -0700 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? In-Reply-To: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Message-ID: <10c86f3829c.5523764322808677804.-2671785383507032457@@vtiger.com> Simpler answer :-): No betas. Expect RC1 in 10 days or so. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Simple question: when is the next (Beta?) release of V5.0 due out? DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/e1ba94eb/attachment-0003.html From Matjaz.Slak at atol.si Wed Jul 19 10:45:49 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Wed, 19 Jul 2006 16:45:49 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Message-ID: Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment-0001.bin From developer at infointegrated.com Thu Jul 20 00:45:03 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Wed, 19 Jul 2006 23:45:03 -0500 Subject: [Vtigercrm-developers] Categories / Sub-Categories, Too Much In-Reply-To: References: Message-ID: If you haven't looked at the current collection of categories and subcategories, take a look. I think that it is becoming too much. Here's the current layout: My Home Page Home Activities Calendar Emails Marketing Campaigns Accounts Contacts Emails Leads Activities Calendar Notes Sales Leads Accounts Contacts Potentials Quotes Sales Order Invoice Products PriceBooks Notes Activities Calendar Support HelpDesk FAQ Accounts Contacts Products Notes Emails Activities Calendar Analytics Dashboard Reports Inventory Products Vendors PriceBooks Purchase Order Sales Order Quotes Invoice Tools RSS My Sites Notes Settings Settings I know the list is long and hard to read, but that's my point. I know and understand that different people will want their sub-modules in different places. As long as the method for changing this is documented, I think that is ok. The default configuration, though, should be simpler. This current layout is almost scary. At least for an end-user it would be. I feel this change should be made before 5.0 GA. To simplify, each item should only appear in one category. I have an updated proposal below that is the closest to meeting most of my customer's needs. With the All Menu, Quick Create, Related Items, and Tag Cloud, it shouldn't matter much if some modules are on different categories. I hope that there are still plans on combining activities and calendar into one item as well (I believe this was put off until after 5.0 GA). I think that an interface for managing these should also be planned post 5.0 GA. I also think the order of the items is important and (where relevant) the order should remain consistent. For example, the sub categories should remain in the same order under the category as it shows in the All Menu. What does everyone else think? Anyone else show this to existing clients and get questions about why the same module appears in many places? That's what got me started thinking of improvements. Any better ideas? My Home Page Home Emails Activities Calendar Contacts Notes Marketing Campaigns Leads Sales Accounts Potentials Quotes Sales Order Invoice Support HelpDesk FAQ Inventory Products Vendors PriceBooks Purchase Order Analytics Dashboard Reports Tools Settings My Sites RSS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/50687ed3/attachment-0001.html From richie at vtiger.com Thu Jul 20 04:06:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:06:18 -0700 Subject: [Vtigercrm-developers] unable to add users to trac Message-ID: <10c8af88631.-2915976287139770639.-215398406965928840@@vtiger.com> Hi Matt! Could you please have a look at the issue please? I am unable to add users to the trac anymore. I am using the following url. vtiger.fosslabs.com/service Do have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/02abcafe/attachment-0003.html From richie at vtiger.com Thu Jul 20 04:17:10 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:17:10 -0700 Subject: [Vtigercrm-developers] trac down? Message-ID: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Hi! The trac seems to be down. Matt, kindly have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/df8c96af/attachment-0001.html From mmbrich at fosslabs.com Thu Jul 20 04:24:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 20 Jul 2006 02:24:10 -0600 Subject: [Vtigercrm-developers] trac down? In-Reply-To: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> References: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Message-ID: <1153383850.5617.0.camel@localhost.localdomain> I was doing some work and had to give it a quick reboot. Should be back up and working now. Matt On Thu, 2006-07-20 at 01:17 -0700, Richie wrote: > Hi! > > The trac seems to be down. > Matt, kindly have a look please. > > Thanks, > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Thu Jul 20 05:47:37 2006 From: crm at email.si (Ales Petric) Date: Thu, 20 Jul 2006 10:47:37 +0100 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44AE643B.1040800@vtigerfacile.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> Message-ID: <44BF5139.9050402@email.si> Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Ai"ssa wrote: > Hi Richie, > i have a login for track, but not the right to submit ticket. > thanks, > Ai"ssa (very busy !) > > Richie a ?crit : > >> Hello! >> >> I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. >> Please cross-check if you have received the relevant mails in the id from which you had made the access >> request. >> >> Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. >> >> richie at vtiger dot com >> >> Richie >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/f47f9233/attachment-0003.html From richie at vtiger.com Thu Jul 20 04:58:46 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:58:46 -0700 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44BF5139.9050402@email.si> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> <44BF5139.9050402@email.si> Message-ID: <10c8b2890c0.2475106285347017844.4336268421121807772@@vtiger.com> Hi Ales! I have granted permission to the trac to all those who have asked for it. Not even 1 single request has been denied. Why should it be? The product is as much yours as mine just that someone has to be in some hiearchy somewhere does not mean that we have a monopoly over it. This is the first time I have got your request and I have granted access to you too. The 1 minute that I spend giving permission saves hours to the community as a whole. You are important, not only to me but to the community as well. I am sure you will do well. Richie ---- Ales Petric<crm at email.si> wrote ---- Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Aïssa wrote: Hi Richie, i have a login for track, but not the right to submit ticket. thanks, Aïssa (very busy !) Richie a ?crit : Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie ------------------------------------------------------------------------ _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/aeeddad4/attachment-0001.html From richie at vtiger.com Thu Jul 20 11:30:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 08:30:05 -0700 Subject: [Vtigercrm-developers] permissions revoked Message-ID: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Dear Team, I have revoked permissions for checkin in the main 5.0 trunk. Only the following have permission to checkin now into the 5.0 trunk. core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj All checkins have to be thru these guys alone. The permissions will be restored once the 5.0 is released. Requesting your understanding, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/0cea747a/attachment-0003.html From tgironnay at lexsi.com Thu Jul 20 11:54:15 2006 From: tgironnay at lexsi.com (GIRONNAY Thibault) Date: Thu, 20 Jul 2006 17:54:15 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi all, Matjaz I'll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It's too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we'll have others hands up cabugs ________________________________ De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: * debugging (fixing parts that either don't work at all and/or work incorrectly) * improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: * multilanguage support (simply get rid of any and all hard-coded strings) * full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/fdd85202/attachment-0001.html From nolan at peaceworks.ca Thu Jul 20 13:50:43 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Thu, 20 Jul 2006 13:50:43 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: References: Message-ID: <44BFC273.5060604@peaceworks.ca> Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Thu Jul 20 13:47:54 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 20 Jul 2006 13:47:54 -0400 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE4@exch.accuratetechnologies.com> Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection My vtigercrm.log is full of these. Where are they coming from and what can I do to stop it? DG From jens at Strawberry.COM Fri Jul 21 02:34:10 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Fri, 21 Jul 2006 08:34:10 +0200 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com>; from Richie on Thu, Jul 20, 2006 at 08:30:05AM -0700 References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Message-ID: <20060721083410.A22106@Strawberry.COM> Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From Matjaz.Slak at atol.si Fri Jul 21 03:04:48 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 09:04:48 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi! I agree completly. Security should be on the list of to-dos. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "GIRONNAY Thibault" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 17:54 Please respond to vtigercrm-developers at lists.vtigercrm.com To cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Matjaz I?ll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It?s too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we?ll have others hands up cabugs De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0001.bin From Matjaz.Slak at atol.si Fri Jul 21 07:36:00 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 13:36:00 +0200 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <44BFC273.5060604@peaceworks.ca> Message-ID: Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Nolan Andres Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0001.bin From jtk at yahoo.com Fri Jul 21 09:09:10 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Fri, 21 Jul 2006 09:09:10 -0400 Subject: [Vtigercrm-developers] permissions revoked References: <20060721083410.A22106@Strawberry.COM> Message-ID: Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. From richie at vtiger.com Fri Jul 21 10:11:25 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:11:25 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <20060721083410.A22106@Strawberry.COM> References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916d296e.5312358042738553104.8864199634924158691@@vtiger.com> Hi Jens! Currently, we are working on fixing the breakages that we have committed. Let these stabilize, then we can integrate this together. ok? I do not want to add one more variable now. Hence the precaution. Richie ---- Jens Hamisch<jens at strawberry.com> wrote ---- Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/ed49a8d5/attachment-0003.html From richie at vtiger.com Fri Jul 21 10:12:10 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:12:10 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: References: <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916dd6be.-546019034062113847.-6787520244753134675@@vtiger.com> Yes, you are right. We will take this into consideration before vtigercrm-5.0.0 is out. In other words, postgres is going to be part of this very release. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/51fe5c86/attachment-0001.html From richie at vtiger.com Fri Jul 21 10:13:48 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:13:48 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: References: Message-ID: <10c916f5716.-3447470126087516421.7834933168012625785@@vtiger.com> Matjaz, you already would have got the access mail for the trac. About the TRAC Wiki, Matt will do the needful. Let us know if you need anything else. Richie ---- Matjaz.Slak at atol.si<Matjaz.Slak at atol.si> wrote ---- Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 Nolan Andres <nolan at peaceworks.ca> Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned        Plea        froma        VTiger        Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > >   > > Matjaz I’ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It’s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > >   > > Hope we’ll have others hands up > >   > > cabugs > >   > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > >   > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > >     * debugging (fixing parts that either don't work at all and/or work >       incorrectly) >     * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > >     * multilanguage support (simply get rid of any and all hard-coded >       strings) >     * full per user or at least per-system localization support (number >       format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 > > *Richie <richie at vtiger.com>* > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > >                   > > To > >                   > > vtigercrm-developers at lists.vtigercrm.com > > cc > >                   > > vtigercrm-developers at lists.vtigercrm.com > > Subject > >                   > > Re: [Vtigercrm-developers] An Impassioned Plea from a        VTiger     >    Integrator > >   > >   > >                   > >   > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: >> >>  Hi! >> >>  If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > <http://zohoshow.com?vt/> _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7be12bf9/attachment-0003.html From allan.bush+vtiger_dev at gmail.com Fri Jul 21 11:32:23 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 21 Jul 2006 08:32:23 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <-8603876167918116646@unknownmsgid> References: <-8603876167918116646@unknownmsgid> Message-ID: <3bec26390607210832x65ed46eo60856d8e2972c110@mail.gmail.com> This is the page we should be using to keep track of everything to be done for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=new&status=assigned&status=reopened&milestone=4.2.5 It would be nice to have a 4.2.6 (or 4.2 future) milestone to keep the list realistic though. Fell free to organize, add and prioritize the things in that list. On the same note you here is the page of everything already accomplished for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=closed&milestone=4.2.5 On 7/21/06, Richie wrote: > > Matjaz, you already would have got the access mail for the trac. > About the TRAC Wiki, Matt will do the needful. > > > Let us know if you need anything else. > > Richie > > > > > ---- Matjaz.Slak at atol.si wrote ---- > > > > Hi! > > Thank you! > > I hope I'll be able to finish up some of my other tasks within a week or > so and then I'll start posting ideas about what to work on here. > > *If anybody has any general wishes and/or requests about which item(s) you > would like to have fixed in 4.2.x, post them here.* By this I mean areas > perceived by vTiger users. Try to fit them in the following categories: > > - debugging (fixing user-perceived functions that either don't work > at all and/or work incorrectly) > - improving usability (based on feedback from users) > - improving security (let us know of possible security holes) > - multilanguage support (simply get rid of any and all hard-coded > strings) > - localization support (number format, date format, currency support > etc - per user or at least per-system) > - other (we can create aditional categories if the need arises) > > > For example: > > - Private Custom Views - allow for a custom view to be marked as > private and only be visible to the user that created it (usability) > - All View columns sortable - allow a user to click on any column > and sort it (usability) > - Repeating calls/meetings - don't work at all? (debugging) > - etc... > > > I'll be collecting them and posting them somewhere - the TRAC Wiki comes > to mind as an appropriate place. We can the priorithise them and look into > required work - and then create tickets for developers (us, again :) to work > on. > > *Richie, Jeff, Matt and/or others:* would it me possible for me to have > acces to post some content to the TRAC Wiki? I would create a document like > "vTiger 4.2.x to-do area" that would include these items we wish to work > on - and specific goals for them. Tickets would then be created based on > these. This document would represent the general guideline. > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > *Nolan Andres * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 20.07.2006 19:50 Please respond to > vtigercrm-developers at lists.vtigercrm.com > > To > vtigercrm-developers at lists.vtigercrm.com cc > > Subject > Re: [Vtigercrm-developers] An Impassioned Plea froma > VTiger Integrator > > > > > > > Hi all, > > Although I'd really love to be able to just contribute features without > having to re-integrate (into v5,) I agree with priorities and I'll > second the addition of security to the list. Security through obscurity > is bad enough, but with open source projects, it simply becomes security > through ignorance. I certainly wouldn't trust vTiger's security in an > environment where the data is actually confidential and a malicious or > competitive party would stand to gain by accessing it illicitly. > > I don't have the availability to co-ordinate things, but you can count > on me for some quantity of bug-fixes, security patches, etc. > > peace, > nokes > > GIRONNAY Thibault wrote: > > Hi all, > > > > > > > > Matjaz I'll be with you and your team in your enterprise, I agree with > > your priorities and have one another to add : the security. The > > organisation sharing privileges for example is indeed totally an > > illusion. It's too easy too change those settings while not being admin > > or to see all records even if the privileges are private. I think this > > is very harmful to offer such buggy features and can discredit Vtiger > > for the people who have interests in security. > > > > > > > > Hope we'll have others hands up > > > > > > > > cabugs > > > > > > > > ------------------------------------------------------------------------ > > > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > > de* Matjaz.Slak at atol.si > > *Envoy? :* mercredi 19 juillet 2006 16:46 > > *? :* vtigercrm-developers at lists.vtigercrm.com > > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > > Integrator > > > > > > > > > > Hi Richie and the rest of the team! > > > > You address me correctly, Matjaz is my name :) > > > > > > As I belive the 4.2.x stream is the current "production" vTiger > > environment for most of the users, my primary goal would be to focus on: > > > > * debugging (fixing parts that either don't work at all and/or work > > incorrectly) > > * improving usability (based on feedback from users) > > > > > > I would also like to try and get the following not-quite-features, maybe > > > bugs? implemented/fixed: > > > > * multilanguage support (simply get rid of any and all hard-coded > > strings) > > * full per user or at least per-system localization support (number > > format, date format, currency support etc) > > > > > > These two last items are - in my opinion - somewhere between debugging > > and new features. vTiger is already supposed to support multiple > > languages, however this support is not well implemented. The same can be > > > said for localization - vTiger is supposed to be able to support > > per-user date format, but again there are areas where the implementation > > > is not as good as it could be. > > > > Also, based on my researches into existing vTiger deployments, I see > > there are a lot of non-english users, but they probably are using forked > > > code, as due to these two issues they cannot use the "official" 4.2.x > > stream code. I would like to get these users back on the team, and I > > know they might return only if we provide them with a 100% localisable > > product. This will enable them to post the patches they make back to the > > > community or at least give them an opportunity to work with us on > > resolving them. > > > > I would try and keep us on this track, rather than go try implement new > > features and make large changes to UI - the place for these is v5. > > > > > > To achieve this, I would first gather any and all contributions > > currently lying around (in the forum, as provided by other people here > > etc.) - matching the categories above - and start the process of getting > > > them in the code. *I would like to see a show of hands* from people that > > > would be prepared to devote some time to debugging/updating tthese > > contributions - as some might need an update. I know me and my > > colleagues in our company will. > > > > If all goes well, we could try and implement a regular timeline (say > > every month) when we would be releasing point versions. If I get at > > least two or three people to help, I guess we could have our first > > result (4.2.5 I guess) in two months. > > > > I think there will be people using the 4.2.x stream for at least a year > > after v5 is released, and that if we as a team show them we are > > supporting them, than they will upgrade to v5 -> if we don't they might > > start looking elsewhere. > > > > > > *Thoughts, anyone?* > > > > > > Matjaz Slak > > matjaz.slak at atol.si > > > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > > *Richie * > > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > > > 17.07.2006 16:57 > > > > Please respond to > > vtigercrm-developers at lists.vtigercrm.com > > > > > > > > To > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > cc > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > Subject > > > > > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > > Integrator > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matjaz! > > I hope I am addressing you properly if not please forgive me and direct > > to the proper mode of addressing. > > > > If you are game then great! > > Welcome to the club. > > Please select your stand-in helper so that at least we have a backup for > > > Linus Matjaz. Let me know and I will grant you the relevant access. > > > > It would be nice if you could briefly state how you plan to address the > > disparate contributions. This is just to get an idea as there are lots > > of data floating around in the code contributions and mailing lists; > > wanted to know if you have any specific plan. I will be busy with the v5 > > > release and will not be able to help you much so the query. > > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > > page which reflects the status of the contributions. I am not sure if > > that is updated till the 4.2.4 release though. > > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > > > > Allan, any tips from you will be nice. > > > > Richie > > > > > > > > > > ---- Sergio A. Kessler wrote ---- > > > > On 7/14/06, Matjaz.Slak at atol.si wrote: > >> > >> Hi! > >> > >> If there's no one else, I volunteer to be the v4 Linus. > > > > just do it. ;-) > > > > > > /sak > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > -- > > > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/411ae3e6/attachment-0001.html From don at vtiger.com Fri Jul 21 12:31:48 2006 From: don at vtiger.com (don) Date: Fri, 21 Jul 2006 09:31:48 -0700 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <10c91edb0e4.-4543952587404481040.-9186935435207679906@@vtiger.com> Hi DG, The logs given below are generated from the include/database/PearDatabase.php file. To avoid this kindly do the following: Edit the include/database/PearDatabase.php file and comment the following lines: -- $this->println("TRANS creating new connection"); in the function checkConnection -- $this->println("ADODB fetchByAssoc return null"); in the function function fetchByAssoc Hope this helps you. Kindly contact us for any further clarifications. Thanks & Regards, Don Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7714d42a/attachment-0003.html From jens at Strawberry.COM Tue Jul 18 03:02:14 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 07:02:14 -0000 Subject: [Vtigercrm-developers] Patches required for PostgreSQL 8.1.4 Message-ID: <20060718090201.B15699@Strawberry.COM> Hi, I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 database. Compared to mySQL this database seems to require some code changes. I've located and fixed the following problems: 1. SELECT count(*) count FROM ... won't work. The AS clause is missing: SELECT count(*) AS count FROM ... 2. Referring table columns in case of joined tables in the SELECT or ORDER BY clause requires the columns also to be listed in a GROUP BY clause. 3. tablename.* won't work in a GROUP BY clause 4. LIMIT #,# is not supported. PostgreSQL requires a single LIMIT and OFFSET clause. 5. PostgreSQL supports transactions. However the current coding results in transaction failures. I've attached my patches to this mail. Those patches at a first glance address the problems 1-4. The transaction problem is not yet fixed. I want to clean up the "simple" SQL statements first, before analyzing such complex things. I'm not a 100% satisfied with the patches, because they introduce some dbType dependencies into the "high level" vtiger code. Also structural information is required in the function which expands the queries by the required GROUP BY clause. I was thinking of moving those things to a more abstract layer, but stopped doing this, because a generic solution would either result in parsing and fixing each entire SQL statement (including all its features and possibilities) or a redesign of the affected SQL queries itsself. In most cases (especially the LIMIT changes) my patches might also work for mySQL, so the database dependency possibly could be removed. This might also apply to some of the GROUP BY patches. Hope those changes will find their way to the vtigercrm5 mainline. Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- A non-text attachment was scrubbed... Name: postgres-patches.tgz Type: application/octet-stream Size: 18385 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/e9b482c8/attachment-0001.obj From richie at vtiger.com Tue Jul 4 07:02:55 2006 From: richie at vtiger.com (Richie) Date: Tue, 04 Jul 2006 04:02:55 -0700 Subject: [Vtigercrm-developers] update bleeding edge svn Message-ID: <10c393477d3.4701894980957041264.-7646275652836694714@@vtiger.com> Hi Matt! Wanted to confirm if we have a script in place for updating the latest code in the vtiger-demo.fosslabs.com site? There have been forum queries if the updates are happening in the first place. Kindly inform. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060704/3631a295/attachment-0004.html From saint at vtiger.com Tue Jul 4 14:40:33 2006 From: saint at vtiger.com (Saint) Date: Wed, 05 Jul 2006 00:10:33 +0530 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings Message-ID: <44AAB621.8080701@vtiger.com> Folks, The following are the new "Settings" icons getting into vtiger 5. *Module * *Icon * Users Roles Privilege Profiles Groups Modules Access Fields Access Module Owners Announcements Custom Fields Picklist Editor Email Templates Mail Merge Tempaltes Notification Schedulers Inventory Notifications Inventory Terms & Conditions Company Details Mail Server Settings Backup Server Settings Proxy Server Settings System Information Invoice Configuration Audit Trail Tax Configuration Currency Settings Migration -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1968 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0098.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1951 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0099.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2197 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0100.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2328 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0101.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2134 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0102.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2319 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0103.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1925 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0104.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2267 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0105.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1883 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0106.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1957 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0107.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2160 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0108.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2175 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0109.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1975 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0110.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2264 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0111.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2370 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0112.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1732 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0113.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2121 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0114.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1972 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0115.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2182 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0116.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2492 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0117.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2546 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0118.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1796 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0119.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2441 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0120.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2451 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0121.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: set-IcoMigration.gif Type: image/gif Size: 2187 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0122.gif From sergiokessler at gmail.com Tue Jul 4 15:09:33 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 4 Jul 2006 16:09:33 -0300 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings In-Reply-To: <44AAB621.8080701@vtiger.com> References: <44AAB621.8080701@vtiger.com> Message-ID: <49216030607041209h171b32d1w9b6e737e1c65a5a8@mail.gmail.com> wow, beautiful ! /sak On 7/4/06, Saint wrote: > > > Folks, > > The following are the new "Settings" icons getting into vtiger 5. > > > Module > Icon > > Users > > > Roles > > > Privilege Profiles > > > Groups > > > Modules Access > > > Fields Access > > > Module Owners > > > Announcements > > > Custom Fields > > > Picklist Editor > > > Email Templates > > > Mail Merge Tempaltes > > > Notification Schedulers > > > Inventory Notifications > > > Inventory Terms & Conditions > > > Company Details > > > Mail Server Settings > > > Backup Server Settings > > > Proxy Server Settings > > > System Information > > > Invoice Configuration > > > Audit Trail > > > Tax Configuration > > > Currency Settings > > > Migration > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From don at vtiger.com Wed Jul 5 11:59:39 2006 From: don at vtiger.com (don) Date: Wed, 05 Jul 2006 08:59:39 -0700 Subject: [Vtigercrm-developers] vtiger CRM 5.0 Beta2 Released Message-ID: <10c3f6a8177.-9001623588305850621.-4297454805191080021@@vtiger.com> Hi All, We are pleased to announce the release of vtigerCRM 5.0 Beta 2. In this release the main focus is on the quality front and we have fixed most of the major bugs that were in the vtigerCRM 5.0 Beta. We have also incorporated most of the feedbacks/suggestions given by the community over 5.0 Beta. In the UI front, the Settings UI has been totally revamped. This release will depict the developments done after vtiger CRM 5.0 Beta. You can give it a try and let us know your valuable feedbacks and suggestions. The live demo of vtigerCRM 5.0 Beta is available at http://vtiger.com/products/crm/demo_5beta/index.php You can download the vtiger CRM 5.0 Beta2 from the following URL : http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=196218&release_id=429844 You can post your feed backs and suggestions at http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Thanks & Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/59d438e1/attachment-0002.html From nico.gnauck at googlemail.com Thu Jul 6 13:12:58 2006 From: nico.gnauck at googlemail.com (Nico Gnauck) Date: Thu, 6 Jul 2006 19:12:58 +0200 Subject: [Vtigercrm-developers] Merge with OpenOffice documents Message-ID: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Hello, I'm currently working on a Mail Merge for version 5.0 with Open Office Dokuments based on the rtf Merge for version 4.2.3. You can find the thread and the Merge skripts for Accounts and Contacts in this thread: http://forums.vtiger.com/viewtopic.php?t=7223. If anybody has time to test this, please do so and give me feedback. Thanks, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/776050fd/attachment-0004.html From mmbrich at fosslabs.com Thu Jul 6 13:32:44 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 06 Jul 2006 11:32:44 -0600 Subject: [Vtigercrm-developers] Merge with OpenOffice documents In-Reply-To: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> References: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Message-ID: <1152207165.22922.96.camel@localhost.localdomain> Hi Nico, I haven't had a chance to test yet but I did merge this into my vtiger5 branch in the branches/ directory of the SCM system. I will get it tested as soon as I can, from there the other developers can decide if it should be merged into trunk/. If you find/fix issues in this branch please post the patches here and I will get them merged in. If you have enough issues and would like, I can set you up with commit access to my branch. Thanks for your contribution! Matt On Thu, 2006-07-06 at 19:12 +0200, Nico Gnauck wrote: > Hello, > > I'm currently working on a Mail Merge for version 5.0 with Open Office > Dokuments based on the rtf Merge for version 4.2.3. > You can find the thread and the Merge skripts for Accounts and > Contacts in this thread: > http://forums.vtiger.com/viewtopic.php?t=7223. > If anybody has time to test this, please do so and give me feedback. > > Thanks, Nico > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Thu Jul 6 16:17:20 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Thu, 06 Jul 2006 16:17:20 -0400 Subject: [Vtigercrm-developers] Trac 0.9.6 released Message-ID: Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. From richie at vtiger.com Fri Jul 7 01:22:12 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:22:12 -0700 Subject: [Vtigercrm-developers] trac account Message-ID: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/f616fb9d/attachment-0002.html From richie at vtiger.com Fri Jul 7 01:25:43 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:25:43 -0700 Subject: [Vtigercrm-developers] update svn-version Message-ID: <10c4772d440.733718465091492167.4729172311574536110@@vtiger.com> Hi! Got this mail in the forums. Can someone do the needful please? Jeff, what do you say? "Hi forum users and especially vtiger admins, im not quite sure, if this is the right place to post, but i think you guys should really consider updating your subversion server to > 1.2.x. For us developers using eclipse it's painstaking to get it to work well, because the svn plugin (subclipse.tigris.org) only supports the old svn servers (< 1.2.0) only if you choose to install a very old version of the plugin (< 0.9.3.0). Unfortunately, this version of the plugin is very buggy, and i can't get it to work properly in my env, especially with eclipse 3.1. It maybe a little selfish to request an update, just because of me not getting my setup to work, but svn has improved so much from 1.1.x to 1.2.x so it might be usefull for everyone. Regards Benjamin" Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/606fa218/attachment-0004.html From richie at vtiger.com Fri Jul 7 01:28:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:28:56 -0700 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com Message-ID: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Hi! Is the vtiger-demo.fosslabs.com updated with the bleeding edge code please? Matt, I guess, we are putting a lot of stress on you alone and it is not fair. Do you think you require some guys from the community to assist you? My main concern is that not any single individual be overloaded. vtiger is team-work and it should be that way. Everyone should prosper. Dedicated volunteers please raise their hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/4782857f/attachment-0002.html From richie at vtiger.com Fri Jul 7 01:31:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:31:56 -0700 Subject: [Vtigercrm-developers] Trac 0.9.6 released In-Reply-To: References: Message-ID: <10c47788588.1738553798220722432.6769330270375144874@@vtiger.com> Let us get this upgraded then. Jeff, would you take ownership for all the 3rd party upgrades please. I know you are already tracking the 3rd party packages but what I am stating is to take ownership for all upgrades for the s/w used to keep track of vtiger? If you need assistants, give a shout in the mailing list. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/1aaf8fb0/attachment-0004.html From webmaster at vtigerfacile.com Fri Jul 7 09:40:11 2006 From: webmaster at vtigerfacile.com (=?UTF-8?B?QcOvc3Nh?=) Date: Fri, 07 Jul 2006 15:40:11 +0200 Subject: [Vtigercrm-developers] trac account In-Reply-To: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Message-ID: <44AE643B.1040800@vtigerfacile.com> Hi Richie, i have a login for track, but not the right to submit ticket. thanks, A?ssa (very busy !) Richie a ?crit : > Hello! > > I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. > Please cross-check if you have received the relevant mails in the id from which you had made the access > request. > > Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. > > richie at vtiger dot com > > Richie > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Fri Jul 7 23:23:02 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 21:23:02 -0600 Subject: [Vtigercrm-developers] New communications system Message-ID: <1152328983.32174.36.camel@localhost.localdomain> I wrote a new CommSystem module in my 5.0.2-MMBRICH branch. The comm system is a full replacement for the chat system from RC1 and also adds a host of API's to manipulate it from your favorite external system or vtiger module :). Here is a short list of features, any testers or patches to help move it along are appreciated. Features: 1) Full P2P chat 2) Session/Off-line messaging capabilities (ie: if a new message comes in right when you click on a link in the system, when the new page loads you will see the message that appeared as the page was being reloaded). 3) Follows your window focus. If you have multiple tabs open in the CRM, you will only get new messages and status messages in the focused window. All messages are cached when there is no focus on a CRM window. 4) Alert/Event messages. An "MSN like" status box that appears at the bottom of your browser to alert about new emails, voicemails, incoming calls, etc. It has pretty effects to make it slide in and out for alerts :). 5) "User is typing" status messages. 6) Email messages from either periodic checks via JSON or can also be injected via scripts. (Ie: incoming emails to helpdesk at domain.com could be announced to users x,y and z) 7) Simple CommSystem.php and CommSystem.js classes to manipulate the alerts and chat system. CommSystem.js is wrote to follow prototype standards as much as I could get it to. ToDo: 1) Finish the group IM feature. 2) Lots of ugly, needs UI work. 3) Support Portal integration ("Chat with Live Help" links in the portal) 4) Message archives so that old messages can be deleted from the CRM (maybe a monthly cron script to backup and delete the messages from the DB). 5) Asterisk AGI Script and SOAP functions to inject Voicemail or Incoming call alerts 6) Cron scripts to populate email alerts? 7) Fix annoying bugs (Ie: '\n\r' breaks sending messages) 8) Internationalization 9) Test, test, test 10) Jabber connector? Drawbacks to this system: 1) Makes a request to the server every N milliseconds to check for new messages, alerts or status updates. This gets heavy on the server. One way to take load off the server is with the focus tracking mentioned above. Un-focused windows will not make requests back to the server. Another way is to create a decay timer like the one used in the prototype Ajax.PeriodicalUpdater() class. This basically checks the last output status and compares it to the current output status. If they are the same then N = (N*) and if the current output status is diff than the last output status N=(N). 2) The whole system is one large timer loop and global references to the CommSystem.js class have to be created to access the class within the loop. This is a memory usage issue but shouldn't be too noticeable for most. 3) Probably a 70% client side and 30% server side system. Thats a lot of javascript. If you get a chance to check it out, let me know what you think and if you'd like to see something like this in vt5 going forward. Matt From mmbrich at fosslabs.com Sat Jul 8 00:15:14 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 22:15:14 -0600 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com In-Reply-To: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> References: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Message-ID: <1152332114.32174.40.camel@localhost.localdomain> On Thu, 2006-07-06 at 22:28 -0700, Richie wrote: > Hi! > > Is the vtiger-demo.fosslabs.com updated with the bleeding edge code > please? I updated it the day RC1 came out but haven't since then. It is currently not automated. > Matt, I guess, we are putting a lot of stress on you alone and it is not fair. > Do you think you require some guys from the community to assist you? > > My main concern is that not any single individual be overloaded. vtiger is team-work and > it should be that way. Everyone should prosper. The workload isn't too bad yet but any help is more than welcomed! > Dedicated volunteers please raise their hands! Matt From richie at vtiger.com Mon Jul 10 08:36:35 2006 From: richie at vtiger.com (Richie) Date: Mon, 10 Jul 2006 05:36:35 -0700 Subject: [Vtigercrm-developers] move to trac-0.9.6 Message-ID: <10c58706195.1364243099676550119.-2686427800793695304@@vtiger.com> Hi! Anyone game to help us move to trac-0.9.6 so that we can utilize the latest and greatest features? Matt, send me a mail with the access to the machine. Also let me know what steps to follow to upgrade. If no one does it, I will have it done. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/cc4fdd2a/attachment-0002.html From mmbrich at fosslabs.com Mon Jul 10 17:09:03 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 15:09:03 -0600 Subject: [Vtigercrm-developers] UI help Message-ID: <1152565743.32174.120.camel@localhost.localdomain> In case no one noticed in the past I suck @ UI design so I figured we would see who wants to step up to the plate on this one. Right now I need the following things, if you want to take one just say so that way no one else duplicates your work. 1) De-Duplication system for settings module. I want this to be able to delete/merge/etc records that can be matched based on certain criteria. I'll write the search engine and logic system to merge/de-dup if someone wants to take on the UI :). I was thinking about having this work in steps. Step 1: select search criteria. Step 2: display duplicate results that are candidates for merge/delete, un-select records from the list via checkbox. Step 3: Select fields to merge or other action to take (delete). Step 4: Execute actions. There was a bounty on this in the forums. If that pans out you'll get a chunk, let me know what you think is fair for your time/effort. 2) Geolocation/Action tracking for email campaigns. This will be a simple popup window that should show a list of the commands from that email (ie: open, followed link, unsubscribed, etc) in one html tab and then the google map to show the actual locations those commands were executed at in another tab. Most likely I will just push one XML descriptor up to google maps to display the country/state/town the email was opened in, but I want to be able to push multiple XML descriptors to google in cases where more than one location is tracked. These extra descriptors can be used to mark possible forwards for that email. Along with this feature we'll need a simple settings area to input your google maps key. 3) Default email unsubscription page. This is a simple page that is visited when a user clicks on the 'unsubscribe' link in emails. The page should have a nice header, a hello message or something, give the user a choice to unsubscribe from that campaign or from all lists in the CRM and then display a success or failure message depending on the result from the CRM's attempt to remove them. If the unsubscribe fails the page should display the company info from the DB so that the user can write in or call to have their information removed. 4) Workflow module? I thought I saw a post that the vtiger crew was going to take this on. If thats the case then this one is void and we don't need to worry about it. Otherwise, go check out the bounty, let me know what you think is a fair cut for your work, then submit me your ideas. If the bounty pans out you'll get a cut of course. 5) Communications system. This is built and ready enough for beta. I need a p2p chat window, group chat window, right hand 'slider' (to show who is online, etc) and we should probably do something with the alert slider as well, it's very plain. The fun part about the chat windows is that none of them are built with HTML so you'll have to do most of the design in CSS. You can also look into the scriptaculous Builder() function for more info on how I create the chat windows, there is flexibility in how you can design them so you're not necessarily restricted to css only. Also could use a chat window for the customer portal if you're up to it :). 6) Direct Mail Designer. This is still on the drawing board but it would be super cool. The idea is to have a list of templates in the "Direct Mail" campaigns that could be merged with the campaign records. Sounds familiar right? Well it would build off of the current merge system by allowing .rtf and .odt files to be merge templates but would also make use of a 'packaging' standard. Basically this packaging (a tarball or zip file) would have a templatename.xml file that would have things like params and thumbnail images and other useful information for merging, etc. This has the ability to have services packaged around it (like we could define an API for designers to make their designs available for pre-set prices and also printing companies to actually do the printing.) Lots of possibilities, if you decide this one is interesting, email me on or off list and we can start a discussion about how this could work. This is candidate for a forge project so if there is enough interest I might just open one. All of this stuff is being created in my branch. I'll give you access to my sandbox area on vtiger-demo.fosslabs.com so you can track stuff and help out. I have every intention of doing these myself if no one takes them, but I can say that I have no skill in UI design whatsoever :). Matt From mmbrich at fosslabs.com Mon Jul 10 23:58:53 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 21:58:53 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590333.16985.2.camel@localhost.localdomain> This is an example screen of what I would like to do for managing campaign actions. If there is a way to tell the campaign type, even when using a diff language or changing the picklist, then I wouldn't have to show every single action. Opinions? Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-24.png Type: image/png Size: 66134 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/86b7c2be/attachment-0002.png From mmbrich at fosslabs.com Tue Jul 11 00:02:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 22:02:49 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590570.16985.4.camel@localhost.localdomain> Here is a screenie of the current comm system if anyone wants to give suggestions. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-25.png Type: image/png Size: 77505 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/854ed82e/attachment-0002.png From dgrant at accuratetechnologies.com Tue Jul 11 14:12:38 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 11 Jul 2006 14:12:38 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG From jtk at yahoo.com Tue Jul 11 17:12:32 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Tue, 11 Jul 2006 17:12:32 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone From sergiokessler at gmail.com Tue Jul 11 18:37:23 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 11 Jul 2006 19:37:23 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> dennis, On 7/11/06, Dennis Grant wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak From mmbrich at fosslabs.com Tue Jul 11 21:58:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 19:58:10 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <1152669490.16985.122.camel@localhost.localdomain> > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt From mmbrich at fosslabs.com Wed Jul 12 00:06:12 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:06:12 -0600 Subject: [Vtigercrm-developers] 5.x webmail changes Message-ID: <1152677172.16985.144.camel@localhost.localdomain> I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt From mmbrich at fosslabs.com Wed Jul 12 00:20:56 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:20:56 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152590570.16985.4.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> Message-ID: <1152678056.16985.149.camel@localhost.localdomain> I'm going to keep posting these hoping that someone will finally get fed up with the ugly and help out ;). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-26.png Type: image/png Size: 90999 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-27.png Type: image/png Size: 67631 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0007.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-28.png Type: image/png Size: 90831 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0008.png From saint at vtiger.com Wed Jul 12 02:09:35 2006 From: saint at vtiger.com (Saint) Date: Wed, 12 Jul 2006 11:39:35 +0530 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152678056.16985.149.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> Message-ID: <44B4921F.8020402@vtiger.com> Matt.. I am aware that, the campaigns module is fairly attended in the UI front. I am in the middle of other works. So give me a few more days.. I will hop in and check it out :-) -Saint Matthew Brichacek wrote: > I'm going to keep posting these hoping that someone will finally get fed > up with the ugly and help out ;). > > Matt > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90999 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0012.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 67631 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0013.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90831 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0014.png From dgrant at accuratetechnologies.com Wed Jul 12 09:41:28 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 12 Jul 2006 09:41:28 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) { bar; } vice if ($foo) { bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG From sergiokessler at gmail.com Wed Jul 12 09:48:28 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Wed, 12 Jul 2006 10:48:28 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From jtk at yahoo.com Wed Jul 12 10:06:57 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Wed, 12 Jul 2006 10:06:57 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). From mmbrich at fosslabs.com Wed Jul 12 11:16:41 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:16:41 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <1152717401.16985.280.camel@localhost.localdomain> On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt From mmbrich at fosslabs.com Wed Jul 12 11:48:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:48:52 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <1152719332.16985.289.camel@localhost.localdomain> I have started doing the query part as I run into them in my branch. I'm also moving the query strings out of functions like get_leads() and putting it in get_related_leads_query() instead. This way the query can be used for other things.. like for example if you want mostly the same output of get_leads() but without the HTML that manged to find its way out of the presentation layer and into the data layer... don't get me started on that. Anyways, with the HUGE db query strings that are used in the system, breaking them into separate short lines is a great suggestion for manageability and if it makes merges easier it's like getting your cake and eating it too :). Matt On Wed, 2006-07-12 at 10:06 -0400, Jeff Kowalczyk wrote: > Dennis Grant wrote: > > Actually, I think with VTiger you are going to see a lot of private > > forks, because individual businesses have their own needs and wants that > > are supersets of core VTiger functionality that simply don't apply to > > other businesses. > > This is one of the reasons why I care about making the source more > merge-friendly (particularly short, vertically formatted SQL statement > string lines). > > If we can get the codebase to the point where branching and merging is a > manageable burden, customization branches have a fighting chance to be > maintained in the repository. Or use a distributed repository such as > bazaar-ng can be used (bzr has a trac backend now). > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 13:16:13 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 11:16:13 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <44B4921F.8020402@vtiger.com> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> <44B4921F.8020402@vtiger.com> Message-ID: <1152724573.16985.290.camel@localhost.localdomain> Gracias, in the mean time I will keep working on the back-end and breaking stuff. Matt On Wed, 2006-07-12 at 11:39 +0530, Saint wrote: > Matt.. > > I am aware that, the campaigns module is fairly attended in the UI > front.I am in the middle of other works. So give me a few more days.. > I will hop in and check it out :-) > > -Saint > > > > > Matthew Brichacek wrote: > > I'm going to keep posting these hoping that someone will finally get fed > > up with the ugly and help out ;). > > > > Matt > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > ____________________________________________________________________ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 23:39:08 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 21:39:08 -0600 Subject: [Vtigercrm-developers] vtiger.fosslabs.com maint Message-ID: <1152761948.16985.311.camel@localhost.localdomain> I am going to shut the vtiger.fosslabs.com machine down this weekend for hardware upgrades. When I bring it back up I plan to snapshot and upgrade SVN. Expect the access to the system to be spotty over the weekend. I am tentatively scheduled to do the work on Saturday evening @ 11PM MST but that may change depending on other upgrades being done at the same time. Matt From richie at vtiger.com Thu Jul 13 04:43:03 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:43:03 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670da880.830325448603459473.-9072372394275150906@@vtiger.com> Hi DG! Your comments are well taken. These will be in place at the earliest. I know that this will be a quick fix but instructions have been sent across to have the code properly commented from now on for any future development/bug fixes. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/488cba6b/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:44:36 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:44:36 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670f131a.7768422503650913231.-7005067799642887197@@vtiger.com> I am game for it . Any takers? What is the procedure and how do we guarantee that there are no breakages? Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f2aae45a/attachment-0004.html From richie at vtiger.com Thu Jul 13 04:46:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:46:05 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <10c67107064.-1678188602298141788.6045287401021222103@@vtiger.com> I second /sak. Contribute your code and we will have it in the 4.2.x branch and then have it subsequently ported to the 5.x too. We could have done it much earlier but it is far too late to get any contributions into 5.x at this stage. As far as possible, keep your changes in separate files so that they can be function invoked from the core code. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- dennis, On 7/11/06, Dennis Grant <dgrant at accuratetechnologies.com> wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/8bd60cb5/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:49:51 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:49:51 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <10c6713e13e.2152742122979094039.4943172801070965118@@vtiger.com> I agree with Matt. We have just started to work on a API-basis. The APIs will be difficult to use initially no doubt. I expect the APIs to be APIs like by 5.2 only as it is a huge change in mindset. Moreover, whatever APIs we have now, have to be properly documented and made much more usable. Matt has pointed out quite a few lacunaes and I do assure you that we do intend to fix them. Guidance and direction on the implementation toward achieving the same are welcome. To all System Integrators, yes, I do understand your pain. But, please understand getting rid of legacy code is much easier said than done. As of now, we will have to live with what we have. Post 5.0, we will make appropriate changes. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/889d7c68/attachment-0004.html From richie at vtiger.com Thu Jul 13 04:51:01 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:51:01 -0700 Subject: [Vtigercrm-developers] 5.x webmail changes In-Reply-To: <1152677172.16985.144.camel@localhost.localdomain> References: <1152677172.16985.144.camel@localhost.localdomain> Message-ID: <10c6714f425.4775035562108243105.2718638484930626999@@vtiger.com> No probs Matt. If it does not work, let us give what works the best way we can. We will revisit this later. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/23b5e029/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:54:53 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:54:53 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c67187bff.-5041963494012382301.4384583989565056693@@vtiger.com> I take all your comments with eyes closed. Kindly expect the changes asap. Please do refer to my prev mail. Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless. So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now. The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) {  bar; } vice if ($foo) {  bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/6f714b17/attachment-0004.html From richie at vtiger.com Thu Jul 13 04:56:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:18 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <10c6719c9f2.-6173366446330663734.-8914245299430889257@@vtiger.com> Well, well, /sak, hold on! We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)! Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/609744b4/attachment-0002.html From richie at vtiger.com Thu Jul 13 04:56:58 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:58 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c671a6747.4209201887890377357.8473992930050161702@@vtiger.com> Ok Jeff. This is new to me. Guide me on this. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/1901e1ee/attachment-0004.html From richie at vtiger.com Thu Jul 13 04:58:39 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:58:39 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152717401.16985.280.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> <1152717401.16985.280.camel@localhost.localdomain> Message-ID: <10c671bf103.1188771339393133750.-7786000437306059540@@vtiger.com> I agree with you Matt. I will post a separate mail to have the private forkers to have their codes submitted for integration to whichever trunk needed. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/dca318ca/attachment-0002.html From richie at vtiger.com Thu Jul 13 06:46:19 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 03:46:19 -0700 Subject: [Vtigercrm-developers] Calling all private 4.x development owners Message-ID: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Hi! This is a call to all the 4.x private development owners. Many of you would have been working on your own version of vtiger as you would have customized it to your own needs. This is a call for those guys. The intent is to aggregate most of the common features that you have built and have them integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch or even in the 5.x branch as needed by the community. Pros: By doing the above, you will be able to be in sync with the latest and greatest developments happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a read as one would think of but we are working on it. Yesterday we had comments about the code not being properly commented, we are working on that right now even as I type this post. So, the idea I am conveying is that we are not perfect but are listening to the comments and taking actions too. Hence, please do keep the faith. Cons: By maintaining your own code bases, you lose out on the community benefits like identifying bugs, feature integration, new ideas, etc. We welcome your contributions. Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise the folly. Let us get on with it and make vtiger a success. I have learnt from my past mistakes. Join the team, come on board. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/65c2edda/attachment-0004.html From dgrant at accuratetechnologies.com Thu Jul 13 10:47:52 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 10:47:52 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... Yeah, but is it worth it? The 4.x codebase is really - sorry guys, I don't mean to take shots at you - but let's face it; it's really very nasty. Some of it is a good deal better than others... but there are three or four different coding paradigms all mixed together just on database queries alone, never mind display models and modularity and whatnot. It *works* great, but it's a serious bitch to maintain. As I mentioned earlier, I haven't looked at the 5.0 codebase, but it is my hope and expectation that it is a lot better. > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, No kidding.... > and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > I mean, if you are going to fork, then fork in all it's glory... Dude, I *NEVER* wanted to fork. I'd be *MUCH, MUCH* happier if I could run a vanilla install of VTiger with zero custom code in it. I was forced into forking by a lack of response from the core dev team, yes - but more so by the fact that I had users who wanted features and I needed to get them done NOW. > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Ahem. I tried to get patches into the core. I tried to get the dev team to do stuff by reporting bugs and providing detailed debug info. But there are limits as to how much time in a day I can burn trying to get an unresponsive dev team to fix my bug. "Why is this still broken?" "Well, I reported it to VTiger last month, and they haven't fixed it yet....." That just doesn't cut it. > My point was that we should find > a way to welcome these wayward forks back to the fold. How? I dunno.. Well, the way I'm going to do it is to roll all my features into 5.0 (which is a huge job, but so it goes) and then cut a patch set for merging into the main core. My expectation is that VTiger's version of Linus (or Alan Cox, or whoever) will then go through the patch set, and then either merge or reject patches based on merit - just like in the kernel. I will then work on trying to address concerns with my rejected patches, so as to get them accepted, except in cases where the patch is clearly local in scope - and those I will maintain myself. BTW, who is the local Linus? > So after the wind clears.. my point really comes down to getting all > these folks who are working on private forks to come back to the > community project, regardless of their justification (or lack of) for > the fork. In an OSS project your most valuable resource is your > developers and if we can find a way to get them back it will be well > worth it IMHO. I agree - and the best way to do that is to be RESPONSIVE. I understand that *my* problem may not be the top priority. I understand that core dev team members are NOT going to just drop everything and look after me. But I *do* expect a response, and to get into the pipeline, and to be given reasonably regular status updates on the status of my problem. And if I submit a patch, I expect it to be reviewed and either accepted or rejected in a reasonable timeframe. I don't know how many of you were/are involved in Linux kernel development, but I used to get help from people like Alan Cox and Linus on a regular basis. If a particular bit of hardware wasn't working, and it looked like a bug in Linux kernel code, we'd trade emails on a daily basis to debug the problem. That's the level of service we're talking about. And this is a good start: > Your comments are well taken. These will be in place at the earliest. > I know that this will be a quick fix but instructions have been sent > across to have the code properly commented from now on for any future > development/bug fixes. Thanks! DG From sergiokessler at gmail.com Thu Jul 13 11:40:25 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Thu, 13 Jul 2006 12:40:25 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> Message-ID: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak From allan.bush+vtiger_dev at gmail.com Thu Jul 13 11:59:48 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Thu, 13 Jul 2006 08:59:48 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From dgrant at accuratetechnologies.com Thu Jul 13 12:10:09 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 12:10:09 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CD8@exch.accuratetechnologies.com> > > BTW, who is the local Linus? > unfortunely, there is no local linus, Who is in charge of V5? Who is the core dev team leader? > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) Uh... thanks, but I'm going to have to pass. At this point, with V5 (seemingly) approaching completion, V4 is a dead end. I intend to move forward on V5 and get away from V4 as fast as I can. DG From jeri at vtiger.com Thu Jul 13 21:04:37 2006 From: jeri at vtiger.com (Jeri John) Date: Thu, 13 Jul 2006 18:04:37 -0700 Subject: [Vtigercrm-developers] Latest Docs updated Message-ID: <10c6a904f47.6172353167700401689.-5432537231218327818@@vtiger.com> Dear team, The latest Docs for vtigerCRM 5.0 beta 2 is updated, and it is available in the following url. http://vtiger.com/products/crm/phpdocs/index.php Thanks & Regards, Jerry. ------------------------------------------ D.Jeri John Skype: jerijohn_vtiger Toll Free: +1 877 788 4437 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f9eb2259/attachment-0002.html From mmbrich at fosslabs.com Thu Jul 13 21:16:45 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 19:16:45 -0600 Subject: [Vtigercrm-developers] Custom fields for activities Message-ID: <1152839806.16985.560.camel@localhost.localdomain> Does anyone have plans to implement custom fields in the activities module? Matt From mmbrich at fosslabs.com Thu Jul 13 22:16:38 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 20:16:38 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <1152843399.16985.611.camel@localhost.localdomain> I have some ideas for cleaning up the structure of vtiger as we move forward. I am just going to lay them out here, let me know what you think. My basic idea comes down to writing wrapper classes that are used to abstract most of the unnecessary functions from developers and instead provides a uniform API to access modules, permissions, input, etc. The idea comes in three pieces. Common UI classes, most of which is already done with the new UI. A "mainframe" engine similar to the joomla $mainframe. And last but certainly not least is an entity engine that would abstract most of the entity details from developers and truly provide the unified API. Lets start with the big one, Entity Engine: The entity engine would be accomplished in three steps. The first step is to move all common variables and functions into the EntityEngine class (which extends CRMEntity). The entity engine would go into the DB to populate these with the correct info. For example tab_name, tab_name_index and all the other most common variables would be stored in the db and populated when the entity engine has a request for that module. The next step would be to create common set of functions in this class that would be exposed to the developer. The initial functions I can think of are things like get/set functions for different field values, etc. The last step to the entity engine would be an XML install system. If a developer came along and wanted to create a simple data collection module, like the current campaigns module, they would simply create an XML file that defines all the fields to be displayed, what relationship types are allowed, etc. The entity engine would then create the correct tables, populate the needed tables for the entity engine (the ones holding tab_name, etc) and register the new entity type with the system. This leads into the UI system because if the developer is just creating the XML file, how are common views displayed (list, detail, edit, relatedlists)? The UI system would be a set of classes to extend smarty and again abstract the gory details of the internal workings from the developer. VTigerUI::DetailView($entity) would follow a flow: 1) Display all common elements (header, etc): $this->createTigerHeader(); 2) Display the common 2 tab display for edit/detail/related views $this->getCommonUI("DetailView"); 3) Create a block for each block type in the DB, and create the fields for it as well. $this->assign("NUM_BLOCKS",sizeof($entity->blocks)); foreach($entity->blocks as $blockid=>$fields) { $block_fields = array(); foreach($fields as $fieldname=>$field_data) { $block_fields = $this->CreateEditField($fieldname,$field_values); // creates new edit fields based on uitype and returns an array as $array[sequence_number] = "HTML output" } $this->assign("BLOCK_".$blockid,$this->addBlock($blockid, $block_fields)); } 4) Display data :) And just like magic, the ListView, DetailView, EditView and CallRelatedList files can all go away and these common views can be managed in a much easier way. Next, the mainframe. In joomla (as far as I understand) the mainframe is meant to handle all GET, POST, REQUEST and SESSSION variables and it also sanitizes that input before giving it to the developer ($mainframe->get_input("REQUEST","data")). On top of this it handles some user security and other things. In vtiger I could see it being used for many similar things. Take for example the CreateDetailField() function call above. Inside of this call would be: if($mainframe->is_allowed("Detail",$field->id)) { stuff.. else return; There are still other details to be worked out, but you see that this isn't a _really_ large change for the flexibility it will give you in the system. After it's all said and done you should have two sets of documents that a developer would have access to, the module developers document that would be a document outlining the three pieces discussed above and then the core developer document that would document all the core back-end functions (everything in utils/). Of course there would be a way to overwrite these methods so that developers can still create non-entity based modules (webmails, calendar, rss, etc), but it should make life much easier for module developers who follow the entity structure in vtiger. What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well. Matt From Matjaz.Slak at atol.si Fri Jul 14 02:42:52 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:42:52 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: Hi! If there's no one else, I volunteer to be the v4 Linus. I have the exact same position as a lot of other people wrote about here - basically my own fork of v4.2.3, and I'm now working to get my patches compatible with v4.2.4 so as to get back to the main trunk. And it's a lot of work, which I need to trade with my basic task - which is supporting several customers we have on vTiger. I hope I will have my set of patches (there might be up to 100 of them, as it's looking right now :) ready in a week or so. I belive we as vTiger Dev team should provide more support for 4.2.x stream -> I guess that almost ALL of vTiger's "real world" users use that right now. And they might go for v5 when it's stable, but that won't be (in my experience) for at least 6 months after it's released. If you want me, I'm here. Just give me a direction to start in, and I (and my three colleagues here) can be reviewing submitted work in no time. And discussing it with you the team here to get decissions on include/reject. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Sergio A. Kessler" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:40 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0002.bin From Matjaz.Slak at atol.si Fri Jul 14 02:43:51 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:43:51 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> Message-ID: Hi! Allan, if you need any help, let me know (see my previous post). Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Allan Bush" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:59 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0002.bin From dgrant at accuratetechnologies.com Fri Jul 14 09:24:34 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 09:24:34 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG From allan.bush+vtiger_dev at gmail.com Fri Jul 14 10:32:02 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 07:32:02 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Proper use of a OO design would solves this for both of you. All the common code and default module behavior should be moved into the a set of default classes or "engines" as Matthew is calling them. Then for each module we inherit the classes and make a couple method calls (ideally this is abstracted as well so to create a module all you do is create a class which inherits the base class) which generates the required database actions / html page. If you want something different then the default, like Dennis describes, you simply extent the required method in your inherited class. This way the common code is abstracted and only needs to exist once while the module specific code is in the module for easy modification. The code is already partly structured this way (it's just not used properly). There's already a base class CRMentity which every module inherits from. What needs to be done is to clean up the CRMentity - module relationship so that only methods common to all modules and their default behavior is defined in CRMentity and only things which need to be changed are defined in the module class. Then we need to create a class for each page type (again some of this already exists. ala inculdes/Listview.php, but here it isn't used at all) with the default behaviors of each page type. Now we have an option, either we have each module inherit these page type classes (making changes as needed ala CRMentity) and have a common set of calls to render each page type or we create a SMALL file in each module with a couple of calls to the page type class to render the page and we substitute new functions as needed for customizations. Personally I think the first option here is the better design, but unless you get it right it could become difficult to modify the parts of the page you want without re-witting a lot of the base class (should be avoided at all cost or we're right back in the mess we are in now). That was a bit of a long winded explanation, let me know if anyone requires clarification. On 7/14/06, Dennis Grant wrote: > > > My basic idea comes down to writing wrapper classes that are used to > > abstract most of the unnecessary functions from developers and instead > > provides a uniform API to access modules, permissions, input, etc. > > Oooh. > > > The idea comes in three pieces. Common UI classes, most of which is > > already done with the new UI. A "mainframe" engine similar to the > > joomla $mainframe. And last but certainly not least is an entity > engine > > that would abstract most of the entity details from developers and > truly > > provide the unified API. > > To be honest, I think this is moving in the wrong direction. > > If everybody used the same vanilla VTiger installation, this would make > a lot of sense - one common UI for the entire set of users, and a much > cleaner codebase for developers. Happy happy for everybody. > > Unfortunately, a lot of us are NOT using vanilla VTiger; we have to > customize the application to meet the needs of our user base. And a lot > of the time, our users really really want changes that may seem utterly > trivial from a developer standpoint, but for whatever reason, they > REALLY want it that way. > > And the customer is always right, so we have to do it. > > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. > > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. > > Yes, it makes changing common code more difficult, 'cause now I have to > drill down into each submodule and make the same change over and over > again, and I can certainly see where modularizing and sharing code makes > that job a lot easier. But the assumption it is based on, while true of > a vanilla install, is NOT true in a customized install environment. > > I'd prefer to see every module live in its own subdirectory of the > modules directory, much as is does in 4.x, but more rigorously (ie, > separate Sales Orders from Purchase Orders, don't group them in Orders) > and each module should have its own, atomic codebase. > > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. > > I'd like to see some standardization on the module file structure > though: > > modules/Foo/EditView.php for the edit UI for the module object > modules/Foo/DetailView.php for the detailed view of the object > modules/Foo/Save.php for saving the object to the DB > modules/Foo/CreatePDF.php for creating a PDF version of the object > modules/Foo/UIElements.php for the common UI functions (that are now > stuffed in include/utils.php > modules/Foo/BarPopup.php if there is a popup window to select associated > Bar objects > > etc. > > It makes dealing with modules easier if we know where the various > functions are kept. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From isimpkins at premierrealm.com Fri Jul 14 11:10:32 2006 From: isimpkins at premierrealm.com (Ivar Simpkins) Date: Fri, 14 Jul 2006 17:10:32 +0200 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: Sorry DG this doesn?t wear with me. 'The price of programmability' is what it's about. There is the short term solution and it has its merits, but planning a structured API can only have its long term benefits. Where does vTiger want to be in the future, this has to be answered. If it wants to be in the top ratings, then I think every effort has to be made, to reconsolidate and then plan for the future. Sure the learning curve is steep but the rewards are enormous. Would it not be better to prefect a generic function, in an OO structure which does all you want, one entrance, one exit and away you go. A well documented code base that automatically builds your API documentation gives you a valuable toolbox, now concentrate the communities efforts on pulling together and raising the lowest common denominator and you have a work the progresses moving a an incredible rate. And as Matt said: 'What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well.' NO, you are not nuts, it gives you the long term ability to use ones creativity to best avail without (always) having to worry about the nuts & bolts. I think this is a courageous step in the right direction, where, after surviving the learning curve, all will benefit, creating a homogeneous standardised kernel, with the ability of Plug 'n Play ala Joomla and probably much more. 'The price of programmability' is high but seeing the caliber of work produced so far, I am convinced Matt is on the right track to creating a new dimension in CRM. Please excuse the tone but its hard to see the same mistake been made over and again. Ivar > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 From mmbrich at fosslabs.com Fri Jul 14 12:54:21 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:21 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Message-ID: <1152896061.16985.648.camel@localhost.localdomain> On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > Proper use of a OO design would solves this for both of you. > > All the common code and default module behavior should be moved into > the a set of default classes or "engines" as Matthew is calling them. > Then for each module we inherit the classes and make a couple method > calls (ideally this is abstracted as well so to create a module all > you do is create a class which inherits the base class) which > generates the required database actions / html page. If you want > something different then the default, like Dennis describes, you > simply extent the required method in your inherited class. This way > the common code is abstracted and only needs to exist once while the > module specific code is in the module for easy modification. I think we're right on the same page here, but if you take for example the Campaign.php class, it should not be needed. All of the functions and variables it defines are generic and do not need to be re-created for each module that does simple data collection and display. If you want to write a module that does more than this, and will need it's own class, by all means, extend the EntityEngine class (or CRMEntity if it becomes the engine) and then continue on your way. > > The code is already partly structured this way (it's just not used > properly). There's already a base class CRMentity which every module > inherits from. What needs to be done is to clean up the CRMentity - > module relationship so that only methods common to all modules and > their default behavior is defined in CRMentity and only things which > need to be changed are defined in the module class. But even things that need to be changed, may not need to be changed and defined in separate module classes. For example all the get_leads, get_contacts, etc functions can be standardized and instead use a set of DB keys to track relationship_types allowed for a module. function get_leads($id,$entity) { if($this->is_relationship_type($entity->module,"Leads")) { stuff.. } else return false; } > Then we need to > create a class for each page type (again some of this already exists. > ala inculdes/Listview.php, but here it isn't used at all) with the > default behaviors of each page type. Now we have an option, either we > have each module inherit these page type classes (making changes as > needed ala CRMentity) and have a common set of calls to render each > page type or we create a SMALL file in each module with a couple of > calls to the page type class to render the page and we substitute new > functions as needed for customizations. Personally I think the first > option here is the better design, but unless you get it right it could > become difficult to modify the parts of the page you want without > re-witting a lot of the base class (should be avoided at all cost or > we're right back in the mess we are in now). Correct, and I think if you created the correct UI classes you could very easily overwrite the functions you want to customize and _only_ the functions you want to customize (like AddBlock() for example). > That was a bit of a long winded explanation, let me know if anyone > requires clarification. I think we're pretty close to being in the same school of though but maybe I needed to explain my thoughts in a bit more detail. I really just laid out a very high level overview of what I think should be done. Matt From mmbrich at fosslabs.com Fri Jul 14 12:54:58 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:58 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <1152896098.16985.650.camel@localhost.localdomain> > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. So in these cases you could over-ride the system DetailView by creating /Accounts/DetailView.html.php for your actual HTML stuff, and /Accounts/Detailview.php if you want to change the logic flow. If you are only changing the look/feel, then re-declare the AddBlock() function with your new special sauce inside of it and off you go. > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. See above, the correct separation of these layers in the system can still give you the flexibility you need. > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > To create new field types it would just be a matter of creating a new UIType, populating the DB fields you want to have that uitype (via XML), and then creating the base HTML for it in the UIType.tpl file. {if {$uitype} == "230"} your_new_html {/if} On top of this you could just over-ride the system UI creator and replace it with your own display classes. > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. I actually think the entity engine will need to have a query builder in it so that the queries can be built dynamically depending on the type of data you are going for. A true entity engine (like the one in ofbiz.org) will not ever let you see a query, nor should you need to if the entity engine is doing it's job correctly. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. i hate utils.php :). But the examples you lay out above would not at all be impossible. You would simply tell the entity engine (via an XML file) that you want a seqno and header value assigned to each entity of type=Quotes, and then in the query builder it will check for seqno and if it find it, ORDER BY seqno will be appended to the query string. Really what I am trying to accomplish is to make your life easier in the long run than what it currently is, even when diverging from the standard way of doing it with-in vtiger. There is a learning curve that will come along with this but correct documentation and developer support via this mailing list should help you get past any of that. Matt From allan.bush+vtiger_dev at gmail.com Fri Jul 14 13:13:28 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 10:13:28 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <1152896061.16985.648.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> Message-ID: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> I'm pretty sure we're on the same page Matt, my reply was more of an attempt to convince Dennis then an attempt to disagree with anything you said. In your example though I'm not sure how much I like having a function called "get_leads" in the base class. I think there's way too much coupling between "modules" right now and I'd like to get away from that, however I'm not sure what the best way to do that is without losing any of the control we currently have. That's probably another discussion though. I agree with your design, I could probably argue all day over the implementation of the details, but as long as it's constant and logical I don't care too much. On 7/14/06, Matthew Brichacek wrote: > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > Proper use of a OO design would solves this for both of you. > > > > All the common code and default module behavior should be moved into > > the a set of default classes or "engines" as Matthew is calling them. > > Then for each module we inherit the classes and make a couple method > > calls (ideally this is abstracted as well so to create a module all > > you do is create a class which inherits the base class) which > > generates the required database actions / html page. If you want > > something different then the default, like Dennis describes, you > > simply extent the required method in your inherited class. This way > > the common code is abstracted and only needs to exist once while the > > module specific code is in the module for easy modification. > I think we're right on the same page here, but if you take for example > the Campaign.php class, it should not be needed. All of the functions > and variables it defines are generic and do not need to be re-created > for each module that does simple data collection and display. > If you want to write a module that does more than this, and will need > it's own class, by all means, extend the EntityEngine class (or > CRMEntity if it becomes the engine) and then continue on your way. > > > > > The code is already partly structured this way (it's just not used > > properly). There's already a base class CRMentity which every module > > inherits from. What needs to be done is to clean up the CRMentity - > > module relationship so that only methods common to all modules and > > their default behavior is defined in CRMentity and only things which > > need to be changed are defined in the module class. > But even things that need to be changed, may not need to be changed and > defined in separate module classes. For example all the get_leads, > get_contacts, etc functions can be standardized and instead use a set of > DB keys to track relationship_types allowed for a module. > function get_leads($id,$entity) { > if($this->is_relationship_type($entity->module,"Leads")) { > stuff.. > } else > return false; > } > > > Then we need to > > create a class for each page type (again some of this already exists. > > ala inculdes/Listview.php, but here it isn't used at all) with the > > default behaviors of each page type. Now we have an option, either we > > have each module inherit these page type classes (making changes as > > needed ala CRMentity) and have a common set of calls to render each > > page type or we create a SMALL file in each module with a couple of > > calls to the page type class to render the page and we substitute new > > functions as needed for customizations. Personally I think the first > > option here is the better design, but unless you get it right it could > > become difficult to modify the parts of the page you want without > > re-witting a lot of the base class (should be avoided at all cost or > > we're right back in the mess we are in now). > Correct, and I think if you created the correct UI classes you could > very easily overwrite the functions you want to customize and _only_ the > functions you want to customize (like AddBlock() for example). > > > > That was a bit of a long winded explanation, let me know if anyone > > requires clarification. > I think we're pretty close to being in the same school of though but > maybe I needed to explain my thoughts in a bit more detail. I really > just laid out a very high level overview of what I think should be done. > > Matt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From mmbrich at fosslabs.com Fri Jul 14 13:18:54 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 11:18:54 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> Message-ID: <1152897535.16985.654.camel@localhost.localdomain> On Fri, 2006-07-14 at 10:13 -0700, Allan Bush wrote: > I'm pretty sure we're on the same page Matt, my reply was more of an > attempt to convince Dennis then an attempt to disagree with anything > you said. > > In your example though I'm not sure how much I like having a function > called "get_leads" in the base class. I think there's way too much > coupling between "modules" right now and I'd like to get away from > that, however I'm not sure what the best way to do that is without > losing any of the control we currently have. That's probably another > discussion though. I'm not a big fan of how this is done either but you're right, this falls into another discussion about how to clean up current practices going forward with a new structure. > > I agree with your design, I could probably argue all day over the > implementation of the details, but as long as it's constant and > logical I don't care too much. Plenty of details that are yet to be worked out ;). Matt > > > On 7/14/06, Matthew Brichacek wrote: > > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > > Proper use of a OO design would solves this for both of you. > > > > > > All the common code and default module behavior should be moved into > > > the a set of default classes or "engines" as Matthew is calling them. > > > Then for each module we inherit the classes and make a couple method > > > calls (ideally this is abstracted as well so to create a module all > > > you do is create a class which inherits the base class) which > > > generates the required database actions / html page. If you want > > > something different then the default, like Dennis describes, you > > > simply extent the required method in your inherited class. This way > > > the common code is abstracted and only needs to exist once while the > > > module specific code is in the module for easy modification. > > I think we're right on the same page here, but if you take for example > > the Campaign.php class, it should not be needed. All of the functions > > and variables it defines are generic and do not need to be re-created > > for each module that does simple data collection and display. > > If you want to write a module that does more than this, and will need > > it's own class, by all means, extend the EntityEngine class (or > > CRMEntity if it becomes the engine) and then continue on your way. > > > > > > > > The code is already partly structured this way (it's just not used > > > properly). There's already a base class CRMentity which every module > > > inherits from. What needs to be done is to clean up the CRMentity - > > > module relationship so that only methods common to all modules and > > > their default behavior is defined in CRMentity and only things which > > > need to be changed are defined in the module class. > > But even things that need to be changed, may not need to be changed and > > defined in separate module classes. For example all the get_leads, > > get_contacts, etc functions can be standardized and instead use a set of > > DB keys to track relationship_types allowed for a module. > > function get_leads($id,$entity) { > > if($this->is_relationship_type($entity->module,"Leads")) { > > stuff.. > > } else > > return false; > > } > > > > > Then we need to > > > create a class for each page type (again some of this already exists. > > > ala inculdes/Listview.php, but here it isn't used at all) with the > > > default behaviors of each page type. Now we have an option, either we > > > have each module inherit these page type classes (making changes as > > > needed ala CRMentity) and have a common set of calls to render each > > > page type or we create a SMALL file in each module with a couple of > > > calls to the page type class to render the page and we substitute new > > > functions as needed for customizations. Personally I think the first > > > option here is the better design, but unless you get it right it could > > > become difficult to modify the parts of the page you want without > > > re-witting a lot of the base class (should be avoided at all cost or > > > we're right back in the mess we are in now). > > Correct, and I think if you created the correct UI classes you could > > very easily overwrite the functions you want to customize and _only_ the > > functions you want to customize (like AddBlock() for example). > > > > > > > That was a bit of a long winded explanation, let me know if anyone > > > requires clarification. > > I think we're pretty close to being in the same school of though but > > maybe I needed to explain my thoughts in a bit more detail. I really > > just laid out a very high level overview of what I think should be done. > > > > Matt > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From nolan at peaceworks.ca Fri Jul 14 13:44:55 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Fri, 14 Jul 2006 13:44:55 -0400 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Message-ID: <1152899095.32568.49.camel@rockcrusher> As one of the mentioned 4.2 developers mostly lurking on this list... Like others have mentioned, I've got 2 classes of modifications: 1. those _I think_ others may be interested in 2. those _I think_ others will not be interested in What I want to know is...is what _I think_ in any way connected with reality? More to the point... How do I know whether or not I *should* submit a given patch to the current tree for 4.2.5? In my previous (though admittedly minimal) exploration, I got the sense that 4.2.x was essentially "feature frozen" and that bug/security fixes and deployment/installation/maintenance stuff were fair game. For myself (and others like me), is 4.2 open for new features? If so, should we just continue to take it on ourselves to self-select those things _we think_ are more universal in nature? Should we try the shotgun approach (submit everything to 'Code Contributions' and see what gets picked up)? Is there a "proper place" to provide a list of changes we've made and give others the opportunity to speak for/against including them (or give a 'vTiger Linus' the opportunity to accept/reject them)? I think once I have a clear idea of how best to contribute, particularly to 4.2, I'll be more able to do so effectively. By the way, I think Matt's v5 architecture ideas are great, but they do muddy the waters for me a bit. Seeing those ideas, I have hope that something along those lines may be implemented, but it also makes me question *when* the right time will be to port some of my changes and additions to v5...I'd rather just do it once. peace, nokes On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > Hi! > This is a call to all the 4.x private development owners. > > Many of you would have been working on your own version of vtiger as you would have > customized it to your own needs. This is a call for those guys. > > The intent is to aggregate most of the common features that you have built and have them > integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch > or even in the 5.x branch as needed by the community. > > Pros: > > By doing the above, you will be able to be in sync with the latest and greatest developments > happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a > read as one would think of but we are working on it. Yesterday we had comments about the > code not being properly commented, we are working on that right now even as I type this post. > So, the idea I am conveying is that we are not perfect but are listening to the comments and > taking actions too. Hence, please do keep the faith. > > Cons: > > By maintaining your own code bases, you lose out on the community benefits like > identifying bugs, feature integration, new ideas, etc. > > We welcome your contributions. > > Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise > the folly. Let us get on with it and make vtiger a success. > I have learnt from my past mistakes. Join the team, come on board. > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Fri Jul 14 15:37:08 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 15:37:08 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> > Really what I am trying to accomplish is to make your life easier in the > long run than what it currently is, even when diverging from the > standard way of doing it with-in vtiger. There is a learning curve that > will come along with this but correct documentation and developer > support via this mailing list should help you get past any of that. Except that you're killing me with your good intentions. The life of an integrator doesn't permit steep learning curves and heavy abstractions; there just isn't time to do so. I've got a dozen different systems to get to play together, a boss screaming at me to get this stuff done yesterday, and no time to devote to learning whatever abstraction layer you've decided to implement. And Murphy's Law being what it is, if your abstraction model has one flaw, that will be the thing that my boss wants as his top priority. "Perfect is the enemy of good enough" I don't want "perfect"; I want "good enough" I want to be able to dive into the source and start modifying how the thing works *right now* without having to trace back a billion functions or wrap my brain around your object model. I don't have time to do so, because I'm simultaneously trying to play with a dozen other pieces of the puzzle. Guys, I have been playing this game for a LONG time. I have written major applications to perform mission-critical business functions.(At one time, if my code broke DaimlerChrysler stopped building cars) I have seen and dealt with thousands of software projects, both as a participant and as an observer, and almost without fail, every time somebody sets out to do the "perfect" object-based, extensible, customizable framework, it just leads to tears. I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. If you write code that any decent developer can pick up, find his bearings in a couple of seconds, and then comprehend *without* the benefit of having read the thousand-page project definition in advance, then you are doing well. The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator - because if your code is so illegible (or so heavily abstracted, or has such a steep learning curve, or whatever) that I cannot figure it out on my own in a few minutes and so have to drop everything until I can get some assistance... well then, you've burned up my precious, precious time. That code might be sheer genius. It might be, once you have tackled the learning curve, breathtakingly beautiful. But if I can't just fire up vi and dive in, then it is WRONG. Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. The big problem with the current state of Vtiger 4.x is that it straddles both worlds. There are parts of the code that are fairly straightforward and out in plain sight, and only lack comments to make them "good enough". Then there are parts that want to be object-oriented with an API, but really depend on a couple of heavily-overloaded megafunctions buried deep in the depths of util.php (also uncommented) so you have to play API detective to figure out just what the hell is happening where. And then there's parts of the code that mix both. It'd be SO much easier to maintain if all the code that related to a module (less some *basic* toolkit functions that could reside in a common include) just lived in that module. Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility. DG From dan.means at teamsrs.com Fri Jul 14 16:25:56 2006 From: dan.means at teamsrs.com (Dan Means) Date: Fri, 14 Jul 2006 13:25:56 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <44B7FDD4.4080009@teamsrs.com> I couldn't have said this better than Dennis.... -- Dan Means Mission Viejo, CA www.dkmeansonline.com www.teamsrs.com From crm at email.si Fri Jul 14 17:34:37 2006 From: crm at email.si (Ales Petric) Date: Fri, 14 Jul 2006 22:34:37 +0100 Subject: [Vtigercrm-developers] What's with 4.2.x future ? Message-ID: <44B80DED.4010808@email.si> HI EVERYONE This is my first post to 'vTiger' developers mailing list About me: My native environment is development environment (around C/C++, VB, HTML, CSS, PHP, ASP, Python). My home system environment is 'Linux' based desktop os. like 'Debian' and 'Debian' based (my latest is 'Ubuntu') For my business server system I use 'Debian' stable. Like all I had to do some system tunning and other stuff related for system to work properly and live. I worked for small and big companies, within groups and on solo projects. My favorite project is project that is more to an end oriented that other. I had worked on lost project to but I had learned something from that, hope you to. Project called 'vTIger': Yes, 'vTiger' :), I am working with this great free source project for some time now (let me think back, 1 year and 6 month it is, sounds like my birthday :) Reason is that I am involved with business that uses 'CRM' software and solution for them 'vTiger' was the answer, from me to them :) Yes, it sells good if support is guaranteed and signed in contract (like must be included); Yes what's new :) What is new? That was my question looking 'vTiger' community. Let's get serious. In my business we had implemented over 150 issues, or tickets related, not features. We have less then 10 serious stuff implemented, tested and deployed. I believe, and some of you will confirm that this is big step back for community when stuff is included in 'vTiger' and not updated on live track inside community. As we now, there are many companys that offers hosting with 'vTiger' CRM, and many are just keeping one eye on 4.2.x. I belive that 'vTiger' is under 'GPL' and much more, there is community above that is responsible for maintaining the project. Community: Let's face it. There should be readable state and mission, end oriented leadership, free participation, known business model of 'vTiger CRM', useful documents on-line, tutorials, subgroups with a roles like module manager, testers, and many more beautiful stuff, ..I yes there is many but not enough. I have read that someone was begging not for himself for some other guy that they should give him some type of account that he can post code 'not(anonymous)' Question is. Can community afford that kind of behaviour, that no actions are taken. Many are complaining about non activity that is going on right now. Proposal: Let's build team of project/module managers and sys-admin guys to do some steeps needed to put out htp://new.vtiger.com/ based on latest release of 4.2.x thread. On the same portal if it is possible ? Within the same community if it is possible ? We can invite all existing groups that are using 4.2.x thread and join forces and merge existing sources and fixed issues. We need that, and more we need all help we can get within testing activities that are needed when new release comes out. With future plans of what's included in first build and what in next. Yes we can plan what features and build them in future within subgroups of module managers responsible to finish what was started. 4.2.x future to be when 4.3 and then 5.0, isn't that the way ? If there is comment, I now there is, and I now there is the way we can bring action into 'vTiger' community. What do ya say? Respect, Ales Petric From carylt at gmail.com Fri Jul 14 17:47:03 2006 From: carylt at gmail.com (Caryl Takvorian) Date: Fri, 14 Jul 2006 22:47:03 +0100 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <8075d1e0607141447y1b5a878at5321bb42dafcd01b@mail.gmail.com> Just for the sake of it, let me say that I whole heartedly agree with Dennis. I'm not unfortunately convinced that his (our) opinion will change anything, but I find the arguments truthfully compelling. Caryl On 7/14/06, Dennis Grant wrote: > > > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/02f2875a/attachment-0004.html From mmbrich at fosslabs.com Fri Jul 14 18:29:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 16:29:30 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <1152916171.16985.800.camel@localhost.localdomain> OK, so I am going to highlight and comment on some of my favorite quotes from DG so far, this way when I start ignoring his emails you will all understand why. 1) It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules. This has to be hands-down the stupidest thing I have ever heard in my life and I can't believe that anyone who claims the experience you do actually posts this drivel on a public mailing list. 2) I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. I am utterly convinced that anyone who argues that 95% code similarities in vtiger modules is a "good enough" method is utterly stupid. 3) The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator ... well then, you've burned up my precious, precious time So your 'job' as an OSS systems integrator has never included needing to RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing question on a mailing list? 4) That code might be sheer genius. But if I can't just fire up vi and dive in, then it is WRONG. I'm starting to see the picture now.. you're lazy, and rather than do something about the current problems in the system you are going to whine about it. Sergio was right, my apologies Sergio. 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. I think I've made it clear that simple, concise and logical are all design goals of the system. And you sir have made it clear that you have no intention of helping move this project forward by displaying your willingness to fork instead of work with a _real_ design structure that a _real_ OSS systems integrator would be very happy to have. Matt On Fri, 2006-07-14 at 15:37 -0400, Dennis Grant wrote: > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From brian at awnow.com Fri Jul 14 21:48:13 2006 From: brian at awnow.com (Brian Laughlin) Date: Fri, 14 Jul 2006 18:48:13 -0700 Subject: [Vtigercrm-developers] Poorly written code is poorly written code. Message-ID: <27CABE0A5EFD714EA5B2F9B47EE5CB855BCFA2@svawmc1.awnow.local> 'Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility.' This is not really a fair statement. OO code done well is a gem. The statement above automatically implies that it will be written poorly. OO code, procedure code or a sql query written badly is poorly written code - period. No method can overcome poor coding. It seems reasonable that v5 is about the future, one that creates better code base that is more reusable and it encourages more development talent to improve, iterate and integrate. With some effort I think we can mature this process so that the core product can continue to benefit from the community's contributions. There seems to be a simple fix to the debate that is ensuing. If you want to keep it as it is then support the 4.2.x branch, otherwise help to mature the code for v5. One last comment. There is a large class of developers that don't really care how the code was written or how it works as long as it works and works well. If you can extend its functionality or easily call it when you need it then for the most part they are happy. That doesn't stop those that want to dig deeper and tweak it at that level. More power to you. Regards, Brian Laughlin From mmbrich at fosslabs.com Sun Jul 16 23:31:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 21:31:30 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight Message-ID: <1153107090.5582.9.camel@localhost.localdomain> I wasn't able to get all the upgrades done last night, expect some more spotty access tonight as I try to finish up the list of to-dos Matt From mmbrich at fosslabs.com Mon Jul 17 00:31:29 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 22:31:29 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight In-Reply-To: <1153107090.5582.9.camel@localhost.localdomain> References: <1153107090.5582.9.camel@localhost.localdomain> Message-ID: <1153110689.5582.17.camel@localhost.localdomain> Upgraded SVN to 1.2.3 from backports.org. Let me know if you have problems with it. There is a backup of both the forge repo and the main repo from just before the upgrade. Matt On Sun, 2006-07-16 at 21:31 -0600, Matthew Brichacek wrote: > I wasn't able to get all the upgrades done last night, expect some more > spotty access tonight as I try to finish up the list of to-dos > > Matt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Mon Jul 17 05:18:50 2006 From: crm at email.si (Ales Petric) Date: Mon, 17 Jul 2006 10:18:50 +0100 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <1152899095.32568.49.camel@rockcrusher> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> <1152899095.32568.49.camel@rockcrusher> Message-ID: <44BB55FA.4050909@email.si> Ok As private developer owner of 4.2.x I would like to be involved 'actively' in planning, maintaining and updating the 4.2.x. With what can I contribute: 1- I can bug fix (ticket solve) 2- I can suggest & plan with others what's to be in next release (4.2.X) and help with coding to achieve that 3- I can define groups for managing individual modules (maintainers) that will togather with other involved in 4.2.x deceide what's needed to build as add-on 4- I can do the functional analyse of current 4.2.x and publish .pdf, like system & user help (for developers and others related) 5- I can built three of functionality, like dir structure (for UseCase, TestCase and other related) 6- I can define which ticket/issue goes with X module or X functionality (for quick issue solving and other related) 7- I can help sync with other anonymous/private developers what was solved/debugged and help to merge existing code into next to be released 8 .. and many other stuff that I had have already done and not published...I can decode that for other users... What do I need: 1- Account with permissions to do something, I don't want to be anonymous updater. Now it's 8 vs 1 :( I it would be great to be involved with when to release and what's included in next 4.2.x. Ales Nolan Andres wrote: > As one of the mentioned 4.2 developers mostly lurking on this list... > > Like others have mentioned, I've got 2 classes of modifications: > > 1. those _I think_ others may be interested in > 2. those _I think_ others will not be interested in > > What I want to know is...is what _I think_ in any way connected with > reality? > > More to the point... > > How do I know whether or not I *should* submit a given patch to the > current tree for 4.2.5? In my previous (though admittedly minimal) > exploration, I got the sense that 4.2.x was essentially "feature frozen" > and that bug/security fixes and deployment/installation/maintenance > stuff were fair game. > > For myself (and others like me), is 4.2 open for new features? If so, > should we just continue to take it on ourselves to self-select those > things _we think_ are more universal in nature? Should we try the > shotgun approach (submit everything to 'Code Contributions' and see what > gets picked up)? Is there a "proper place" to provide a list of changes > we've made and give others the opportunity to speak for/against > including them (or give a 'vTiger Linus' the opportunity to > accept/reject them)? > > I think once I have a clear idea of how best to contribute, particularly > to 4.2, I'll be more able to do so effectively. > > By the way, I think Matt's v5 architecture ideas are great, but they do > muddy the waters for me a bit. Seeing those ideas, I have hope that > something along those lines may be implemented, but it also makes me > question *when* the right time will be to port some of my changes and > additions to v5...I'd rather just do it once. > > peace, > nokes > > > > On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > >> Hi! >> This is a call to all the 4.x private development owners. >> >> Many of you would have been working on your own version of vtiger as you would have >> customized it to your own needs. This is a call for those guys. >> >> The intent is to aggregate most of the common features that you have built and have them >> integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch >> or even in the 5.x branch as needed by the community. >> >> Pros: >> >> By doing the above, you will be able to be in sync with the latest and greatest developments >> happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a >> read as one would think of but we are working on it. Yesterday we had comments about the >> code not being properly commented, we are working on that right now even as I type this post. >> So, the idea I am conveying is that we are not perfect but are listening to the comments and >> taking actions too. Hence, please do keep the faith. >> >> Cons: >> >> By maintaining your own code bases, you lose out on the community benefits like >> identifying bugs, feature integration, new ideas, etc. >> >> We welcome your contributions. >> >> Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise >> the folly. Let us get on with it and make vtiger a success. >> I have learnt from my past mistakes. Join the team, come on board. >> >> Richie >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > __________ NOD32 1.1661 (20060714) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f0af863c/attachment-0002.html From sergiokessler at gmail.com Mon Jul 17 09:36:39 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 10:36:39 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak From dgrant at accuratetechnologies.com Mon Jul 17 09:51:45 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Mon, 17 Jul 2006 09:51:45 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG From richie at vtiger.com Mon Jul 17 10:48:07 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:48:07 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> Message-ID: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Hi Team! Let us take a step back and review what is happening. As the case stands, the intent is to provide an ideal vtiger architecture which needs almost everyones needs. It is plain that as of now, there are only 2 "strong/loud" arguments. I am sure you all will agree that both of them are not overly subscribed by any majority yet. Let us get some more ideas- however radical they be- into this list and then we will vote the good ideas in. By being too strongly worded on any particular idea, it will only stop short the other guys to put forth their ideas however miniscule/insignificant that might appear to be. I have myself faced this situations many times and I wish that the same does not happen here. Let us target 2 weeks from today as the time within which we should get all the ideas in. We can always short list as we have quite some experienced hands on board. vtigercrm-5.0.0 will be out within that time. Good to see some emotion here but I am sure we will hold to the rules of basic etiquettes and only wrt the point in concern. Thank You, Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9af843db/attachment-0004.html From richie at vtiger.com Mon Jul 17 10:57:28 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:57:28 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> Message-ID: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/d71cb2dd/attachment-0002.html From richie at vtiger.com Mon Jul 17 11:43:10 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 08:43:10 -0700 Subject: [Vtigercrm-developers] automated tests update Message-ID: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f783fc2f/attachment-0004.html From richie at vtiger.com Mon Jul 17 12:01:27 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:01:27 -0700 Subject: [Vtigercrm-developers] have a go at the demo Message-ID: <10c7d3878ee.-2525705299028808692.-7798707862789036512@@vtiger.com> Dear Team, Kindly have a go at the demo so that we can identify the bugs and fix them. We are planning to freeze taking up any new bug-fixing post this week. Needless to say, if there be any pressing bugs, we will have to re-consider else we stick to this plan. We would like to take into consideration all the bugs that we get by this week alone. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/05c6f7c8/attachment-0002.html From richie at vtiger.com Mon Jul 17 12:04:40 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:04:40 -0700 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 Message-ID: <10c7d3b68c9.-1733958150241885349.-2381377074013605034@@vtiger.com> Ken asked me a question in my blogs about how we can have a better documentation for v5. I honestly do not know if any setup is available which can help us achieve the same other than that of a wiki. Any new ideas are welcome. It will be nice to have a distributed effort on for the documentation as well. Let us get some working backbone for collaborative documentation up and running fast. Any ideas/suggestions? Any experienced documentor on board, please raise hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/effef8f7/attachment-0004.html From richie at vtiger.com Mon Jul 17 12:24:59 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:24:59 -0700 Subject: [Vtigercrm-developers] Help Needed Feature Message-ID: <10c7d4e0030.-6478902657238423422.8728970723888816495@@vtiger.com> Is there any Help Needed feature available in the forge? Ken asked me this and I could not answer the query. Please find the link to the blog post for contextual reference: http://blogs.vtiger.com/weblog_entry.php?p=28125#28125 I think what Ken is referring is to have a more vertically-distributed setup something like Help Needed in Leads Module Bug-fixing Help Needed in Leads Module Docs Help Needed in Leads Module Automation of test cases etc. Matt/Fathi, can we have this for all the projects in the forge please or does it already exist? I just checked the forge and did not find any links. Am I missing something? Probably, we can have a link to the vtigercrm-5.0.0 live source in the vtigerforge too. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/1c9b7dca/attachment-0002.html From richie at vtiger.com Mon Jul 17 12:31:34 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:31:34 -0700 Subject: [Vtigercrm-developers] automated trac registration Message-ID: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9e1e63d7/attachment-0004.html From richie at vtiger.com Mon Jul 17 12:34:57 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:34:57 -0700 Subject: [Vtigercrm-developers] Fwd: error Message-ID: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> ----j.ruisz at ruisz.com wrote ---- ============Forwarded Mail============ >From : j.ruisz at ruisz.com To : richie at vtiger.com Date :Fri, 14 Jul 2006 08:11:36 +0200 Subject : error ============Forwarded Mail============ Hello , trying to test the online demo of vtiger 5 i got this result: *Fatal error*: Call to a member function on a non-object in */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* on line *431* with best regards, mit freundlichen Gr??en, Joachim Ruisz Werbegrafik, Bildagentur, Webagentur Softwareentwicklung Joachim Ruisz A 8940 Liezen +43 664 312 4830 j.ruisz at ruisz.com http://www.ruisz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/332ceeeb/attachment-0002.html From richie at vtiger.com Mon Jul 17 12:35:17 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:35:17 -0700 Subject: [Vtigercrm-developers] Fwd: Translations Message-ID: <10c7d576ed5.6497289794643483356.-5939067564803299625@@vtiger.com> ----webmaster at vtigerfacile.com wrote ---- ============Forwarded Mail============ >From : webmaster at vtigerfacile.com To : richie at vtiger.com Date :Mon, 17 Jul 2006 02:31:42 +0200 Subject : Translations ============Forwarded Mail============ Vanakkam Shankar, i have made a little test for translation. I have added few line in app_strings file. And like for module customview, all dropdown in all editviews (Call/Meeting inclued) are translated. If we can have the same things in listview & detailview, the translation will be perfect, and vtiger 5 can be used in multilang without problem. I want to mention the value of select box is keep in english () Best regards, A?ssa Find the added strings in /include/languages/fr_fr.lang.php below //activities 'Planned'=>'Plannifi?', 'Held'=>'A eu lieu', 'Not Held'=>'N\'a pas eu lieu', 'Medium'=>'Normale', 'Private'=>'Priv?', 'Public'=>'Public', 'Daily'=>'Quotidienne', 'Weekly'=>'Hebdomadaire', 'Monthly'=>'Mensuelle', 'Yearly'=>'Annuelle', 'Completed'=>'Termin?', 'Deferred'=>'Report?', //Campaigns 'Excellent'=>'Excellent', 'Good'=>'Bonne', 'Average'=>'Moyenne', 'Poor'=>'Faible', 'Conference'=>'Conf?rence', 'Webinar'=>'S?minaire', 'Trade Show'=>'Salon', 'Public Relations'=>'Relations Publique', 'Partners'=>'Partenaires', 'Referral Program'=>'Programme', 'Advertisement'=>'Publicit?', 'Banner Ads'=>'Banni?re web', 'Direct Mail'=>'Email direct', 'Email'=>'Email', 'Telemarketing'=>'T?l?marketing', 'Others'=>'Autre', 'Planning'=>'Plannifi?', 'Complete'=>'Termin?', 'Cancelled'=>'Annul?', //Accounts //Industry list 'Apparel'=>'Appareillage', 'Banking'=>'Banque', 'Biotechnology'=>'Biotechnologie', 'Chemicals'=>'Industrie chimique', 'Communications'=>'Communications', 'Construction'=>'BTP', 'Consulting'=>'Conseil', 'Education'=>'Education', 'Electronics'=>'Electronique', 'Energy'=>'Energie', 'Engineering'=>'Engineering', 'Entertainment'=>'Divertissement', 'Environmental'=>'Environnement', 'Finance'=>'Finance', 'Food & Beverage'=>'Agro alimentaire', 'Government'=>'Secteur public', 'Healthcare'=>'Sant?', 'Hospitality'=>'Hopitaux', 'Insurance'=>'Assurances', 'Machinery'=>'', 'Manufacturing'=>'Manufacture', 'Media'=>'M?dia', 'Not For Profit'=>'But non lucratif', 'Recreation'=>'Amusement', 'Retail'=>'D?taillant', 'Shipping'=>'Livreur', 'Technology'=>'Technologie', 'Telecommunications'=>'T?l?communications', 'Transportation'=>'Voyage', 'Utilities'=>'D\'utilit? publique', 'Other'=>'Autre', //accounts type 'Analyst'=>'Analyste', 'Competitor'=>'Concurrent', 'Customer'=>'Client', 'Integrator'=>'Int?grateur', 'Investor'=>'Investisseur', 'Partner'=>'Partenaire', 'Press'=>'Presse', 'Prospect'=>'Prospect', 'Reseller'=>'Revendeur', 'Other'=>'Autre', 'Existing Business'=>'Client existant', 'New Business'=>'Nouveau client', 'Cold Call'=>'Appel direct', 'Existing Customer'=>'Client existant', 'Self Generated'=>'Auto g?n?r?', 'Employee'=>'Employ?', 'Partner'=>'Partenaire', 'Public Relations'=>'Relation publique', 'Direct Mail'=>'Email direct', 'Conference'=>'Conf?rence', 'Trade Show'=>'Salon', 'Web Site'=>'Site web', 'Word of mouth'=>'Bouche ? oreille', 'Other'=>'Autre', 'Prospecting'=>'Prospection', 'Qualification'=>'Qualification', 'Needs Analysis'=>'Requiert analyse', 'Value Proposition'=>'Proposition', 'Id. Decision Makers'=>'Attente d?cision', 'Perception Analysis'=>'Anallyse', 'Proposal/Price Quote'=>'Devis', 'Negotiation/Review'=>'N?gociation', 'Closed Won'=>'Clos gagn?', 'Closed Lost'=>'Clos perdu', 'Attempted to Contact'=>'Attente contact', 'Cold'=>'Froid', 'Contact in Future'=>'A recontacter', 'Contacted'=>'Contact?', 'Hot'=>'Chaud', 'Junk Lead'=>'Corbeille', 'Lost Lead'=>'Perdu', 'Not Contacted'=>'Non contact?', 'Pre Qualified'=>'Pr? qualifi?', 'Qualified'=>'Qualifi?', 'Warm'=>'Brulant', 'Acquired'=>'Acquis', 'Active'=>'Actif', 'Market Failed'=>'March? perdu', 'Project Cancelled'=>'Projet annul?', 'Shutdown'=>'Eteint', 'Open'=>'Ouvert', 'In Progress'=>'En cours', 'Wait For Response'=>'Attente de r?ponse', 'Closed'=>'Clos', 'General'=>'G?n?ral', 'Low'=>'Basse', 'Normal'=>'Normale', 'High'=>'Haute', 'Urgent'=>'Urgent', 'Minor'=>'Mineure', 'Major'=>'Majeur', 'Feature'=>'Fonctionnalit?', 'Critical'=>'Critique', 'Big Problem'=>'Gros probl?me', 'Small Problem'=>'Petit probl?me', 'Other Problem'=>'Autre probl?me', 'Hardware'=>'Mat?riel', 'Software'=>'Logiciel', 'CRM Applications'=>'Application CRM', 'Box'=>'Boite', 'Carton'=>'Carton', 'Dozen'=>'Douzaine', 'Each'=>'Pi?ce', 'Hours'=>'Heure', 'Impressions'=>'Impression', 'Lb'=>'Lb', 'M'=>'M', 'Pack'=>'Pack', 'Pages'=>'Pages', 'Pieces'=>'Pi?ces', 'Quantity'=>'Quantit?', 'Reams'=>'Rames', 'Sheet'=>'Pages', 'Spiral Binder'=>'Reliure', 'Sq Ft'=>'Sq Ft', 'Created'=>'Cr??', 'Delivered'=>'Livr?', 'Reviewed'=>'Corrig?', 'Accepted'=>'Accept?', 'Rejected'=>'Rejett?', 'Approved'=>'Approuv?', 'Sent'=>'Envoy?', 'Credit Invoice'=>'Avoir', 'Paid'=>'Sold?', 'Received Shipment'=>'Commande re?ue', 'Call'=>'Appel', 'Meeting'=>'Rendez-vous', 'Task'=>'T?che', '--None--'=>'Aucun', -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9ad522c6/attachment-0004.html From gopals at vtiger.com Mon Jul 17 13:58:01 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 10:58:01 -0700 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Message-ID: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Hi, If there is automate option, it is better to notify user id and password to the correct email ids. I am already struggling with free forums and wiki registration process. People register with junk mail ids and spam our bug tracker as well. My be we can create a group mail id and alias to admin users, who can create trac users ids so that load is shared among developer community. Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/c36beaeb/attachment-0002.html From mmbrich at fosslabs.com Mon Jul 17 14:18:22 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:18:22 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Message-ID: <1153160302.5582.73.camel@localhost.localdomain> > It is plain that as of now, there are only 2 "strong/loud" arguments. > I am sure you all will agree that both of them are not overly > subscribed by any majority yet. Yes but there is only one idea on the table, and 1 set of criticisms followed by absolutely no suggestions on how to better the first idea. This was really my bitch about the first set of posts. > > Let us get some more ideas- however radical they be- into this list > and then we will vote the good ideas in. This is a great idea. I have been looking forward to someone else posting some ideas to get the ball rolling. I for one welcome radical ideas if anyone has any. > By being too strongly worded on any particular idea, it will only stop > short the other guys to put forth their ideas however > miniscule/insignificant that might appear to be. I certainly don't mean to scare off any developers that are going to actually bring some ideas to the table, quite the contrary. If someone has been playing around in 5.x and said to themselves "wouldn't it be easier if this was done like this..." then please tell us what you are thinking, even if it doesn't involve a full change to the architecture and only covers some small area of the code. > > I have myself faced this situations many times and I wish that the > same does not happen here. > > Let us target 2 weeks from today as the time within which we should > get all the ideas in. Lets not rush this, or pile on top of the workload that many vtiger devels are probably already experiencing. The only reason I brought my idea to the table this soon is because you and I had discussed this off list and I thought it needed to be in front of the community. > We can always short list as we have quite some experienced hands on > board. > vtigercrm-5.0.0 will be out within that time. But after 5.0.0 is out is when I think we'll start to see the most interesting ideas. Many devels may still be in 4.x and haven't had a chance yet to start playing with 5.x. Lets let them get their hands dirty in the new code first. > > Good to see some emotion here but I am sure we will hold to the rules > of basic etiquettes and only wrt the point in concern. I know I am a blunt person and sometimes that catches people off guard :), I rarely mean to come off as rude unless someone fully deserves it. Anyways, bring on the ideas for improving vtiger! Matt From mmbrich at fosslabs.com Mon Jul 17 14:22:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:22:49 -0600 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Message-ID: <1153160569.5582.79.camel@localhost.localdomain> I can't think of a great way to do automated sign-up without using captcha or something similar, and we all know there are ways around those systems. I like your ideas of an admin list that people can request access from. And BTW, which interface are you guys using to give developers trac accounts? There is the trac module which was installed or there is the service page that I created to manage SVN and trac. The reason I ask is because the service page may be out of date now that we've upgraded trac a couple times since I wrote it. Matt On Mon, 2006-07-17 at 10:58 -0700, Gopal wrote: > Hi, > > If there is automate option, it is better to notify user id and > password to the correct email ids. I am already struggling with free > forums and wiki registration process. People register with junk mail > ids and spam our bug tracker as well. > > My be we can create a group mail id and alias to admin users, who can > create trac users ids so that load is shared among developer > community. > > Gopal > --- > S.S.G.Gopal > skype: sripadag > ph: +1 877 788 4437 > blog: http://gopal.vtiger.com > > > > > ----richie at vtiger.com wrote ---- > > > Hi! > Team, is there any way we can have an automated trac registration? I can do the registrations > till a point and the current mechanism is too crude. > > Jeff/Matt any ideas please? > > Richie _______________________________________________ > Get started with creating presentations online - > http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Mon Jul 17 14:24:20 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:24:20 -0600 Subject: [Vtigercrm-developers] Fwd: error In-Reply-To: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> References: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> Message-ID: <1153160660.5582.81.camel@localhost.localdomain> I'll upgrade the demo sometime this afternoon, I still haven't had a chance to sit down and write an automation system for this since. I plan to create something along the lines of Jeff's suggestion and automate it with post-commit hooks. Anyone who wants to help, just say the word. Matt On Mon, 2006-07-17 at 09:34 -0700, Richie wrote: > > > > > ----j.ruisz at ruisz.com wrote ---- > > ============Forwarded Mail============ > From : j.ruisz at ruisz.com > To : richie at vtiger.com > Date :Fri, 14 Jul 2006 08:11:36 +0200 > Subject : error > ============Forwarded Mail============ > > Hello , > > trying to test the online demo of vtiger 5 i got this result: > > *Fatal error*: Call to a member function on a non-object in > */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* > on line *431* > > > > with best regards, > mit freundlichen Gr??en, > > Joachim Ruisz > > Werbegrafik, Bildagentur, Webagentur > Softwareentwicklung > > Joachim Ruisz > A 8940 Liezen > +43 664 312 4830 > j.ruisz at ruisz.com > http://www.ruisz.com > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From gopals at vtiger.com Mon Jul 17 14:37:05 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 11:37:05 -0700 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> References: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Message-ID: <10c7dc6f0c9.-5230172439552086929.-6694355083648319934@@vtiger.com> Hi Richie, I am aware of that currently we are using AdventNet QEngine for automating some of the test cases. But I am not clear, how can our external developer community use this tool in their local environment. Do you have any plans to get some more licenses for the sake of vtiger developer community? Thanks, Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/8b304edc/attachment-0004.html From jtk at yahoo.com Mon Jul 17 15:01:00 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 15:01:00 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: Gopal wrote: > I am aware of that currently we are using AdventNet QEngine for > automating some of the test cases. But I am not clear, how can our > external developer community use this tool in their local environment. > Do you have any plans to get some more licenses for the sake of vtiger > developer community? I'm glad to see regression tests on the agenda, but we don't need non-free tools to get this done. Selenium, which I've mentioned before, runs recorded tests in a browser, giving the most/only realistic test environment for javascript, etc. Selenium tests can be recorded by a firefox plugin, and the test source can be checked into subversion like any other source. This is what we should use, IMHO. http://openqa.org/selenium/ As far as running 'continuous integration testing'; some testing experts have used buildbot and vmware/vnc integration to continuously and automatically run unit and integration tests in a headless environment. http://www.google.com/search?q=buildbot+selenium http://agile.idyll.org/wiki/BuildBotTechnologyNarrative http://agile.idyll.org/buildbot/ All this testing technology uses free software. From mmbrich at fosslabs.com Mon Jul 17 17:25:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 15:25:52 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: <1153171552.5582.166.camel@localhost.localdomain> I haven't looked into Selenium yet but with JS does it work at the source level only, does it use gecko to actually execute and evaluate the JS or can it check for changes in the DOM like it does the source? In 5.x there are quite a few places where the DOM is being manipulated directly or indirectly and I don't think a source level verification tool will catch most of those. Maybe augmenting it with the scriptactulous unit test lib would work? http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Matt On Mon, 2006-07-17 at 15:01 -0400, Jeff Kowalczyk wrote: > Gopal wrote: > > I am aware of that currently we are using AdventNet QEngine for > > automating some of the test cases. But I am not clear, how can our > > external developer community use this tool in their local environment. > > Do you have any plans to get some more licenses for the sake of vtiger > > developer community? > > I'm glad to see regression tests on the agenda, but we don't need non-free > tools to get this done. > > Selenium, which I've mentioned before, runs recorded tests in a browser, > giving the most/only realistic test environment for javascript, etc. > > Selenium tests can be recorded by a firefox plugin, and the test source > can be checked into subversion like any other source. This is what we > should use, IMHO. > > http://openqa.org/selenium/ > > As far as running 'continuous integration testing'; some testing experts > have used buildbot and vmware/vnc integration to continuously and > automatically run unit and integration tests in a headless environment. > > http://www.google.com/search?q=buildbot+selenium > > http://agile.idyll.org/wiki/BuildBotTechnologyNarrative > > http://agile.idyll.org/buildbot/ > > All this testing technology uses free software. > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Mon Jul 17 18:53:33 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 18:53:33 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: Matthew Brichacek wrote: > I haven't looked into Selenium yet but with JS does it work at the > source level only, does it use gecko to actually execute and evaluate > the JS or can it check for changes in the DOM like it does the source? > In 5.x there are quite a few places where the DOM is being manipulated > directly or indirectly and I don't think a source level verification > tool will catch most of those. Selenium directly drives the browser as if the user were clicking it. The demo http://www.openqa.org/selenium-core/demos.html illustrates the concept. > Maybe augmenting it with the scriptactulous unit test lib would work? > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Unit tests in the client and server-side source would be enhancements, to be sure. However, I am skeptical about trying to retrofit unit test coverage to a large code base. The community would have a hard time achieving useful code coverage unless there were tests for *everything*, starting from early in the project. Selenium's end-result testing, and the fact that such tests can be recorded for submission by even novice users, would be an efficient use of limited community resources. If the testing fever strikes the community, perhaps all new code could be required to have unit tests, and so on. From sergiokessler at gmail.com Mon Jul 17 19:14:20 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 20:14:20 -0300 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 In-Reply-To: <8091387652950704133@unknownmsgid> References: <8091387652950704133@unknownmsgid> Message-ID: <49216030607171614g2a47b5di900e13b06c4810f6@mail.gmail.com> richie, a wiki is the best aproach for this, don't worry... (of course, then you need people that do collaborate) /sak On 7/17/06, Richie wrote: > > Ken asked me a question in my blogs about how we can have > a better documentation for v5. > I honestly do not know if any setup is available which > can help us achieve the same other than > that of a wiki. > Any new ideas are welcome. > > It will be nice to have a distributed effort on for > the documentation as well. > Let us get some working backbone for > collaborative documentation up and running > fast. > > Any ideas/suggestions? > Any experienced documentor on board, please raise hands! > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From mmbrich at fosslabs.com Mon Jul 17 20:13:46 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 18:13:46 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: <1153181627.5582.194.camel@localhost.localdomain> On Mon, 2006-07-17 at 18:53 -0400, Jeff Kowalczyk wrote: > Matthew Brichacek wrote: > > I haven't looked into Selenium yet but with JS does it work at the > > source level only, does it use gecko to actually execute and evaluate > > the JS or can it check for changes in the DOM like it does the source? > > In 5.x there are quite a few places where the DOM is being manipulated > > directly or indirectly and I don't think a source level verification > > tool will catch most of those. > > Selenium directly drives the browser as if the user were clicking it. The > demo http://www.openqa.org/selenium-core/demos.html illustrates the > concept. I tried this out and did a little digging in the Core and IDE. From the looks of it, Selenium can handle a _lot_ of the javascript testing we would need, if not all of it. > > > Maybe augmenting it with the scriptactulous unit test lib would work? > > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting > > Unit tests in the client and server-side source would be enhancements, to > be sure. However, I am skeptical about trying to retrofit unit test > coverage to a large code base. The community would have a hard time > achieving useful code coverage unless there were tests for *everything*, > starting from early in the project. > > Selenium's end-result testing, and the fact that such tests can be > recorded for submission by even novice users, would be an efficient use of > limited community resources. If the testing fever strikes the community, > perhaps all new code could be required to have unit tests, and so on. I had thought of this before too but my experience in requiring unit tests has not been good :). In the CGL project we tried to enforce a rule like this and it was shot down almost before it left the ground. In a PoC environment like that it's understandable but I think even in the case of vtiger the fever would have to be HOT to get everyone on board. Matt From richie at vtiger.com Tue Jul 18 01:40:42 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 22:40:42 -0700 Subject: [Vtigercrm-developers] XTemplate removed Message-ID: <10c80267f98.3578777089016548574.3997907602755987476@@vtiger.com> This is to inform that we have removed XTemplate dependency in vtigercrm5.0.0. XTemplate has been removed from the source as well. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9fe2c2d6/attachment-0002.html From webmaster at vtigerfacile.com Tue Jul 18 05:18:43 2006 From: webmaster at vtigerfacile.com (=?ISO-8859-1?Q?A=EFssa?=) Date: Tue, 18 Jul 2006 11:18:43 +0200 Subject: [Vtigercrm-developers] Idea for future Message-ID: <44BCA773.9050506@vtigerfacile.com> Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa From richie at vtiger.com Tue Jul 18 06:20:36 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:20:36 -0700 Subject: [Vtigercrm-developers] need helping hands Message-ID: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> I am quoting Gopal's bug report. " As per discussion. I am testing product on the following setup: OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a-installer.exe php settings: error_reporting = E_ALL display_errors = On display_startup_errors = On log_errors = On After completion of installation 1.2 mb error log is generated in Apache error.log file. It is better to fix some of the notices and warnings, which will definitely improve the performance of the product. Thanks, Gopal " Need helping hands who can dig into this and give the fixes. We are held up with validation over here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/071764bc/attachment-0004.html From richie at vtiger.com Tue Jul 18 06:21:42 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:21:42 -0700 Subject: [Vtigercrm-developers] Idea for future In-Reply-To: <44BCA773.9050506@vtigerfacile.com> References: <44BCA773.9050506@vtigerfacile.com> Message-ID: <10c8127c4e2.-191772016694368201.-7661796100973677084@@vtiger.com> Hello! I do agree with that. I wanted it to be part of vtigercrm-5.0.0 but it was a feature so dropped it. It does not require too much effort actually. Will be taken up as part of 5.0.1 Richie ---- A?ssa<webmaster at vtigerfacile.com> wrote ---- Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/c3cec421/attachment-0002.html From richie at vtiger.com Tue Jul 18 08:13:08 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 05:13:08 -0700 Subject: [Vtigercrm-developers] need helping hands-2 Message-ID: <10c818dc9b0.-7967502206826138398.-2571256210646174921@@vtiger.com> We are getting quite some javascript issues in IE browsers. Any one out there game to test it in IE and help us by giving the fixes will be great. Please ensure that the fix does not break the Firefox/Mozilla support. Kindly post the fix in the trac and a blurb here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/a6b94bf0/attachment-0004.html From developer at infointegrated.com Tue Jul 18 08:33:39 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Tue, 18 Jul 2006 07:33:39 -0500 Subject: [Vtigercrm-developers] need helping hands In-Reply-To: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> References: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> Message-ID: <9160DA4D-DAAA-4C0D-B458-E401E03C5E49@infointegrated.com> Sounds like quite the challenge. I just started doing some more thorough testing of vtiger 5.0. I have created 3 new tickets on it. I was able to create patches for the first two. #1531 is to reset the Quick Create menu to Quick Create... after selecting an item (with a patch). #1532 cleans up the formatting of the AllMenu: putting headers on all columns, keeping the length more consistent (with a patch). #1533 is a bug when resizing the window too small. the HomePage Dashboard looks horrible. There needs to be some resize code, but I've not had time to look into patching this one. If I have time, I will also look for solutions to some of the error logs and IE JavaScript Issues. Not sure how much free time I'll have... Brian On Jul 18, 2006, at 5:20 AM, Richie wrote: > I am quoting Gopal's bug report. > " > As per discussion. I am testing product on the following setup: > OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a- > installer.exe php settings: > error_reporting = E_ALL display_errors = On display_startup_errors > = On log_errors = On > After completion of installation 1.2 mb error log is generated in > Apache error.log file. > It is better to fix some of the notices and warnings, which will > definitely improve the performance of the product. > Thanks, Gopal > " > > > Need helping hands who can dig into this and give the fixes. > We are held up with validation over here. > > Richie > _______________________________________________ > Get started with creating presentations online - http:// > zohoshow.com?vt From dgrant at accuratetechnologies.com Tue Jul 18 08:58:03 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 18 Jul 2006 08:58:03 -0400 Subject: [Vtigercrm-developers] vtiger arch going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090C@exch.accuratetechnologies.com> >> It is plain that as of now, there are only 2 "strong/loud" arguments. >> I am sure you all will agree that both of them are not overly >> subscribed by any majority yet. > Yes but there is only one idea on the table, and 1 set of criticisms > followed by absolutely no suggestions on how to better the first idea. > This was really my bitch about the first set of posts. Then frankly, you misread. 1) All code must be commented. Ideally, this would be a priority such that commenting existing code would be an actual project, but realistically, the goal of "all NEW code must be commented" or perhaps "every time you touch the code, a comment must be inserted" is doable. 2) The current (4.x) architecture uses a number of "common" functions (so identified by virtue of living in the include directory) that are not really common. An easy test is that if at any time a soi-disant "common" function tests to see what module it was called from and then acts differently based on the result of that test, it ain't common. Those functions should be broken out of the include directory and moved into the appropriate module directory - perhaps something like modules/Foo/UI.php (although this naming convention is definitely open for discussion) 3) Any time you go to the database, the actual SQL should be exposed; it helps integrators understand the layout and function of the database and makes extending the database much easier. It's OK to streamline db functions somewhat though - something like: $query = 'SOME SQL'; @2D_array = query_db($query) or handle_db_error; Is OK. 3) All modules must be atomic. At no time is it EVER permissible that changing the code in module FOO *changes* the functionality of module BAR - with one exception; if module FOO ever *calls* module BAR, and a code change to BAR has broken the interface, then it is understood that FOO calling BAR will break (and shame on whoever changed BAR's interface) In some cases, this will actually move functionality INTO common code, and that's a good thing. For example, currently HelpDesk calls code in Emails to do its email notification stuff (HORROR!) This would be better served by a function in utils.php that called some sort of generic email API: $result = send_email($to, $from, $cc, $bcc, $subject, $body, $flags); 4) There are two major challenges facing the vtiger architecture, independent of code structure: a) Per-user localization, which in turn is broken down into: i) User language of choice; and ii) User operating currency (which may be a function of what office the user is working out of) b) Per-user security (a user cannot edit someone else's Quote, for example) Both of these are ABSOLUTE MUSTS going forward, and there's a lot of heavy lifting there. No matter what the code structure is, these two design structures must be part of the arch. I'm hoping that 5.0 has support for this already... >> Let us get some more ideas- however radical they be- into this list >> and then we will vote the good ideas in. > This is a great idea. I have been looking forward to someone else > posting some ideas to get the ball rolling. I for one welcome radical > ideas if anyone has any. Hrm, well, let's see how welcoming you *really* are. DG From jens at Strawberry.COM Tue Jul 18 09:16:35 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 15:16:35 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] Message-ID: <20060718151635.D16513@Strawberry.COM> -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- An embedded message was scrubbed... From: Jens Hamisch Subject: Patches required for PostgreSQL 8.1.4 Date: Tue, 18 Jul 2006 09:02:01 +0200 Size: 27774 Url: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/efd557cc/attachment-0004.mht From allan.bush+vtiger_dev at gmail.com Tue Jul 18 10:14:27 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 07:14:27 -0700 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <20060718151635.D16513@Strawberry.COM> References: <20060718151635.D16513@Strawberry.COM> Message-ID: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> I have given up on getting postgres support into 5.0 because I got tired of having my changes reverted and the database changing on me. The last straw was when all the database table names were changed without warning. If someone else wants to continue the effect feel free to take a look at this patch and take over the effort. On 7/18/06, Jens Hamisch wrote: > > -- > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > > ---------- Forwarded message ---------- > From: Jens Hamisch > To: vtigercrm-developers at lists.vtigercrm.com > Date: Tue, 18 Jul 2006 09:02:01 +0200 > Subject: Patches required for PostgreSQL 8.1.4 > Hi, > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > database. Compared to mySQL this database seems to require some code > changes. I've located and fixed the following problems: > > 1. SELECT count(*) count FROM ... won't work. > The AS clause is missing: SELECT count(*) AS count FROM ... > > 2. Referring table columns in case of joined tables in the > SELECT or ORDER BY clause requires the columns also to be > listed in a GROUP BY clause. > > 3. tablename.* won't work in a GROUP BY clause > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > LIMIT and OFFSET clause. > > 5. PostgreSQL supports transactions. However the current coding > results in transaction failures. > > I've attached my patches to this mail. Those patches at a first glance > address the problems 1-4. The transaction problem is not yet fixed. > I want to clean up the "simple" SQL statements first, before analyzing > such complex things. > > I'm not a 100% satisfied with the patches, because they introduce some > dbType dependencies into the "high level" vtiger code. Also structural > information is required in the function which expands the queries by > the required GROUP BY clause. I was thinking of moving those things > to a more abstract layer, but stopped doing this, because a generic > solution would either result in parsing and fixing each entire SQL statement > (including all its features and possibilities) or a redesign of the > affected SQL queries itsself. > > In most cases (especially the LIMIT changes) my patches might also work > for mySQL, so the database dependency possibly could be removed. This > might also apply to some of the GROUP BY patches. > > > Hope those changes will find their way to the vtigercrm5 mainline. > > Kind regards > -- Jens > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > From jens at Strawberry.COM Tue Jul 18 11:12:13 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 17:12:13 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com>; from Allan Bush on Tue, Jul 18, 2006 at 07:14:27AM -0700 References: <20060718151635.D16513@Strawberry.COM> <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> Message-ID: <20060718171213.F16513@Strawberry.COM> Hi Allan, hi *, most changes I did seem not to be related to postgres only. So it would help a lot (and remove dbType dependencies) from the code if smb. could check if my changes will also be valid for mySQL ... Jens On Tue, Jul 18, 2006 at 07:14:27AM -0700, Allan Bush wrote: > I have given up on getting postgres support into 5.0 because I got > tired of having my changes reverted and the database changing on me. > The last straw was when all the database table names were changed > without warning. > > If someone else wants to continue the effect feel free to take a look > at this patch and take over the effort. > > On 7/18/06, Jens Hamisch wrote: > > > > -- > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > > > ---------- Forwarded message ---------- > > From: Jens Hamisch > > To: vtigercrm-developers at lists.vtigercrm.com > > Date: Tue, 18 Jul 2006 09:02:01 +0200 > > Subject: Patches required for PostgreSQL 8.1.4 > > Hi, > > > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > > database. Compared to mySQL this database seems to require some code > > changes. I've located and fixed the following problems: > > > > 1. SELECT count(*) count FROM ... won't work. > > The AS clause is missing: SELECT count(*) AS count FROM ... > > > > 2. Referring table columns in case of joined tables in the > > SELECT or ORDER BY clause requires the columns also to be > > listed in a GROUP BY clause. > > > > 3. tablename.* won't work in a GROUP BY clause > > > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > > LIMIT and OFFSET clause. > > > > 5. PostgreSQL supports transactions. However the current coding > > results in transaction failures. > > > > I've attached my patches to this mail. Those patches at a first glance > > address the problems 1-4. The transaction problem is not yet fixed. > > I want to clean up the "simple" SQL statements first, before analyzing > > such complex things. > > > > I'm not a 100% satisfied with the patches, because they introduce some > > dbType dependencies into the "high level" vtiger code. Also structural > > information is required in the function which expands the queries by > > the required GROUP BY clause. I was thinking of moving those things > > to a more abstract layer, but stopped doing this, because a generic > > solution would either result in parsing and fixing each entire SQL statement > > (including all its features and possibilities) or a redesign of the > > affected SQL queries itsself. > > > > In most cases (especially the LIMIT changes) my patches might also work > > for mySQL, so the database dependency possibly could be removed. This > > might also apply to some of the GROUP BY patches. > > > > > > Hope those changes will find their way to the vtigercrm5 mainline. > > > > Kind regards > > -- Jens > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From allan.bush+vtiger_dev at gmail.com Tue Jul 18 11:21:46 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 08:21:46 -0700 Subject: [Vtigercrm-developers] Commit list is broken Message-ID: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> I haven't received any email from the commit/ticket list (vtigercrm-commits at lists.vtigercrm.com) since the 16th. I just made a couple changes which should have triggered emails and they haven't been received either so I'm fairly certain the list is down. From mmbrich at fosslabs.com Tue Jul 18 14:28:48 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 18 Jul 2006 12:28:48 -0600 Subject: [Vtigercrm-developers] Commit list is broken In-Reply-To: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> References: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> Message-ID: <1153247328.5582.214.camel@localhost.localdomain> This is probably from the SVN upgrade, the version we are on now moved all hook scripts to a diff area and I probably missed one. I'll see if I can fix it ASAP. Matt On Tue, 2006-07-18 at 08:21 -0700, Allan Bush wrote: > I haven't received any email from the commit/ticket list > (vtigercrm-commits at lists.vtigercrm.com) since the 16th. > > I just made a couple changes which should have triggered emails and > they haven't been received either so I'm fairly certain the list is > down. > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jens at Strawberry.COM Tue Jul 18 14:44:48 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 20:44:48 +0200 Subject: [Vtigercrm-developers] Yet another postgres8 patch Message-ID: <20060718204448.D29275@Strawberry.COM> Hi, yet another patch addressing postgres8 Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- *** vtiger_crm/include/database/Postgres8.php.rev8092 Tue Jul 18 20:37:05 2006 --- vtiger_crm/include/database/Postgres8.php Tue Jul 18 20:38:50 2006 *************** *** 122,127 **** --- 122,131 ---- elseif( $table == "vtiger_profile2field") $subfields = array ( "profileid", "tabid", "fieldid", "visible", "readonly"); + //vtiger_field + elseif( $table == "vtiger_field") + $subfields = array ( "tabid", "fieldid", "columnname", "tablename", "generatedtype", "uitype", "fieldname", "fieldlabel", "readonly", "presence", "selected", "maximumlength", "sequence", "block", "displaytype", "typeofdata", "quickcreate", "quickcreatesequence", "info_type"); + //fields of the requested array still undefined else $log->info("function expandRecord: please add structural information for table '".$table."'"); *** vtiger_crm/include/utils/CommonUtils.php.rev8092 Tue Jul 18 20:25:23 2006 --- vtiger_crm/include/utils/CommonUtils.php Tue Jul 18 20:36:01 2006 *************** *** 960,971 **** { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in $blockid_list and vtiger_field.displaytype in (1,2,4) order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and vtiger_field.displaytype in (1,2,4) and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." group by vtiger_field.fieldid order by block,sequence"; } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); --- 960,974 ---- { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN $blockid_list AND vtiger_field.displaytype IN (1,2,4) ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND vtiger_field.displaytype IN (1,2,4) AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); *************** *** 976,987 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list ." and ".$display_type_check." and info_type = '".$info_type."' order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and info_type = '".$info_type."' and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } else --- 979,993 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list ." AND ".$display_type_check." AND info_type = '".$info_type."' ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND info_type = '".$info_type."' AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } else *************** *** 988,999 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } $result = $adb->query($sql); --- 994,1008 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } $result = $adb->query($sql); *************** *** 1789,1796 **** } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and quickcreate=0 and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." order by quickcreatesequence"; } $category = getParentTab(); --- 1798,1808 ---- } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND quickcreate=0 AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." ORDER BY quickcreatesequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $quickcreate_query = fixPostgresQuery( $quickcreate_query, $log, 0); } $category = getParentTab(); *** vtiger_crm/modules/Users/Authenticate.php.rev8092 Tue Jul 18 19:55:38 2006 --- vtiger_crm/modules/Users/Authenticate.php Tue Jul 18 19:57:24 2006 *************** *** 40,47 **** { //Inserting entries for audit trail during login ! $date_var = date('YmdHis'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,$date_var)"; $adb->query($query); --- 40,47 ---- { //Inserting entries for audit trail during login ! $date_var = date('Y-m-d H:i:s'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,'$date_var')"; $adb->query($query); From libregeek at gmail.com Wed Jul 19 01:07:25 2006 From: libregeek at gmail.com (Manilal K M) Date: Wed, 19 Jul 2006 10:37:25 +0530 Subject: [Vtigercrm-developers] Something happened with forums.vtiger.com Message-ID: <2315046d0607182207k577376efv69026d9ce7e887c2@mail.gmail.com> Hi Team, Today Morning I got the reminder for the forum topic given below. How this happened? There are mo updates on this thread and it's almost 4 months old. Please look into it. regards Manilal ---------- Forwarded message ---------- From: webmaster at vtiger.com Date: 19-Jul-2006 07:38 Subject: New Topic Notification for forum "Announcements" - vtiger CRM 5 Alpha 5 Released To: Hello ! Sai has posted a new topic called "vtiger CRM 5 Alpha 5 Released" in the "Announcements" forum at vtiger. You can use the following link to view the topic: http://forums.vtiger.com/viewtopic.php?p=23074#23074 ----------------------------------------------- Posted text: Hi, We are pleased to announce the vtiger [b:7141f7c5eb]CRM 5.0 Alpha 5 release[/b:7141f7c5eb]. The intent of this release is to showcase to the vtiger community, the significant changes made after v5 Alpha 4 release i.e., changes since Mar 31, 06\' . We have conducted performance testing for some of the modules using a popular [b:7141f7c5eb]Web Based Testing Software (AdventNet QEngine 6.0),[/b:7141f7c5eb] which helped us to identify some of the bottlenecks in performance. We will publish the performance reports soon. We thank AdventNet for permitting us to make use of this interesting software and we gladly recommend it to everyone too, not because AdventNet allowed us to use it but because it is really good. We are also pleased to release the downloadable version of the [b:7141f7c5eb]vtiger CRM PHP API Documentation.[/b:7141f7c5eb] The demo of vtigerCRM 5 alpha 5 is available at http://vtiger.com/products/crm/demo_5alpha/index.php You can download the [b:7141f7c5eb]EXE, BIN, or tar.gz[/b:7141f7c5eb] from Sourceforge.net. [b:7141f7c5eb]NOTE:[/b:7141f7c5eb] We strongly recommend CRM community NOT to USE vtiger CRM 5 Alpha 5 for real-time deployment. In case you are looking for an immediate CRM solution for your business, please consider using the vtiger CRM 4.2.3 (latest stable version) or 4.2.4 which will be out shortly. [b:7141f7c5eb]Important URLs:[/b:7141f7c5eb] [b:7141f7c5eb]Download:[/b:7141f7c5eb] http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=186641 [b:7141f7c5eb]Report Bugs[/b:7141f7c5eb] @: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Note: Please refer to the reported bugs before submitting a new bug. [b:7141f7c5eb]Release Notes:[/b:7141f7c5eb] * Smarty template applied to Currency Configuration Feature * List View feature database queries are optimized for all the modules * PHP API documentation for some of the major function * New module called Marketing is added. Campaigns module is now part of Marketing primary module. * AJAXified Notification Schedulers * AJAXified Inventory Notifications * AJAXified Picklist Settings * AJAXified Assign Module Owners * New UI for Integration of Mail Merge Templates * New UI for Company Information * New UI for Outgoing Mail Server * New UI for Backup Server Configuration * New UI for Terms and Conditions * New UI for Announcements * New UI for RSS module Thanks & Regards, Don ----------------------------------------------- You are receiving this email because you are watching the forum, "Announcements" at vtiger. If you no longer wish to watch this forum you can either click the "Stop watching this forum link" found at the bottom of the "Announcements" forum, or by clicking the following link: http://forums.vtiger.com/viewforum.php?f=1&unwatch=forum -- Thanks, The Management -- I would rather be a serf in a poor man's house and be above ground than reign among the dead From dgrant at accuratetechnologies.com Wed Jul 19 08:58:46 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 19 Jul 2006 08:58:46 -0400 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Simple question: when is the next (Beta?) release of V5.0 due out? DG From richie at vtiger.com Wed Jul 19 09:22:20 2006 From: richie at vtiger.com (Richie) Date: Wed, 19 Jul 2006 06:22:20 -0700 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? In-Reply-To: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Message-ID: <10c86f3829c.5523764322808677804.-2671785383507032457@@vtiger.com> Simpler answer :-): No betas. Expect RC1 in 10 days or so. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Simple question: when is the next (Beta?) release of V5.0 due out? DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/e1ba94eb/attachment-0004.html From Matjaz.Slak at atol.si Wed Jul 19 10:45:49 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Wed, 19 Jul 2006 16:45:49 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Message-ID: Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment-0002.bin From developer at infointegrated.com Thu Jul 20 00:45:03 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Wed, 19 Jul 2006 23:45:03 -0500 Subject: [Vtigercrm-developers] Categories / Sub-Categories, Too Much In-Reply-To: References: Message-ID: If you haven't looked at the current collection of categories and subcategories, take a look. I think that it is becoming too much. Here's the current layout: My Home Page Home Activities Calendar Emails Marketing Campaigns Accounts Contacts Emails Leads Activities Calendar Notes Sales Leads Accounts Contacts Potentials Quotes Sales Order Invoice Products PriceBooks Notes Activities Calendar Support HelpDesk FAQ Accounts Contacts Products Notes Emails Activities Calendar Analytics Dashboard Reports Inventory Products Vendors PriceBooks Purchase Order Sales Order Quotes Invoice Tools RSS My Sites Notes Settings Settings I know the list is long and hard to read, but that's my point. I know and understand that different people will want their sub-modules in different places. As long as the method for changing this is documented, I think that is ok. The default configuration, though, should be simpler. This current layout is almost scary. At least for an end-user it would be. I feel this change should be made before 5.0 GA. To simplify, each item should only appear in one category. I have an updated proposal below that is the closest to meeting most of my customer's needs. With the All Menu, Quick Create, Related Items, and Tag Cloud, it shouldn't matter much if some modules are on different categories. I hope that there are still plans on combining activities and calendar into one item as well (I believe this was put off until after 5.0 GA). I think that an interface for managing these should also be planned post 5.0 GA. I also think the order of the items is important and (where relevant) the order should remain consistent. For example, the sub categories should remain in the same order under the category as it shows in the All Menu. What does everyone else think? Anyone else show this to existing clients and get questions about why the same module appears in many places? That's what got me started thinking of improvements. Any better ideas? My Home Page Home Emails Activities Calendar Contacts Notes Marketing Campaigns Leads Sales Accounts Potentials Quotes Sales Order Invoice Support HelpDesk FAQ Inventory Products Vendors PriceBooks Purchase Order Analytics Dashboard Reports Tools Settings My Sites RSS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/50687ed3/attachment-0002.html From richie at vtiger.com Thu Jul 20 04:06:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:06:18 -0700 Subject: [Vtigercrm-developers] unable to add users to trac Message-ID: <10c8af88631.-2915976287139770639.-215398406965928840@@vtiger.com> Hi Matt! Could you please have a look at the issue please? I am unable to add users to the trac anymore. I am using the following url. vtiger.fosslabs.com/service Do have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/02abcafe/attachment-0004.html From richie at vtiger.com Thu Jul 20 04:17:10 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:17:10 -0700 Subject: [Vtigercrm-developers] trac down? Message-ID: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Hi! The trac seems to be down. Matt, kindly have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/df8c96af/attachment-0002.html From mmbrich at fosslabs.com Thu Jul 20 04:24:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 20 Jul 2006 02:24:10 -0600 Subject: [Vtigercrm-developers] trac down? In-Reply-To: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> References: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Message-ID: <1153383850.5617.0.camel@localhost.localdomain> I was doing some work and had to give it a quick reboot. Should be back up and working now. Matt On Thu, 2006-07-20 at 01:17 -0700, Richie wrote: > Hi! > > The trac seems to be down. > Matt, kindly have a look please. > > Thanks, > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Thu Jul 20 05:47:37 2006 From: crm at email.si (Ales Petric) Date: Thu, 20 Jul 2006 10:47:37 +0100 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44AE643B.1040800@vtigerfacile.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> Message-ID: <44BF5139.9050402@email.si> Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Ai"ssa wrote: > Hi Richie, > i have a login for track, but not the right to submit ticket. > thanks, > Ai"ssa (very busy !) > > Richie a ?crit : > >> Hello! >> >> I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. >> Please cross-check if you have received the relevant mails in the id from which you had made the access >> request. >> >> Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. >> >> richie at vtiger dot com >> >> Richie >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/f47f9233/attachment-0004.html From richie at vtiger.com Thu Jul 20 04:58:46 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:58:46 -0700 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44BF5139.9050402@email.si> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> <44BF5139.9050402@email.si> Message-ID: <10c8b2890c0.2475106285347017844.4336268421121807772@@vtiger.com> Hi Ales! I have granted permission to the trac to all those who have asked for it. Not even 1 single request has been denied. Why should it be? The product is as much yours as mine just that someone has to be in some hiearchy somewhere does not mean that we have a monopoly over it. This is the first time I have got your request and I have granted access to you too. The 1 minute that I spend giving permission saves hours to the community as a whole. You are important, not only to me but to the community as well. I am sure you will do well. Richie ---- Ales Petric<crm at email.si> wrote ---- Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Aïssa wrote: Hi Richie, i have a login for track, but not the right to submit ticket. thanks, Aïssa (very busy !) Richie a ?crit : Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie ------------------------------------------------------------------------ _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/aeeddad4/attachment-0002.html From richie at vtiger.com Thu Jul 20 11:30:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 08:30:05 -0700 Subject: [Vtigercrm-developers] permissions revoked Message-ID: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Dear Team, I have revoked permissions for checkin in the main 5.0 trunk. Only the following have permission to checkin now into the 5.0 trunk. core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj All checkins have to be thru these guys alone. The permissions will be restored once the 5.0 is released. Requesting your understanding, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/0cea747a/attachment-0004.html From tgironnay at lexsi.com Thu Jul 20 11:54:15 2006 From: tgironnay at lexsi.com (GIRONNAY Thibault) Date: Thu, 20 Jul 2006 17:54:15 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi all, Matjaz I'll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It's too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we'll have others hands up cabugs ________________________________ De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: * debugging (fixing parts that either don't work at all and/or work incorrectly) * improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: * multilanguage support (simply get rid of any and all hard-coded strings) * full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/fdd85202/attachment-0002.html From nolan at peaceworks.ca Thu Jul 20 13:50:43 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Thu, 20 Jul 2006 13:50:43 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: References: Message-ID: <44BFC273.5060604@peaceworks.ca> Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Thu Jul 20 13:47:54 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 20 Jul 2006 13:47:54 -0400 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE4@exch.accuratetechnologies.com> Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection My vtigercrm.log is full of these. Where are they coming from and what can I do to stop it? DG From jens at Strawberry.COM Fri Jul 21 02:34:10 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Fri, 21 Jul 2006 08:34:10 +0200 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com>; from Richie on Thu, Jul 20, 2006 at 08:30:05AM -0700 References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Message-ID: <20060721083410.A22106@Strawberry.COM> Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From Matjaz.Slak at atol.si Fri Jul 21 03:04:48 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 09:04:48 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi! I agree completly. Security should be on the list of to-dos. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "GIRONNAY Thibault" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 17:54 Please respond to vtigercrm-developers at lists.vtigercrm.com To cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Matjaz I?ll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It?s too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we?ll have others hands up cabugs De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0002.bin From Matjaz.Slak at atol.si Fri Jul 21 07:36:00 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 13:36:00 +0200 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <44BFC273.5060604@peaceworks.ca> Message-ID: Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Nolan Andres Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0002.bin From jtk at yahoo.com Fri Jul 21 09:09:10 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Fri, 21 Jul 2006 09:09:10 -0400 Subject: [Vtigercrm-developers] permissions revoked References: <20060721083410.A22106@Strawberry.COM> Message-ID: Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. From richie at vtiger.com Fri Jul 21 10:11:25 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:11:25 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <20060721083410.A22106@Strawberry.COM> References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916d296e.5312358042738553104.8864199634924158691@@vtiger.com> Hi Jens! Currently, we are working on fixing the breakages that we have committed. Let these stabilize, then we can integrate this together. ok? I do not want to add one more variable now. Hence the precaution. Richie ---- Jens Hamisch<jens at strawberry.com> wrote ---- Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/ed49a8d5/attachment-0004.html From richie at vtiger.com Fri Jul 21 10:12:10 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:12:10 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: References: <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916dd6be.-546019034062113847.-6787520244753134675@@vtiger.com> Yes, you are right. We will take this into consideration before vtigercrm-5.0.0 is out. In other words, postgres is going to be part of this very release. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/51fe5c86/attachment-0002.html From richie at vtiger.com Fri Jul 21 10:13:48 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:13:48 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: References: Message-ID: <10c916f5716.-3447470126087516421.7834933168012625785@@vtiger.com> Matjaz, you already would have got the access mail for the trac. About the TRAC Wiki, Matt will do the needful. Let us know if you need anything else. Richie ---- Matjaz.Slak at atol.si<Matjaz.Slak at atol.si> wrote ---- Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 Nolan Andres <nolan at peaceworks.ca> Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned        Plea        froma        VTiger        Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > >   > > Matjaz I’ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It’s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > >   > > Hope we’ll have others hands up > >   > > cabugs > >   > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > >   > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > >     * debugging (fixing parts that either don't work at all and/or work >       incorrectly) >     * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > >     * multilanguage support (simply get rid of any and all hard-coded >       strings) >     * full per user or at least per-system localization support (number >       format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 > > *Richie <richie at vtiger.com>* > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > >                   > > To > >                   > > vtigercrm-developers at lists.vtigercrm.com > > cc > >                   > > vtigercrm-developers at lists.vtigercrm.com > > Subject > >                   > > Re: [Vtigercrm-developers] An Impassioned Plea from a        VTiger     >    Integrator > >   > >   > >                   > >   > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: >> >>  Hi! >> >>  If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > <http://zohoshow.com?vt/> _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7be12bf9/attachment-0004.html From allan.bush+vtiger_dev at gmail.com Fri Jul 21 11:32:23 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 21 Jul 2006 08:32:23 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <-8603876167918116646@unknownmsgid> References: <-8603876167918116646@unknownmsgid> Message-ID: <3bec26390607210832x65ed46eo60856d8e2972c110@mail.gmail.com> This is the page we should be using to keep track of everything to be done for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=new&status=assigned&status=reopened&milestone=4.2.5 It would be nice to have a 4.2.6 (or 4.2 future) milestone to keep the list realistic though. Fell free to organize, add and prioritize the things in that list. On the same note you here is the page of everything already accomplished for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=closed&milestone=4.2.5 On 7/21/06, Richie wrote: > > Matjaz, you already would have got the access mail for the trac. > About the TRAC Wiki, Matt will do the needful. > > > Let us know if you need anything else. > > Richie > > > > > ---- Matjaz.Slak at atol.si wrote ---- > > > > Hi! > > Thank you! > > I hope I'll be able to finish up some of my other tasks within a week or > so and then I'll start posting ideas about what to work on here. > > *If anybody has any general wishes and/or requests about which item(s) you > would like to have fixed in 4.2.x, post them here.* By this I mean areas > perceived by vTiger users. Try to fit them in the following categories: > > - debugging (fixing user-perceived functions that either don't work > at all and/or work incorrectly) > - improving usability (based on feedback from users) > - improving security (let us know of possible security holes) > - multilanguage support (simply get rid of any and all hard-coded > strings) > - localization support (number format, date format, currency support > etc - per user or at least per-system) > - other (we can create aditional categories if the need arises) > > > For example: > > - Private Custom Views - allow for a custom view to be marked as > private and only be visible to the user that created it (usability) > - All View columns sortable - allow a user to click on any column > and sort it (usability) > - Repeating calls/meetings - don't work at all? (debugging) > - etc... > > > I'll be collecting them and posting them somewhere - the TRAC Wiki comes > to mind as an appropriate place. We can the priorithise them and look into > required work - and then create tickets for developers (us, again :) to work > on. > > *Richie, Jeff, Matt and/or others:* would it me possible for me to have > acces to post some content to the TRAC Wiki? I would create a document like > "vTiger 4.2.x to-do area" that would include these items we wish to work > on - and specific goals for them. Tickets would then be created based on > these. This document would represent the general guideline. > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > *Nolan Andres * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 20.07.2006 19:50 Please respond to > vtigercrm-developers at lists.vtigercrm.com > > To > vtigercrm-developers at lists.vtigercrm.com cc > > Subject > Re: [Vtigercrm-developers] An Impassioned Plea froma > VTiger Integrator > > > > > > > Hi all, > > Although I'd really love to be able to just contribute features without > having to re-integrate (into v5,) I agree with priorities and I'll > second the addition of security to the list. Security through obscurity > is bad enough, but with open source projects, it simply becomes security > through ignorance. I certainly wouldn't trust vTiger's security in an > environment where the data is actually confidential and a malicious or > competitive party would stand to gain by accessing it illicitly. > > I don't have the availability to co-ordinate things, but you can count > on me for some quantity of bug-fixes, security patches, etc. > > peace, > nokes > > GIRONNAY Thibault wrote: > > Hi all, > > > > > > > > Matjaz I'll be with you and your team in your enterprise, I agree with > > your priorities and have one another to add : the security. The > > organisation sharing privileges for example is indeed totally an > > illusion. It's too easy too change those settings while not being admin > > or to see all records even if the privileges are private. I think this > > is very harmful to offer such buggy features and can discredit Vtiger > > for the people who have interests in security. > > > > > > > > Hope we'll have others hands up > > > > > > > > cabugs > > > > > > > > ------------------------------------------------------------------------ > > > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > > de* Matjaz.Slak at atol.si > > *Envoy? :* mercredi 19 juillet 2006 16:46 > > *? :* vtigercrm-developers at lists.vtigercrm.com > > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > > Integrator > > > > > > > > > > Hi Richie and the rest of the team! > > > > You address me correctly, Matjaz is my name :) > > > > > > As I belive the 4.2.x stream is the current "production" vTiger > > environment for most of the users, my primary goal would be to focus on: > > > > * debugging (fixing parts that either don't work at all and/or work > > incorrectly) > > * improving usability (based on feedback from users) > > > > > > I would also like to try and get the following not-quite-features, maybe > > > bugs? implemented/fixed: > > > > * multilanguage support (simply get rid of any and all hard-coded > > strings) > > * full per user or at least per-system localization support (number > > format, date format, currency support etc) > > > > > > These two last items are - in my opinion - somewhere between debugging > > and new features. vTiger is already supposed to support multiple > > languages, however this support is not well implemented. The same can be > > > said for localization - vTiger is supposed to be able to support > > per-user date format, but again there are areas where the implementation > > > is not as good as it could be. > > > > Also, based on my researches into existing vTiger deployments, I see > > there are a lot of non-english users, but they probably are using forked > > > code, as due to these two issues they cannot use the "official" 4.2.x > > stream code. I would like to get these users back on the team, and I > > know they might return only if we provide them with a 100% localisable > > product. This will enable them to post the patches they make back to the > > > community or at least give them an opportunity to work with us on > > resolving them. > > > > I would try and keep us on this track, rather than go try implement new > > features and make large changes to UI - the place for these is v5. > > > > > > To achieve this, I would first gather any and all contributions > > currently lying around (in the forum, as provided by other people here > > etc.) - matching the categories above - and start the process of getting > > > them in the code. *I would like to see a show of hands* from people that > > > would be prepared to devote some time to debugging/updating tthese > > contributions - as some might need an update. I know me and my > > colleagues in our company will. > > > > If all goes well, we could try and implement a regular timeline (say > > every month) when we would be releasing point versions. If I get at > > least two or three people to help, I guess we could have our first > > result (4.2.5 I guess) in two months. > > > > I think there will be people using the 4.2.x stream for at least a year > > after v5 is released, and that if we as a team show them we are > > supporting them, than they will upgrade to v5 -> if we don't they might > > start looking elsewhere. > > > > > > *Thoughts, anyone?* > > > > > > Matjaz Slak > > matjaz.slak at atol.si > > > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > > *Richie * > > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > > > 17.07.2006 16:57 > > > > Please respond to > > vtigercrm-developers at lists.vtigercrm.com > > > > > > > > To > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > cc > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > Subject > > > > > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > > Integrator > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matjaz! > > I hope I am addressing you properly if not please forgive me and direct > > to the proper mode of addressing. > > > > If you are game then great! > > Welcome to the club. > > Please select your stand-in helper so that at least we have a backup for > > > Linus Matjaz. Let me know and I will grant you the relevant access. > > > > It would be nice if you could briefly state how you plan to address the > > disparate contributions. This is just to get an idea as there are lots > > of data floating around in the code contributions and mailing lists; > > wanted to know if you have any specific plan. I will be busy with the v5 > > > release and will not be able to help you much so the query. > > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > > page which reflects the status of the contributions. I am not sure if > > that is updated till the 4.2.4 release though. > > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > > > > Allan, any tips from you will be nice. > > > > Richie > > > > > > > > > > ---- Sergio A. Kessler wrote ---- > > > > On 7/14/06, Matjaz.Slak at atol.si wrote: > >> > >> Hi! > >> > >> If there's no one else, I volunteer to be the v4 Linus. > > > > just do it. ;-) > > > > > > /sak > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > -- > > > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/411ae3e6/attachment-0002.html From don at vtiger.com Fri Jul 21 12:31:48 2006 From: don at vtiger.com (don) Date: Fri, 21 Jul 2006 09:31:48 -0700 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <10c91edb0e4.-4543952587404481040.-9186935435207679906@@vtiger.com> Hi DG, The logs given below are generated from the include/database/PearDatabase.php file. To avoid this kindly do the following: Edit the include/database/PearDatabase.php file and comment the following lines: -- $this->println("TRANS creating new connection"); in the function checkConnection -- $this->println("ADODB fetchByAssoc return null"); in the function function fetchByAssoc Hope this helps you. Kindly contact us for any further clarifications. Thanks & Regards, Don Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7714d42a/attachment-0004.html From jens at Strawberry.COM Tue Jul 18 03:02:14 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 07:02:14 -0000 Subject: [Vtigercrm-developers] Patches required for PostgreSQL 8.1.4 Message-ID: <20060718090201.B15699@Strawberry.COM> Hi, I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 database. Compared to mySQL this database seems to require some code changes. I've located and fixed the following problems: 1. SELECT count(*) count FROM ... won't work. The AS clause is missing: SELECT count(*) AS count FROM ... 2. Referring table columns in case of joined tables in the SELECT or ORDER BY clause requires the columns also to be listed in a GROUP BY clause. 3. tablename.* won't work in a GROUP BY clause 4. LIMIT #,# is not supported. PostgreSQL requires a single LIMIT and OFFSET clause. 5. PostgreSQL supports transactions. However the current coding results in transaction failures. I've attached my patches to this mail. Those patches at a first glance address the problems 1-4. The transaction problem is not yet fixed. I want to clean up the "simple" SQL statements first, before analyzing such complex things. I'm not a 100% satisfied with the patches, because they introduce some dbType dependencies into the "high level" vtiger code. Also structural information is required in the function which expands the queries by the required GROUP BY clause. I was thinking of moving those things to a more abstract layer, but stopped doing this, because a generic solution would either result in parsing and fixing each entire SQL statement (including all its features and possibilities) or a redesign of the affected SQL queries itsself. In most cases (especially the LIMIT changes) my patches might also work for mySQL, so the database dependency possibly could be removed. This might also apply to some of the GROUP BY patches. Hope those changes will find their way to the vtigercrm5 mainline. Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- A non-text attachment was scrubbed... Name: postgres-patches.tgz Type: application/octet-stream Size: 18385 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/e9b482c8/attachment-0002.obj From richie at vtiger.com Tue Jul 4 04:02:55 2006 From: richie at vtiger.com (Richie) Date: Tue, 04 Jul 2006 04:02:55 -0700 Subject: [Vtigercrm-developers] update bleeding edge svn Message-ID: <10c393477d3.4701894980957041264.-7646275652836694714@@vtiger.com> Hi Matt! Wanted to confirm if we have a script in place for updating the latest code in the vtiger-demo.fosslabs.com site? There have been forum queries if the updates are happening in the first place. Kindly inform. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060704/3631a295/attachment-0005.html From saint at vtiger.com Tue Jul 4 11:40:33 2006 From: saint at vtiger.com (Saint) Date: Wed, 05 Jul 2006 00:10:33 +0530 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings Message-ID: <44AAB621.8080701@vtiger.com> Folks, The following are the new "Settings" icons getting into vtiger 5. *Module * *Icon * Users Roles Privilege Profiles Groups Modules Access Fields Access Module Owners Announcements Custom Fields Picklist Editor Email Templates Mail Merge Tempaltes Notification Schedulers Inventory Notifications Inventory Terms & Conditions Company Details Mail Server Settings Backup Server Settings Proxy Server Settings System Information Invoice Configuration Audit Trail Tax Configuration Currency Settings Migration -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1968 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0123.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1951 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0124.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2197 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0125.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2328 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0126.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2134 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0127.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2319 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0128.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1925 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0129.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2267 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0130.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1883 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0131.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1957 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0132.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2160 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0133.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2175 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0134.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1975 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0135.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2264 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0136.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2370 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0137.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1732 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0138.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2121 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0139.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1972 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0140.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2182 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0141.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2492 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0142.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2546 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0143.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1796 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0144.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2441 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0145.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2451 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0146.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: set-IcoMigration.gif Type: image/gif Size: 2187 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/07476702/attachment-0147.gif From sergiokessler at gmail.com Tue Jul 4 12:09:33 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 4 Jul 2006 16:09:33 -0300 Subject: [Vtigercrm-developers] [LANCER] New Icons for Settings In-Reply-To: <44AAB621.8080701@vtiger.com> References: <44AAB621.8080701@vtiger.com> Message-ID: <49216030607041209h171b32d1w9b6e737e1c65a5a8@mail.gmail.com> wow, beautiful ! /sak On 7/4/06, Saint wrote: > > > Folks, > > The following are the new "Settings" icons getting into vtiger 5. > > > Module > Icon > > Users > > > Roles > > > Privilege Profiles > > > Groups > > > Modules Access > > > Fields Access > > > Module Owners > > > Announcements > > > Custom Fields > > > Picklist Editor > > > Email Templates > > > Mail Merge Tempaltes > > > Notification Schedulers > > > Inventory Notifications > > > Inventory Terms & Conditions > > > Company Details > > > Mail Server Settings > > > Backup Server Settings > > > Proxy Server Settings > > > System Information > > > Invoice Configuration > > > Audit Trail > > > Tax Configuration > > > Currency Settings > > > Migration > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From don at vtiger.com Wed Jul 5 08:59:39 2006 From: don at vtiger.com (don) Date: Wed, 05 Jul 2006 08:59:39 -0700 Subject: [Vtigercrm-developers] vtiger CRM 5.0 Beta2 Released Message-ID: <10c3f6a8177.-9001623588305850621.-4297454805191080021@@vtiger.com> Hi All, We are pleased to announce the release of vtigerCRM 5.0 Beta 2. In this release the main focus is on the quality front and we have fixed most of the major bugs that were in the vtigerCRM 5.0 Beta. We have also incorporated most of the feedbacks/suggestions given by the community over 5.0 Beta. In the UI front, the Settings UI has been totally revamped. This release will depict the developments done after vtiger CRM 5.0 Beta. You can give it a try and let us know your valuable feedbacks and suggestions. The live demo of vtigerCRM 5.0 Beta is available at http://vtiger.com/products/crm/demo_5beta/index.php You can download the vtiger CRM 5.0 Beta2 from the following URL : http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=196218&release_id=429844 You can post your feed backs and suggestions at http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Thanks & Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060705/59d438e1/attachment-0003.html From nico.gnauck at googlemail.com Thu Jul 6 10:12:58 2006 From: nico.gnauck at googlemail.com (Nico Gnauck) Date: Thu, 6 Jul 2006 19:12:58 +0200 Subject: [Vtigercrm-developers] Merge with OpenOffice documents Message-ID: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Hello, I'm currently working on a Mail Merge for version 5.0 with Open Office Dokuments based on the rtf Merge for version 4.2.3. You can find the thread and the Merge skripts for Accounts and Contacts in this thread: http://forums.vtiger.com/viewtopic.php?t=7223. If anybody has time to test this, please do so and give me feedback. Thanks, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/776050fd/attachment-0005.html From mmbrich at fosslabs.com Thu Jul 6 10:32:44 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 06 Jul 2006 11:32:44 -0600 Subject: [Vtigercrm-developers] Merge with OpenOffice documents In-Reply-To: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> References: <338bc7990607061012s22776075ie85ab6bf590fe8ac@mail.gmail.com> Message-ID: <1152207165.22922.96.camel@localhost.localdomain> Hi Nico, I haven't had a chance to test yet but I did merge this into my vtiger5 branch in the branches/ directory of the SCM system. I will get it tested as soon as I can, from there the other developers can decide if it should be merged into trunk/. If you find/fix issues in this branch please post the patches here and I will get them merged in. If you have enough issues and would like, I can set you up with commit access to my branch. Thanks for your contribution! Matt On Thu, 2006-07-06 at 19:12 +0200, Nico Gnauck wrote: > Hello, > > I'm currently working on a Mail Merge for version 5.0 with Open Office > Dokuments based on the rtf Merge for version 4.2.3. > You can find the thread and the Merge skripts for Accounts and > Contacts in this thread: > http://forums.vtiger.com/viewtopic.php?t=7223. > If anybody has time to test this, please do so and give me feedback. > > Thanks, Nico > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Thu Jul 6 13:17:20 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Thu, 06 Jul 2006 16:17:20 -0400 Subject: [Vtigercrm-developers] Trac 0.9.6 released Message-ID: Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. From richie at vtiger.com Thu Jul 6 22:22:12 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:22:12 -0700 Subject: [Vtigercrm-developers] trac account Message-ID: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/f616fb9d/attachment-0003.html From richie at vtiger.com Thu Jul 6 22:25:43 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:25:43 -0700 Subject: [Vtigercrm-developers] update svn-version Message-ID: <10c4772d440.733718465091492167.4729172311574536110@@vtiger.com> Hi! Got this mail in the forums. Can someone do the needful please? Jeff, what do you say? "Hi forum users and especially vtiger admins, im not quite sure, if this is the right place to post, but i think you guys should really consider updating your subversion server to > 1.2.x. For us developers using eclipse it's painstaking to get it to work well, because the svn plugin (subclipse.tigris.org) only supports the old svn servers (< 1.2.0) only if you choose to install a very old version of the plugin (< 0.9.3.0). Unfortunately, this version of the plugin is very buggy, and i can't get it to work properly in my env, especially with eclipse 3.1. It maybe a little selfish to request an update, just because of me not getting my setup to work, but svn has improved so much from 1.1.x to 1.2.x so it might be usefull for everyone. Regards Benjamin" Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/606fa218/attachment-0005.html From richie at vtiger.com Thu Jul 6 22:28:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:28:56 -0700 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com Message-ID: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Hi! Is the vtiger-demo.fosslabs.com updated with the bleeding edge code please? Matt, I guess, we are putting a lot of stress on you alone and it is not fair. Do you think you require some guys from the community to assist you? My main concern is that not any single individual be overloaded. vtiger is team-work and it should be that way. Everyone should prosper. Dedicated volunteers please raise their hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/4782857f/attachment-0003.html From richie at vtiger.com Thu Jul 6 22:31:56 2006 From: richie at vtiger.com (Richie) Date: Thu, 06 Jul 2006 22:31:56 -0700 Subject: [Vtigercrm-developers] Trac 0.9.6 released In-Reply-To: References: Message-ID: <10c47788588.1738553798220722432.6769330270375144874@@vtiger.com> Let us get this upgraded then. Jeff, would you take ownership for all the 3rd party upgrades please. I know you are already tracking the 3rd party packages but what I am stating is to take ownership for all upgrades for the s/w used to keep track of vtiger? If you need assistants, give a shout in the mailing list. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Subject: [fmII] Trac 0.9.6 released (Default branch) Date: Thu, 6 Jul 2006 13:11:12 -0700 (PDT) This email is to inform you about the release of version '0.9.6' of 'Trac' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/trac/ The changes in this release are as follows: This release fixes a reStructuredText breach of privacy and denial of service vulnerability. It has trac-post-commit-hook fixes. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060706/1aaf8fb0/attachment-0005.html From webmaster at vtigerfacile.com Fri Jul 7 06:40:11 2006 From: webmaster at vtigerfacile.com (=?UTF-8?B?QcOvc3Nh?=) Date: Fri, 07 Jul 2006 15:40:11 +0200 Subject: [Vtigercrm-developers] trac account In-Reply-To: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> Message-ID: <44AE643B.1040800@vtigerfacile.com> Hi Richie, i have a login for track, but not the right to submit ticket. thanks, A?ssa (very busy !) Richie a ?crit : > Hello! > > I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. > Please cross-check if you have received the relevant mails in the id from which you had made the access > request. > > Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. > > richie at vtiger dot com > > Richie > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Fri Jul 7 20:23:02 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 21:23:02 -0600 Subject: [Vtigercrm-developers] New communications system Message-ID: <1152328983.32174.36.camel@localhost.localdomain> I wrote a new CommSystem module in my 5.0.2-MMBRICH branch. The comm system is a full replacement for the chat system from RC1 and also adds a host of API's to manipulate it from your favorite external system or vtiger module :). Here is a short list of features, any testers or patches to help move it along are appreciated. Features: 1) Full P2P chat 2) Session/Off-line messaging capabilities (ie: if a new message comes in right when you click on a link in the system, when the new page loads you will see the message that appeared as the page was being reloaded). 3) Follows your window focus. If you have multiple tabs open in the CRM, you will only get new messages and status messages in the focused window. All messages are cached when there is no focus on a CRM window. 4) Alert/Event messages. An "MSN like" status box that appears at the bottom of your browser to alert about new emails, voicemails, incoming calls, etc. It has pretty effects to make it slide in and out for alerts :). 5) "User is typing" status messages. 6) Email messages from either periodic checks via JSON or can also be injected via scripts. (Ie: incoming emails to helpdesk at domain.com could be announced to users x,y and z) 7) Simple CommSystem.php and CommSystem.js classes to manipulate the alerts and chat system. CommSystem.js is wrote to follow prototype standards as much as I could get it to. ToDo: 1) Finish the group IM feature. 2) Lots of ugly, needs UI work. 3) Support Portal integration ("Chat with Live Help" links in the portal) 4) Message archives so that old messages can be deleted from the CRM (maybe a monthly cron script to backup and delete the messages from the DB). 5) Asterisk AGI Script and SOAP functions to inject Voicemail or Incoming call alerts 6) Cron scripts to populate email alerts? 7) Fix annoying bugs (Ie: '\n\r' breaks sending messages) 8) Internationalization 9) Test, test, test 10) Jabber connector? Drawbacks to this system: 1) Makes a request to the server every N milliseconds to check for new messages, alerts or status updates. This gets heavy on the server. One way to take load off the server is with the focus tracking mentioned above. Un-focused windows will not make requests back to the server. Another way is to create a decay timer like the one used in the prototype Ajax.PeriodicalUpdater() class. This basically checks the last output status and compares it to the current output status. If they are the same then N = (N*) and if the current output status is diff than the last output status N=(N). 2) The whole system is one large timer loop and global references to the CommSystem.js class have to be created to access the class within the loop. This is a memory usage issue but shouldn't be too noticeable for most. 3) Probably a 70% client side and 30% server side system. Thats a lot of javascript. If you get a chance to check it out, let me know what you think and if you'd like to see something like this in vt5 going forward. Matt From mmbrich at fosslabs.com Fri Jul 7 21:15:14 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 07 Jul 2006 22:15:14 -0600 Subject: [Vtigercrm-developers] update vtiger-demo.fosslabs.com In-Reply-To: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> References: <10c4775c71c.9076376643558475756.-2707024709437897040@@vtiger.com> Message-ID: <1152332114.32174.40.camel@localhost.localdomain> On Thu, 2006-07-06 at 22:28 -0700, Richie wrote: > Hi! > > Is the vtiger-demo.fosslabs.com updated with the bleeding edge code > please? I updated it the day RC1 came out but haven't since then. It is currently not automated. > Matt, I guess, we are putting a lot of stress on you alone and it is not fair. > Do you think you require some guys from the community to assist you? > > My main concern is that not any single individual be overloaded. vtiger is team-work and > it should be that way. Everyone should prosper. The workload isn't too bad yet but any help is more than welcomed! > Dedicated volunteers please raise their hands! Matt From richie at vtiger.com Mon Jul 10 05:36:35 2006 From: richie at vtiger.com (Richie) Date: Mon, 10 Jul 2006 05:36:35 -0700 Subject: [Vtigercrm-developers] move to trac-0.9.6 Message-ID: <10c58706195.1364243099676550119.-2686427800793695304@@vtiger.com> Hi! Anyone game to help us move to trac-0.9.6 so that we can utilize the latest and greatest features? Matt, send me a mail with the access to the machine. Also let me know what steps to follow to upgrade. If no one does it, I will have it done. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/cc4fdd2a/attachment-0003.html From mmbrich at fosslabs.com Mon Jul 10 14:09:03 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 15:09:03 -0600 Subject: [Vtigercrm-developers] UI help Message-ID: <1152565743.32174.120.camel@localhost.localdomain> In case no one noticed in the past I suck @ UI design so I figured we would see who wants to step up to the plate on this one. Right now I need the following things, if you want to take one just say so that way no one else duplicates your work. 1) De-Duplication system for settings module. I want this to be able to delete/merge/etc records that can be matched based on certain criteria. I'll write the search engine and logic system to merge/de-dup if someone wants to take on the UI :). I was thinking about having this work in steps. Step 1: select search criteria. Step 2: display duplicate results that are candidates for merge/delete, un-select records from the list via checkbox. Step 3: Select fields to merge or other action to take (delete). Step 4: Execute actions. There was a bounty on this in the forums. If that pans out you'll get a chunk, let me know what you think is fair for your time/effort. 2) Geolocation/Action tracking for email campaigns. This will be a simple popup window that should show a list of the commands from that email (ie: open, followed link, unsubscribed, etc) in one html tab and then the google map to show the actual locations those commands were executed at in another tab. Most likely I will just push one XML descriptor up to google maps to display the country/state/town the email was opened in, but I want to be able to push multiple XML descriptors to google in cases where more than one location is tracked. These extra descriptors can be used to mark possible forwards for that email. Along with this feature we'll need a simple settings area to input your google maps key. 3) Default email unsubscription page. This is a simple page that is visited when a user clicks on the 'unsubscribe' link in emails. The page should have a nice header, a hello message or something, give the user a choice to unsubscribe from that campaign or from all lists in the CRM and then display a success or failure message depending on the result from the CRM's attempt to remove them. If the unsubscribe fails the page should display the company info from the DB so that the user can write in or call to have their information removed. 4) Workflow module? I thought I saw a post that the vtiger crew was going to take this on. If thats the case then this one is void and we don't need to worry about it. Otherwise, go check out the bounty, let me know what you think is a fair cut for your work, then submit me your ideas. If the bounty pans out you'll get a cut of course. 5) Communications system. This is built and ready enough for beta. I need a p2p chat window, group chat window, right hand 'slider' (to show who is online, etc) and we should probably do something with the alert slider as well, it's very plain. The fun part about the chat windows is that none of them are built with HTML so you'll have to do most of the design in CSS. You can also look into the scriptaculous Builder() function for more info on how I create the chat windows, there is flexibility in how you can design them so you're not necessarily restricted to css only. Also could use a chat window for the customer portal if you're up to it :). 6) Direct Mail Designer. This is still on the drawing board but it would be super cool. The idea is to have a list of templates in the "Direct Mail" campaigns that could be merged with the campaign records. Sounds familiar right? Well it would build off of the current merge system by allowing .rtf and .odt files to be merge templates but would also make use of a 'packaging' standard. Basically this packaging (a tarball or zip file) would have a templatename.xml file that would have things like params and thumbnail images and other useful information for merging, etc. This has the ability to have services packaged around it (like we could define an API for designers to make their designs available for pre-set prices and also printing companies to actually do the printing.) Lots of possibilities, if you decide this one is interesting, email me on or off list and we can start a discussion about how this could work. This is candidate for a forge project so if there is enough interest I might just open one. All of this stuff is being created in my branch. I'll give you access to my sandbox area on vtiger-demo.fosslabs.com so you can track stuff and help out. I have every intention of doing these myself if no one takes them, but I can say that I have no skill in UI design whatsoever :). Matt From mmbrich at fosslabs.com Mon Jul 10 20:58:53 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 21:58:53 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590333.16985.2.camel@localhost.localdomain> This is an example screen of what I would like to do for managing campaign actions. If there is a way to tell the campaign type, even when using a diff language or changing the picklist, then I wouldn't have to show every single action. Opinions? Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-24.png Type: image/png Size: 66134 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/86b7c2be/attachment-0003.png From mmbrich at fosslabs.com Mon Jul 10 21:02:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 10 Jul 2006 22:02:49 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152565743.32174.120.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> Message-ID: <1152590570.16985.4.camel@localhost.localdomain> Here is a screenie of the current comm system if anyone wants to give suggestions. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-25.png Type: image/png Size: 77505 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060710/854ed82e/attachment-0003.png From dgrant at accuratetechnologies.com Tue Jul 11 11:12:38 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 11 Jul 2006 14:12:38 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG From jtk at yahoo.com Tue Jul 11 14:12:32 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Tue, 11 Jul 2006 17:12:32 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone From sergiokessler at gmail.com Tue Jul 11 15:37:23 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Tue, 11 Jul 2006 19:37:23 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> dennis, On 7/11/06, Dennis Grant wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak From mmbrich at fosslabs.com Tue Jul 11 18:58:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 19:58:10 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <1152669490.16985.122.camel@localhost.localdomain> > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt From mmbrich at fosslabs.com Tue Jul 11 21:06:12 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:06:12 -0600 Subject: [Vtigercrm-developers] 5.x webmail changes Message-ID: <1152677172.16985.144.camel@localhost.localdomain> I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt From mmbrich at fosslabs.com Tue Jul 11 21:20:56 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 11 Jul 2006 22:20:56 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152590570.16985.4.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> Message-ID: <1152678056.16985.149.camel@localhost.localdomain> I'm going to keep posting these hoping that someone will finally get fed up with the ugly and help out ;). Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-26.png Type: image/png Size: 90999 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0009.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-27.png Type: image/png Size: 67631 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0010.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-28.png Type: image/png Size: 90831 bytes Desc: Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060711/de52a588/attachment-0011.png From saint at vtiger.com Tue Jul 11 23:09:35 2006 From: saint at vtiger.com (Saint) Date: Wed, 12 Jul 2006 11:39:35 +0530 Subject: [Vtigercrm-developers] UI help In-Reply-To: <1152678056.16985.149.camel@localhost.localdomain> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> Message-ID: <44B4921F.8020402@vtiger.com> Matt.. I am aware that, the campaigns module is fairly attended in the UI front. I am in the middle of other works. So give me a few more days.. I will hop in and check it out :-) -Saint Matthew Brichacek wrote: > I'm going to keep posting these hoping that someone will finally get fed > up with the ugly and help out ;). > > Matt > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90999 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0015.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 67631 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0016.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 90831 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060712/e501b013/attachment-0017.png From dgrant at accuratetechnologies.com Wed Jul 12 06:41:28 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 12 Jul 2006 09:41:28 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) { bar; } vice if ($foo) { bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG From sergiokessler at gmail.com Wed Jul 12 06:48:28 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Wed, 12 Jul 2006 10:48:28 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From jtk at yahoo.com Wed Jul 12 07:06:57 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Wed, 12 Jul 2006 10:06:57 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). From mmbrich at fosslabs.com Wed Jul 12 08:16:41 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:16:41 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <1152717401.16985.280.camel@localhost.localdomain> On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt From mmbrich at fosslabs.com Wed Jul 12 08:48:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 09:48:52 -0600 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <1152719332.16985.289.camel@localhost.localdomain> I have started doing the query part as I run into them in my branch. I'm also moving the query strings out of functions like get_leads() and putting it in get_related_leads_query() instead. This way the query can be used for other things.. like for example if you want mostly the same output of get_leads() but without the HTML that manged to find its way out of the presentation layer and into the data layer... don't get me started on that. Anyways, with the HUGE db query strings that are used in the system, breaking them into separate short lines is a great suggestion for manageability and if it makes merges easier it's like getting your cake and eating it too :). Matt On Wed, 2006-07-12 at 10:06 -0400, Jeff Kowalczyk wrote: > Dennis Grant wrote: > > Actually, I think with VTiger you are going to see a lot of private > > forks, because individual businesses have their own needs and wants that > > are supersets of core VTiger functionality that simply don't apply to > > other businesses. > > This is one of the reasons why I care about making the source more > merge-friendly (particularly short, vertically formatted SQL statement > string lines). > > If we can get the codebase to the point where branching and merging is a > manageable burden, customization branches have a fighting chance to be > maintained in the repository. Or use a distributed repository such as > bazaar-ng can be used (bzr has a trac backend now). > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 10:16:13 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 11:16:13 -0600 Subject: [Vtigercrm-developers] UI help In-Reply-To: <44B4921F.8020402@vtiger.com> References: <1152565743.32174.120.camel@localhost.localdomain> <1152590570.16985.4.camel@localhost.localdomain> <1152678056.16985.149.camel@localhost.localdomain> <44B4921F.8020402@vtiger.com> Message-ID: <1152724573.16985.290.camel@localhost.localdomain> Gracias, in the mean time I will keep working on the back-end and breaking stuff. Matt On Wed, 2006-07-12 at 11:39 +0530, Saint wrote: > Matt.. > > I am aware that, the campaigns module is fairly attended in the UI > front.I am in the middle of other works. So give me a few more days.. > I will hop in and check it out :-) > > -Saint > > > > > Matthew Brichacek wrote: > > I'm going to keep posting these hoping that someone will finally get fed > > up with the ugly and help out ;). > > > > Matt > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > ____________________________________________________________________ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Wed Jul 12 20:39:08 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Wed, 12 Jul 2006 21:39:08 -0600 Subject: [Vtigercrm-developers] vtiger.fosslabs.com maint Message-ID: <1152761948.16985.311.camel@localhost.localdomain> I am going to shut the vtiger.fosslabs.com machine down this weekend for hardware upgrades. When I bring it back up I plan to snapshot and upgrade SVN. Expect the access to the system to be spotty over the weekend. I am tentatively scheduled to do the work on Saturday evening @ 11PM MST but that may change depending on other upgrades being done at the same time. Matt From richie at vtiger.com Thu Jul 13 01:43:03 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:43:03 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670da880.830325448603459473.-9072372394275150906@@vtiger.com> Hi DG! Your comments are well taken. These will be in place at the earliest. I know that this will be a quick fix but instructions have been sent across to have the code properly commented from now on for any future development/bug fixes. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Ladies and Gentlemen, I am currently employed as the lead integrator/programmer for VTigerCRM at a medium-sized manufacturing company. My job is to maintain the VTigerCRM server, and to customize our installation of VTiger to match our business needs. Sometimes this involves getting other systems (like Microsoft Great Plains) to play nicely with the CRM; sometimes it means changing VTiger code to better adopt the CRM to our particular business needs. Our current installation is a heavily-modified (and I do mean HEAVILY) modified 4.3.2 installation. To be honest, I painted myself into a bit of a corner with the way I implemented our code changes, such that upgrading to newer versions is a formidable challenge. My intent is to, soon, bring up a 5.0 installation and start backporting our changes into it, but this time with patch management tools to better manage upgrading in the future. In a way, it's a bit like maintaining my own private fork of something like the Linux kernel, and so I intend on adopting the best practices of those who have gone before me. Anyway, I have occasion to spend a LOT of time in VTiger code, and while I have not yet seen the V5.0 code in any great detail, I have a pair of impassioned pleas for all current VTiger developers (in any version) 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! Those of us who have to pop into a module to make a few tweaks to how it looks/operates are hamstrung by the lack of comments in VTiger code. We wind up having to work everything out from scratch, and that makes a difficult job even more difficult. The fact that VTIger code, in general, uses good descriptive variable names helps out a lot, but comments would go even further. Please please PLEASE get into the habit of commenting your code, even if you think the functionality is obvious - you'll REALLY help guys like me out. 2) I see a lot of code that looks like this: if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { if ($some_parameter !='') { Do some stuff; } } What is missing here is any sort of exception handling. Not only does this code fail silently if the tested assumptions aren't true (which has caused some unusual bugs) it also fails to communicate to integrators what the allowed/expected parameters of this code block are. EVERY SINGLE IF OR IF/THEN NEEDS AN ELSE TO CATCH EXCEPTIONS, without exception (heh) Failing to do this opens the door to bizarre bugs and much wasted time trying to track them down. It also makes an integrator's job that much more difficult. Compare to this example: // Prepare the foo object for writing to the database // We are only supposed to be called from the module_name1 or module_name2 modules if ($_REQUEST['module'] == 'module_name1' || $_REQUEST['module'] == 'module_name2') { // We need this to be set if ($some_parameter !='') { Do some stuff; } else { print_warning("Expected some_parameter to be set in do_stuff.php"); } } else { print_warning("Called with unexpected value of REQUEST[module] : ".$REQUEST['module']." from do_stuff.php."); } I don't want to get all programmer grammer nazi here, but I've been ripping my hair out by the roots for the last few hours, and it's all totally unnecessary. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/488cba6b/attachment-0003.html From richie at vtiger.com Thu Jul 13 01:44:36 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:44:36 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> Message-ID: <10c670f131a.7768422503650913231.-7005067799642887197@@vtiger.com> I am game for it . Any takers? What is the procedure and how do we guarantee that there are no breakages? Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > I don't want to get all programmer grammer nazi here Programmer grammar Nazi. ;) I think many of us who are working on the periphery with vtigercrm have pet peeves about the formatted representation of the source code. Those pet peeves confer a certain squeal point for making a comment about it (no pun) and another, higher, one for doing something about it on our own. The interval between squeal points is where we've been circling for months. No few persons (rightly) want to clean up a fraction of the code when new checkins aren't guaranteed follow the same standards. And so, the technical debt incurred by the fixable problem of poor source formatting (including commentless code) continues to impose costs on vtigercrm development. Further, if we fix this before major vtigercrm-5.x branching, we reap major merging benefits. If only after, we get zero backporting crosstalk between branches, like we have with vtigercrm/branches/4.2 and vtigercrm/trunk. Fundable Fixes -------------- What about setting up a fundable.org project for sponsoring source cleanup? We who are interested in seeing the code beautified could assign a monetary value to that interest. Enough support would collectively make it worth the core team's while to stop coding for a few days, and clean up the broken windows of the source formatting. Volunteers would of course augment their efforts at the same time, and going forward, friendly admonishment could be leveled upon lazy checkins with poorly formatted source. http://fundable.org/ (example) http://www.fundable.org/groupactions/ploneboard-phase-one/view?searchterm=plone _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f2aae45a/attachment-0005.html From richie at vtiger.com Thu Jul 13 01:46:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:46:05 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> Message-ID: <10c67107064.-1678188602298141788.6045287401021222103@@vtiger.com> I second /sak. Contribute your code and we will have it in the 4.2.x branch and then have it subsequently ported to the 5.x too. We could have done it much earlier but it is far too late to get any contributions into 5.x at this stage. As far as possible, keep your changes in separate files so that they can be function invoked from the core code. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- dennis, On 7/11/06, Dennis Grant <dgrant at accuratetechnologies.com> wrote: > Ladies and Gentlemen, > [snip] > > Our current installation is a heavily-modified (and I do mean HEAVILY) > modified 4.3.2 installation. To be honest, I painted myself into a bit > of a corner with the way I implemented our code changes, such that > upgrading to newer versions is a formidable challenge. this is a mistake many people do. you have choosed to fork the project instead of trying to work with the community. and all this people end up in the same corner as you... :-) > 1) For the love of all that is holy, PLEASE COMMENT YOUR CODE! I'm pretty sure that the vtiger developers will accept you code comment patches... your duty if that is what you really want... > I don't want to get all programmer grammer nazi here, but I've been > ripping my hair out by the roots for the last few hours, and it's all > totally unnecessary. keep posting patches to the trac please... the people managing the 4.x branch have been very responsive and are doing a good job... cheers, /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/8bd60cb5/attachment-0003.html From richie at vtiger.com Thu Jul 13 01:49:51 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:49:51 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152669490.16985.122.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> Message-ID: <10c6713e13e.2152742122979094039.4943172801070965118@@vtiger.com> I agree with Matt. We have just started to work on a API-basis. The APIs will be difficult to use initially no doubt. I expect the APIs to be APIs like by 5.2 only as it is a huge change in mindset. Moreover, whatever APIs we have now, have to be properly documented and made much more usable. Matt has pointed out quite a few lacunaes and I do assure you that we do intend to fix them. Guidance and direction on the implementation toward achieving the same are welcome. To all System Integrators, yes, I do understand your pain. But, please understand getting rid of legacy code is much easier said than done. As of now, we will have to live with what we have. Post 5.0, we will make appropriate changes. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- > [snip] > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > of a corner with the way I implemented our code changes, such that > > upgrading to newer versions is a formidable challenge. > > this is a mistake many people do. > you have choosed to fork the project instead of trying to work with > the community. > > and all this people end up in the same corner as you... :-) > While I would normally agree 100% with Sergio on this point, I think we need to take the history of this project into consideration and maybe look at the bigger picture. There was a point in this project where you could come along, see a project with a fairly vibrant community forming, an interesting product being developed and a complete lack of direction and management. This type of environment is ripe for internal forks and the fact that the project didn't fork into a new OSS project is nothing short of a miracle (seriously!). I think Dennis is just the first one to cry out for help publicly, there are probably many more out there like him (I know of 6). The system integrators had a choice to make... Stand behind the OSS project in all it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. While in most cases I would say you're loony for privately forking a strong OSS project, in those cases I would say it was a justifiable move (i'm biased of course). Ok, so there have to be a _ton_ of cool features and ideas floating around in all these private forks and I think the project managers should make a full effort to get these integrators back into the community and help them get their features in 5.x. Why not put them in 4.x? Here are the options as far as I see them for people who have forked from 4.x: 1) Keep running with your own 4.x fork even after the community drops 4.x in favor of 5.x. Good luck, have fun, and let us know how that works out :). 2) Submit patches for all your features into 4.x, get them integrated, then submit them for 5.x (or hope some wonderful soul did it for you). If you have to submit them yourself after you've done 4.x, chances are you will miss the final release of 5.x and will be in a stable period that may be harder to get your features into. 3) If not already done, stabilize your 4.x fork and get busy forward porting everything to 5.x. You'll need to create your own upgrade path for your company/customers but IMHO you're chances of success are better in this case. Some of your features may not be accepted, but maybe the underlying framework that you need to enable those features can be, or if you're lucky, the API will do what you need (don't hold your breath). It really comes down to options 2 and 3, and who wants to double all their work when you know damn well that 4.x is going to be abandoned now that 5.x shows the promise it does. And I mean that with absolutely no disrespect for the people working hard on maintaining 4.x for the community. Will 4.x be maintained forever? I highly doubt it, once 5.x stabilizes and upgrade paths are figured out we'll certainly want those developer resources moved to 5.x right? About code comments: I'm in no position to preach about code comments, but I am getting better at it (code comments that is :). What I think we could use _way_ more than code comments is a sane API with at least _some_ standardization and logic to it. But I don't have the time to do it or fix the millions of things that will break, so I'll just shut up now. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/889d7c68/attachment-0005.html From richie at vtiger.com Thu Jul 13 01:51:01 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:51:01 -0700 Subject: [Vtigercrm-developers] 5.x webmail changes In-Reply-To: <1152677172.16985.144.camel@localhost.localdomain> References: <1152677172.16985.144.camel@localhost.localdomain> Message-ID: <10c6714f425.4775035562108243105.2718638484930626999@@vtiger.com> No probs Matt. If it does not work, let us give what works the best way we can. We will revisit this later. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- I just can't get POP to work worth a crap with php_imap (used in the webmails module) so I am going to drop POP support all together. Richie and I had decided to do this initially but I left it in to see if maybe I could get it to work. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/23b5e029/attachment-0003.html From richie at vtiger.com Thu Jul 13 01:54:53 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:54:53 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c67187bff.-5041963494012382301.4384583989565056693@@vtiger.com> I take all your comments with eyes closed. Kindly expect the changes asap. Please do refer to my prev mail. Comment as an afterthought is like a Thank You after a day the event has occured, utterly worthless. So, yes, this 'utterly worthless' post-coding comments will have to be lived with for now. The instructions have been sent to have all the on-the-fly comments to be integrated as much as possible, as relevant as possible. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > I think many of us who are working on the periphery with vtigercrm have > pet peeves about the formatted representation of the source code. I am actually fairly agnostic when it comes to code FORMAT. I think it's possible to waste a great deal of heat & light arguing over things like: if ($foo) {  bar; } vice if ($foo) {  bar; } vice if ($foo) { bar; } I really don't care one way or another, and attempting to force people into an alien code format just for the sake of uniformity is really not worth the effort. It's a freakin' if statement testing if $foo is set and if it is, it executes bar - that's what matters. I don't even care if the database access API (for example) is the same everywhere - as long as I can figure out what is going on, I don't particularly care about HOW you do it. I'm a big boy, and I've written and maintained a ton of code. I can adopt. What I DO care about is that code is commented AS IT IS WRITTEN - not after the fact, but as it goes into the code. I, as an integrator, need to know how the code functions so I can quickly track down bugs, find where features reside so I can modify them, and identify places to hook into for integration. I need to know WHY something is the way it is, and the only way to do that is through comments. > No few persons (rightly) want to clean up a fraction of the code > when new checkins aren't guaranteed follow the same standards. I (mostly) disagree - every comment is worth its weight (figuratively speaking) in gold. I'd love it if somebody went through and commented the entire codebase, but I understand that's a lot of work - and while I think the dividends that pays are big enough to make the pain worthwhile, I also understand that it's not very sexy and so not likely to happen without somebody explicitly funding it. (Hell, fund ME, and I'LL do it) But I **DO** think that we can at least stop the bleeding by requiring that all NEW code be properly commented. It takes a miniscule amount of effort on the part of the coder and the check-in authority, and it pays such enormous dividends for later maintenance that we really cannot afford NOT to do it. > keep posting patches to the trac please... > the people managing the 4.x branch have been very responsive and are > doing a good job... I have submitted a variety of patches to a variety of places, including this list, and to the best of my knowledge, not a single patch has made it into the core. Some of this may be my fault, and as I mentioned in my first message, I intend to revamp my own code maintenance process to operate more like a private fork of the Linux kernel, such that I can generate actual diff patches, with the intent of making the incorporation of my changes into the core (when it applies - it doesn't always have universal utility) easier. > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). Actually, I think with VTiger you are going to see a lot of private forks, because individual businesses have their own needs and wants that are supersets of core VTiger functionality that simply don't apply to other businesses. My life is easier the smaller the delta is between the vanilla VTiger core and my own fork, so I intend to try and get as many of my changes put into the V5x core as possible - but the bottom line is that there will be things that my management want in our CRM that nobody else in the world will want, and that's fine. > Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or leadership, or fork and be in charge of their own destiny. I literally had no choice. I was directed to make the CRM do certain things (after all, I have the source code) and "it doesn't do that out of the box" was NOT an acceptable answer. Even "that's coming in the next version of the CRM" is increasingly hard to justify, given how long it has taken for 5.0 to solidify. Some of the things I have done are really very pretty. Others are horrible, horrible hacks (my version supports localized currencies, with exchange rates, but you don't want to know how....) Other changes are less obvious. For example, I was required to modify the Quote engine so that it preserved the order that products were added to a quote and printed them out accordingly - totally cosmetic, but our sales guys had a valid need for that to happen, so I did it. > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Bingo. As far as I am concerned, 4.x is a dead tree being maintained only as long as necessary to get 5.x established, after which it will be dropped. But the habits that NEED to be carried into 5.x MUST be established NOW. Comment your code. Every IF has an ELSE - even if that ELSE should never ever execute. Simple simple simple; but yet they pay enormous dividends later on. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/6f714b17/attachment-0005.html From richie at vtiger.com Thu Jul 13 01:56:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:18 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> Message-ID: <10c6719c9f2.-6173366446330663734.-8914245299430889257@@vtiger.com> Well, well, /sak, hold on! We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)! Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- Mat, v4.x would not be abandoned while there is people interested in maintaining it, that's all needed in open source, interested and executive people... it can be mantained forever while this condition is met... and I agree with you that there was (is ?) an utterly lack of receptive response to community developers from the core team, and the project was crying for a fork, but all those people creating private forks also lacked the balls to create a serious *public* fork... I mean, if you are going to fork, then fork in all it's glory... those people that never submitted a patch, never figthed for more open development, created their own private branch, and then came up here whining, are ... well, whiners IMO those who want to mantain v4.x just need to step up and do something about it... cheers, /sergio On 7/11/06, Matthew Brichacek <mmbrich at fosslabs.com> wrote: > > [snip] > > > > > > Our current installation is a heavily-modified (and I do mean HEAVILY) > > > modified 4.3.2 installation. To be honest, I painted myself into a bit > > > of a corner with the way I implemented our code changes, such that > > > upgrading to newer versions is a formidable challenge. > > > > this is a mistake many people do. > > you have choosed to fork the project instead of trying to work with > > the community. > > > > and all this people end up in the same corner as you... :-) > > > While I would normally agree 100% with Sergio on this point, I think we > need to take the history of this project into consideration and maybe > look at the bigger picture. > > There was a point in this project where you could come along, see a > project with a fairly vibrant community forming, an interesting product > being developed and a complete lack of direction and management. This > type of environment is ripe for internal forks and the fact that the > project didn't fork into a new OSS project is nothing short of a miracle > (seriously!). > > I think Dennis is just the first one to cry out for help publicly, there > are probably many more out there like him (I know of 6). The system > integrators had a choice to make... Stand behind the OSS project in all > it's glory and be at the mercy of a project with no direction or > leadership, or fork and be in charge of their own destiny. While in > most cases I would say you're loony for privately forking a strong OSS > project, in those cases I would say it was a justifiable move (i'm > biased of course). > > Ok, so there have to be a _ton_ of cool features and ideas floating > around in all these private forks and I think the project managers > should make a full effort to get these integrators back into the > community and help them get their features in 5.x. Why not put them in > 4.x? Here are the options as far as I see them for people who have > forked from 4.x: > > 1) Keep running with your own 4.x fork even after the community drops > 4.x in favor of 5.x. Good luck, have fun, and let us know how that > works out :). > > 2) Submit patches for all your features into 4.x, get them integrated, > then submit them for 5.x (or hope some wonderful soul did it for you). > If you have to submit them yourself after you've done 4.x, chances are > you will miss the final release of 5.x and will be in a stable period > that may be harder to get your features into. > > 3) If not already done, stabilize your 4.x fork and get busy forward > porting everything to 5.x. You'll need to create your own upgrade path > for your company/customers but IMHO you're chances of success are better > in this case. Some of your features may not be accepted, but maybe the > underlying framework that you need to enable those features can be, or > if you're lucky, the API will do what you need (don't hold your breath). > > It really comes down to options 2 and 3, and who wants to double all > their work when you know damn well that 4.x is going to be abandoned now > that 5.x shows the promise it does. And I mean that with absolutely no > disrespect for the people working hard on maintaining 4.x for the > community. Will 4.x be maintained forever? I highly doubt it, once 5.x > stabilizes and upgrade paths are figured out we'll certainly want those > developer resources moved to 5.x right? > > About code comments: > I'm in no position to preach about code comments, but I am getting > better at it (code comments that is :). What I think we could use _way_ > more than code comments is a sane API with at least _some_ > standardization and logic to it. But I don't have the time to do it or > fix the millions of things that will break, so I'll just shut up now. > > Matt > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/609744b4/attachment-0003.html From richie at vtiger.com Thu Jul 13 01:56:58 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:56:58 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: References: <3E26E7A199CABA49822B3E6B741434F97D0905@exch.accuratetechnologies.com> Message-ID: <10c671a6747.4209201887890377357.8473992930050161702@@vtiger.com> Ok Jeff. This is new to me. Guide me on this. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Dennis Grant wrote: > Actually, I think with VTiger you are going to see a lot of private > forks, because individual businesses have their own needs and wants that > are supersets of core VTiger functionality that simply don't apply to > other businesses. This is one of the reasons why I care about making the source more merge-friendly (particularly short, vertically formatted SQL statement string lines). If we can get the codebase to the point where branching and merging is a manageable burden, customization branches have a fighting chance to be maintained in the repository. Or use a distributed repository such as bazaar-ng can be used (bzr has a trac backend now). _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/1901e1ee/attachment-0005.html From richie at vtiger.com Thu Jul 13 01:58:39 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 01:58:39 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from an VTiger Integrator In-Reply-To: <1152717401.16985.280.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0904@exch.accuratetechnologies.com> <49216030607111537l2fcb80d7q25802c2dca157eab@mail.gmail.com> <1152669490.16985.122.camel@localhost.localdomain> <49216030607120648g5b8d131ia23c6513de00a988@mail.gmail.com> <1152717401.16985.280.camel@localhost.localdomain> Message-ID: <10c671bf103.1188771339393133750.-7786000437306059540@@vtiger.com> I agree with you Matt. I will post a separate mail to have the private forkers to have their codes submitted for integration to whichever trunk needed. Richie ---- Matthew Brichacek<mmbrich at fosslabs.com> wrote ---- On Wed, 2006-07-12 at 10:48 -0300, Sergio A. Kessler wrote: > Mat, > > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... It could, but I just don't see it happening after 5.x is stable and usable. This is just my opinion based on past experience. > > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > > I mean, if you are going to fork, then fork in all it's glory... Because maintaining a proper OSS project with little to no support from the community (and abandoning the core team) is no small task, esp. when the boss is breathing down your neck to get X,Y,Z features enabled ASAP. Other things.. the community was building quickly, features were storming into the forums (even though they didn't get used) and the code was a complete cluster fuck. The pros of a fork barely outweighed the benefits and for mere mortal to come along and try to tackle it would have been near suicidal. Also, in some cases the choice to fork may have been the career saving moment after the boss found out you decided to deploy the company on project that was abandoned over night with no warning or word of upgrade paths, bug fixes, etc. > > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Most of them did submit patches and fought for more open development and when they were ignored simply took their patches and went home. Some of us were a little more vocal about it but the only reason that worked is because the critical mass needed to make a real change had already built up from the people who came before us. This really was my point in the last thread. I would normally agree with you 100% on this issue but I think this project had a period where there was a sign on the front door saying "Open for business.. Developers Welcome.. and Trespassers will be ignored (or shot)" all in the same breath. > > those who want to mantain v4.x just need to step up and do something about it... My argument wasn't really for 4.x maint. I think the current maintainers are doing a fine job of keeping the release afloat for the community (no thanks to me mind you). My point was that we should find a way to welcome these wayward forks back to the fold. How? I dunno.. but I think it's worth investigating as I am pretty sure that many many private vtiger4.x forks are floating about. Personally I am going gangbusters to try and get all of our 4.x features into 5.x since I despise being forked from a project but asking all of these integrators to do that is not nice, nor is it standard operating procedure for an OSS project.. I firmly believe that much less of this would have happened if this project was following a true OSS format during the 4.x devel and hadn't gone off half-cocked to start 5.x. Do I think 5.x was worth the wait and headache of what happened to 4.x? Not even remotely close, we could have added smarty, campaigns and all the AJAX fluff to 4.x in less time IMO. So after the wind clears.. my point really comes down to getting all these folks who are working on private forks to come back to the community project, regardless of their justification (or lack of) for the fork. In an OSS project your most valuable resource is your developers and if we can find a way to get them back it will be well worth it IMHO. Matt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/dca318ca/attachment-0003.html From richie at vtiger.com Thu Jul 13 03:46:19 2006 From: richie at vtiger.com (Richie) Date: Thu, 13 Jul 2006 03:46:19 -0700 Subject: [Vtigercrm-developers] Calling all private 4.x development owners Message-ID: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Hi! This is a call to all the 4.x private development owners. Many of you would have been working on your own version of vtiger as you would have customized it to your own needs. This is a call for those guys. The intent is to aggregate most of the common features that you have built and have them integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch or even in the 5.x branch as needed by the community. Pros: By doing the above, you will be able to be in sync with the latest and greatest developments happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a read as one would think of but we are working on it. Yesterday we had comments about the code not being properly commented, we are working on that right now even as I type this post. So, the idea I am conveying is that we are not perfect but are listening to the comments and taking actions too. Hence, please do keep the faith. Cons: By maintaining your own code bases, you lose out on the community benefits like identifying bugs, feature integration, new ideas, etc. We welcome your contributions. Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise the folly. Let us get on with it and make vtiger a success. I have learnt from my past mistakes. Join the team, come on board. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/65c2edda/attachment-0005.html From dgrant at accuratetechnologies.com Thu Jul 13 07:47:52 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 10:47:52 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> > v4.x would not be abandoned while there is people interested in > maintaining it, that's all needed in open source, interested and > executive people... > it can be mantained forever while this condition is met... Yeah, but is it worth it? The 4.x codebase is really - sorry guys, I don't mean to take shots at you - but let's face it; it's really very nasty. Some of it is a good deal better than others... but there are three or four different coding paradigms all mixed together just on database queries alone, never mind display models and modularity and whatnot. It *works* great, but it's a serious bitch to maintain. As I mentioned earlier, I haven't looked at the 5.0 codebase, but it is my hope and expectation that it is a lot better. > and I agree with you that there was (is ?) an utterly lack of > receptive response to community developers from the core team, No kidding.... > and the > project was crying for a fork, but all those people creating private > forks also lacked the balls to create a serious *public* fork... > I mean, if you are going to fork, then fork in all it's glory... Dude, I *NEVER* wanted to fork. I'd be *MUCH, MUCH* happier if I could run a vanilla install of VTiger with zero custom code in it. I was forced into forking by a lack of response from the core dev team, yes - but more so by the fact that I had users who wanted features and I needed to get them done NOW. > those people that never submitted a patch, never figthed for more open > development, created their own private branch, and then came up here > whining, are ... well, whiners IMO Ahem. I tried to get patches into the core. I tried to get the dev team to do stuff by reporting bugs and providing detailed debug info. But there are limits as to how much time in a day I can burn trying to get an unresponsive dev team to fix my bug. "Why is this still broken?" "Well, I reported it to VTiger last month, and they haven't fixed it yet....." That just doesn't cut it. > My point was that we should find > a way to welcome these wayward forks back to the fold. How? I dunno.. Well, the way I'm going to do it is to roll all my features into 5.0 (which is a huge job, but so it goes) and then cut a patch set for merging into the main core. My expectation is that VTiger's version of Linus (or Alan Cox, or whoever) will then go through the patch set, and then either merge or reject patches based on merit - just like in the kernel. I will then work on trying to address concerns with my rejected patches, so as to get them accepted, except in cases where the patch is clearly local in scope - and those I will maintain myself. BTW, who is the local Linus? > So after the wind clears.. my point really comes down to getting all > these folks who are working on private forks to come back to the > community project, regardless of their justification (or lack of) for > the fork. In an OSS project your most valuable resource is your > developers and if we can find a way to get them back it will be well > worth it IMHO. I agree - and the best way to do that is to be RESPONSIVE. I understand that *my* problem may not be the top priority. I understand that core dev team members are NOT going to just drop everything and look after me. But I *do* expect a response, and to get into the pipeline, and to be given reasonably regular status updates on the status of my problem. And if I submit a patch, I expect it to be reviewed and either accepted or rejected in a reasonable timeframe. I don't know how many of you were/are involved in Linux kernel development, but I used to get help from people like Alan Cox and Linus on a regular basis. If a particular bit of hardware wasn't working, and it looked like a bug in Linux kernel code, we'd trade emails on a daily basis to debug the problem. That's the level of service we're talking about. And this is a good start: > Your comments are well taken. These will be in place at the earliest. > I know that this will be a quick fix but instructions have been sent > across to have the code properly commented from now on for any future > development/bug fixes. Thanks! DG From sergiokessler at gmail.com Thu Jul 13 08:40:25 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Thu, 13 Jul 2006 12:40:25 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> Message-ID: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak From allan.bush+vtiger_dev at gmail.com Thu Jul 13 08:59:48 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Thu, 13 Jul 2006 08:59:48 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0906@exch.accuratetechnologies.com> <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From dgrant at accuratetechnologies.com Thu Jul 13 09:10:09 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 13 Jul 2006 12:10:09 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CD8@exch.accuratetechnologies.com> > > BTW, who is the local Linus? > unfortunely, there is no local linus, Who is in charge of V5? Who is the core dev team leader? > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) Uh... thanks, but I'm going to have to pass. At this point, with V5 (seemingly) approaching completion, V4 is a dead end. I intend to move forward on V5 and get away from V4 as fast as I can. DG From jeri at vtiger.com Thu Jul 13 18:04:37 2006 From: jeri at vtiger.com (Jeri John) Date: Thu, 13 Jul 2006 18:04:37 -0700 Subject: [Vtigercrm-developers] Latest Docs updated Message-ID: <10c6a904f47.6172353167700401689.-5432537231218327818@@vtiger.com> Dear team, The latest Docs for vtigerCRM 5.0 beta 2 is updated, and it is available in the following url. http://vtiger.com/products/crm/phpdocs/index.php Thanks & Regards, Jerry. ------------------------------------------ D.Jeri John Skype: jerijohn_vtiger Toll Free: +1 877 788 4437 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060713/f9eb2259/attachment-0003.html From mmbrich at fosslabs.com Thu Jul 13 18:16:45 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 19:16:45 -0600 Subject: [Vtigercrm-developers] Custom fields for activities Message-ID: <1152839806.16985.560.camel@localhost.localdomain> Does anyone have plans to implement custom fields in the activities module? Matt From mmbrich at fosslabs.com Thu Jul 13 19:16:38 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 13 Jul 2006 20:16:38 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <1152843399.16985.611.camel@localhost.localdomain> I have some ideas for cleaning up the structure of vtiger as we move forward. I am just going to lay them out here, let me know what you think. My basic idea comes down to writing wrapper classes that are used to abstract most of the unnecessary functions from developers and instead provides a uniform API to access modules, permissions, input, etc. The idea comes in three pieces. Common UI classes, most of which is already done with the new UI. A "mainframe" engine similar to the joomla $mainframe. And last but certainly not least is an entity engine that would abstract most of the entity details from developers and truly provide the unified API. Lets start with the big one, Entity Engine: The entity engine would be accomplished in three steps. The first step is to move all common variables and functions into the EntityEngine class (which extends CRMEntity). The entity engine would go into the DB to populate these with the correct info. For example tab_name, tab_name_index and all the other most common variables would be stored in the db and populated when the entity engine has a request for that module. The next step would be to create common set of functions in this class that would be exposed to the developer. The initial functions I can think of are things like get/set functions for different field values, etc. The last step to the entity engine would be an XML install system. If a developer came along and wanted to create a simple data collection module, like the current campaigns module, they would simply create an XML file that defines all the fields to be displayed, what relationship types are allowed, etc. The entity engine would then create the correct tables, populate the needed tables for the entity engine (the ones holding tab_name, etc) and register the new entity type with the system. This leads into the UI system because if the developer is just creating the XML file, how are common views displayed (list, detail, edit, relatedlists)? The UI system would be a set of classes to extend smarty and again abstract the gory details of the internal workings from the developer. VTigerUI::DetailView($entity) would follow a flow: 1) Display all common elements (header, etc): $this->createTigerHeader(); 2) Display the common 2 tab display for edit/detail/related views $this->getCommonUI("DetailView"); 3) Create a block for each block type in the DB, and create the fields for it as well. $this->assign("NUM_BLOCKS",sizeof($entity->blocks)); foreach($entity->blocks as $blockid=>$fields) { $block_fields = array(); foreach($fields as $fieldname=>$field_data) { $block_fields = $this->CreateEditField($fieldname,$field_values); // creates new edit fields based on uitype and returns an array as $array[sequence_number] = "HTML output" } $this->assign("BLOCK_".$blockid,$this->addBlock($blockid, $block_fields)); } 4) Display data :) And just like magic, the ListView, DetailView, EditView and CallRelatedList files can all go away and these common views can be managed in a much easier way. Next, the mainframe. In joomla (as far as I understand) the mainframe is meant to handle all GET, POST, REQUEST and SESSSION variables and it also sanitizes that input before giving it to the developer ($mainframe->get_input("REQUEST","data")). On top of this it handles some user security and other things. In vtiger I could see it being used for many similar things. Take for example the CreateDetailField() function call above. Inside of this call would be: if($mainframe->is_allowed("Detail",$field->id)) { stuff.. else return; There are still other details to be worked out, but you see that this isn't a _really_ large change for the flexibility it will give you in the system. After it's all said and done you should have two sets of documents that a developer would have access to, the module developers document that would be a document outlining the three pieces discussed above and then the core developer document that would document all the core back-end functions (everything in utils/). Of course there would be a way to overwrite these methods so that developers can still create non-entity based modules (webmails, calendar, rss, etc), but it should make life much easier for module developers who follow the entity structure in vtiger. What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well. Matt From Matjaz.Slak at atol.si Thu Jul 13 23:42:52 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:42:52 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: Hi! If there's no one else, I volunteer to be the v4 Linus. I have the exact same position as a lot of other people wrote about here - basically my own fork of v4.2.3, and I'm now working to get my patches compatible with v4.2.4 so as to get back to the main trunk. And it's a lot of work, which I need to trade with my basic task - which is supporting several customers we have on vTiger. I hope I will have my set of patches (there might be up to 100 of them, as it's looking right now :) ready in a week or so. I belive we as vTiger Dev team should provide more support for 4.2.x stream -> I guess that almost ALL of vTiger's "real world" users use that right now. And they might go for v5 when it's stable, but that won't be (in my experience) for at least 6 months after it's released. If you want me, I'm here. Just give me a direction to start in, and I (and my three colleagues here) can be reviewing submitted work in no time. And discussing it with you the team here to get decissions on include/reject. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Sergio A. Kessler" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:40 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator On 7/13/06, Dennis Grant wrote: > > v4.x would not be abandoned while there is people interested in > > maintaining it, that's all needed in open source, interested and > > executive people... > > it can be mantained forever while this condition is met... > > Yeah, but is it worth it? well, up to you ;-) (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > BTW, who is the local Linus? unfortunely, there is no local linus, mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, and then Philip and Allan Bush were trying to help, but I imagine they are in lack of time... you can be the linus of v4 if you want... it's a meritocracy (it's that spelled correctly ?) > > I agree - and the best way to do that is to be RESPONSIVE. the problem is there is NO one that can respond about v4, the core team is working full on v5... and v4 has no Linus (at least with enough time)... /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/5bc91030/attachment-0003.bin From Matjaz.Slak at atol.si Thu Jul 13 23:43:51 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 14 Jul 2006 08:43:51 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <3bec26390607130859m703b5689wf5114791d4e78339@mail.gmail.com> Message-ID: Hi! Allan, if you need any help, let me know (see my previous post). Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "Allan Bush" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 13.07.2006 17:59 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator As Sergio said I've kind of taken responsibility for the 4.2 branch (along with a bunch of help from Jeff and Joel). Unfortunately I just don't have as much time to devote to the project as I'd like. I encourage you to use the trac system as there is just too much noise in the forums to parse through it all. If you post a trac ticket with milestone 4.2.5 I WILL look at it and if you attach a patch (preferably against the latest 4.2 svn code) I WILL review it and check it in or leave a comment of why it didn't get checked in. For my part the lack of feedback from other developers/users has been somewhat discouraging. For example after the 4.2.4 release a couple bugs where discovered so I planned a quick 4.2.4.1 release but I wasn't able to find anyone to test it and I didn't have the time myself so that's still sitting on the back burner. This week I'm partly on vacation and don't have the time to deal with non critical stuff but I'm setting aside some time early next week to review any new tickets and get 4.2.5 back on track. I've committed to that release, but afterwards unless I see a lot more community support that will probably be the end of the 4.2 line. Allan On 7/13/06, Sergio A. Kessler wrote: > On 7/13/06, Dennis Grant wrote: > > > v4.x would not be abandoned while there is people interested in > > > maintaining it, that's all needed in open source, interested and > > > executive people... > > > it can be mantained forever while this condition is met... > > > > Yeah, but is it worth it? > > well, up to you ;-) > (I mean, up to the outside comunity, vtiger core team is heavely focused en V5) > > > BTW, who is the local Linus? > > unfortunely, there is no local linus, > mike fedyk was doing a terrific job on maintaining v4, but then he dissapeared, > and then Philip and Allan Bush were trying to help, but I imagine they > are in lack of time... > > you can be the linus of v4 if you want... > it's a meritocracy (it's that spelled correctly ?) > > > > > I agree - and the best way to do that is to be RESPONSIVE. > > the problem is there is NO one that can respond about v4, > the core team is working full on v5... > and v4 has no Linus (at least with enough time)... > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/d4b8b53a/attachment-0003.bin From dgrant at accuratetechnologies.com Fri Jul 14 06:24:34 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 09:24:34 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG From allan.bush+vtiger_dev at gmail.com Fri Jul 14 07:32:02 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 07:32:02 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Proper use of a OO design would solves this for both of you. All the common code and default module behavior should be moved into the a set of default classes or "engines" as Matthew is calling them. Then for each module we inherit the classes and make a couple method calls (ideally this is abstracted as well so to create a module all you do is create a class which inherits the base class) which generates the required database actions / html page. If you want something different then the default, like Dennis describes, you simply extent the required method in your inherited class. This way the common code is abstracted and only needs to exist once while the module specific code is in the module for easy modification. The code is already partly structured this way (it's just not used properly). There's already a base class CRMentity which every module inherits from. What needs to be done is to clean up the CRMentity - module relationship so that only methods common to all modules and their default behavior is defined in CRMentity and only things which need to be changed are defined in the module class. Then we need to create a class for each page type (again some of this already exists. ala inculdes/Listview.php, but here it isn't used at all) with the default behaviors of each page type. Now we have an option, either we have each module inherit these page type classes (making changes as needed ala CRMentity) and have a common set of calls to render each page type or we create a SMALL file in each module with a couple of calls to the page type class to render the page and we substitute new functions as needed for customizations. Personally I think the first option here is the better design, but unless you get it right it could become difficult to modify the parts of the page you want without re-witting a lot of the base class (should be avoided at all cost or we're right back in the mess we are in now). That was a bit of a long winded explanation, let me know if anyone requires clarification. On 7/14/06, Dennis Grant wrote: > > > My basic idea comes down to writing wrapper classes that are used to > > abstract most of the unnecessary functions from developers and instead > > provides a uniform API to access modules, permissions, input, etc. > > Oooh. > > > The idea comes in three pieces. Common UI classes, most of which is > > already done with the new UI. A "mainframe" engine similar to the > > joomla $mainframe. And last but certainly not least is an entity > engine > > that would abstract most of the entity details from developers and > truly > > provide the unified API. > > To be honest, I think this is moving in the wrong direction. > > If everybody used the same vanilla VTiger installation, this would make > a lot of sense - one common UI for the entire set of users, and a much > cleaner codebase for developers. Happy happy for everybody. > > Unfortunately, a lot of us are NOT using vanilla VTiger; we have to > customize the application to meet the needs of our user base. And a lot > of the time, our users really really want changes that may seem utterly > trivial from a developer standpoint, but for whatever reason, they > REALLY want it that way. > > And the customer is always right, so we have to do it. > > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. > > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. > > Yes, it makes changing common code more difficult, 'cause now I have to > drill down into each submodule and make the same change over and over > again, and I can certainly see where modularizing and sharing code makes > that job a lot easier. But the assumption it is based on, while true of > a vanilla install, is NOT true in a customized install environment. > > I'd prefer to see every module live in its own subdirectory of the > modules directory, much as is does in 4.x, but more rigorously (ie, > separate Sales Orders from Purchase Orders, don't group them in Orders) > and each module should have its own, atomic codebase. > > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. > > I'd like to see some standardization on the module file structure > though: > > modules/Foo/EditView.php for the edit UI for the module object > modules/Foo/DetailView.php for the detailed view of the object > modules/Foo/Save.php for saving the object to the DB > modules/Foo/CreatePDF.php for creating a PDF version of the object > modules/Foo/UIElements.php for the common UI functions (that are now > stuffed in include/utils.php > modules/Foo/BarPopup.php if there is a popup window to select associated > Bar objects > > etc. > > It makes dealing with modules easier if we know where the various > functions are kept. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From isimpkins at premierrealm.com Fri Jul 14 08:10:32 2006 From: isimpkins at premierrealm.com (Ivar Simpkins) Date: Fri, 14 Jul 2006 17:10:32 +0200 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: Sorry DG this doesn?t wear with me. 'The price of programmability' is what it's about. There is the short term solution and it has its merits, but planning a structured API can only have its long term benefits. Where does vTiger want to be in the future, this has to be answered. If it wants to be in the top ratings, then I think every effort has to be made, to reconsolidate and then plan for the future. Sure the learning curve is steep but the rewards are enormous. Would it not be better to prefect a generic function, in an OO structure which does all you want, one entrance, one exit and away you go. A well documented code base that automatically builds your API documentation gives you a valuable toolbox, now concentrate the communities efforts on pulling together and raising the lowest common denominator and you have a work the progresses moving a an incredible rate. And as Matt said: 'What do you think? Am I nuts? Does it take too much away from the developer in the name of standardization? To me it feels like the next natural step to cleaning up the system and creating defined layers as far as security, display and entities are concerned. It should cut down on all the unnecessary code re-creation in the system as well.' NO, you are not nuts, it gives you the long term ability to use ones creativity to best avail without (always) having to worry about the nuts & bolts. I think this is a courageous step in the right direction, where, after surviving the learning curve, all will benefit, creating a homogeneous standardised kernel, with the ability of Plug 'n Play ala Joomla and probably much more. 'The price of programmability' is high but seeing the caliber of work produced so far, I am convinced Matt is on the right track to creating a new dimension in CRM. Please excuse the tone but its hard to see the same mistake been made over and again. Ivar > My basic idea comes down to writing wrapper classes that are used to > abstract most of the unnecessary functions from developers and instead > provides a uniform API to access modules, permissions, input, etc. Oooh. > The idea comes in three pieces. Common UI classes, most of which is > already done with the new UI. A "mainframe" engine similar to the > joomla $mainframe. And last but certainly not least is an entity engine > that would abstract most of the entity details from developers and truly > provide the unified API. To be honest, I think this is moving in the wrong direction. If everybody used the same vanilla VTiger installation, this would make a lot of sense - one common UI for the entire set of users, and a much cleaner codebase for developers. Happy happy for everybody. Unfortunately, a lot of us are NOT using vanilla VTiger; we have to customize the application to meet the needs of our user base. And a lot of the time, our users really really want changes that may seem utterly trivial from a developer standpoint, but for whatever reason, they REALLY want it that way. And the customer is always right, so we have to do it. I don't, for example, want to see something like where Accounts and Contacts share the same DetailView module - because in my setup, there are large differences between the DetailView we do for Accounts, and the DetailView we do for Contacts. It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules in a vanilla install, because that way, if I'm working on the Contacts DetailView, I don't have to worry about changes spilling over into the operation of another module. Yes, it makes changing common code more difficult, 'cause now I have to drill down into each submodule and make the same change over and over again, and I can certainly see where modularizing and sharing code makes that job a lot easier. But the assumption it is based on, while true of a vanilla install, is NOT true in a customized install environment. I'd prefer to see every module live in its own subdirectory of the modules directory, much as is does in 4.x, but more rigorously (ie, separate Sales Orders from Purchase Orders, don't group them in Orders) and each module should have its own, atomic codebase. We're doing things in the field that are far more advanced than just custom fields (although we make use of those too) and we need the flexibility that comes with exposing the dirty details. Same thing with database queries. It's tempting I know to try and abstract all those away with wrapper functions (and there are some wrapper functions that are OK - something like getContactEmail($contactID) or getContactAccount($contactID) or isDeleted($crmID) are all simple and handy and useful for simplifying out some of the database access overhead. But as soon as you start getting into more complex queries, I want to see the SQL right there in the code. I need to understand EXACTLY what is going on, and I may need to muck with the query; especially if I have changed/extended the database/table. For example, our users had a need for Quotes to preserve the order in which Products were added to the Quote. The intent is that they wanted the PDF export of a Quote to do something like this: Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Big expensive item 2 Option A for item 2 Option C for item 2 But as the items came out of the database in the order in which they were added to the database, what they got once they saved it might be something like: Option C for Item 2 Option A for item 1 Big Expensive item 2 ...etc >From a developer point of view, that's OK, 'cause all the items are on there and the total is right, so what's the big deal? Well to them, this WAS a big deal - a really big deal. They wanted this changed, and my boss wanted it to happen NOW; so I extended the QuoteProductsRel to include a sequenceNumber. Then they wanted to be able to add headings, like this: Heading 1 Big expensive item 1 Option A for item 1 Option B for item 1 Option C for item 1 Heading 2 Big expensive item 2 Option A for item 2 Option C for item 2 So I extended QuoteProductsRel to include a heading field that, if populated, would print on the line preceding the product it was associated with. Etc etc etc. This sort of stuff is WAY easier if the code to do it is right there, and not buried in a common function somewhere (like a lot of the UI code is, where you have the Mother of all If Statements lurking in utils.php that has to account for *every single module* before it presents the UI. I'd like to see some standardization on the module file structure though: modules/Foo/EditView.php for the edit UI for the module object modules/Foo/DetailView.php for the detailed view of the object modules/Foo/Save.php for saving the object to the DB modules/Foo/CreatePDF.php for creating a PDF version of the object modules/Foo/UIElements.php for the common UI functions (that are now stuffed in include/utils.php modules/Foo/BarPopup.php if there is a popup window to select associated Bar objects etc. It makes dealing with modules easier if we know where the various functions are kept. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 2006/07/13 From mmbrich at fosslabs.com Fri Jul 14 09:54:21 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:21 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> Message-ID: <1152896061.16985.648.camel@localhost.localdomain> On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > Proper use of a OO design would solves this for both of you. > > All the common code and default module behavior should be moved into > the a set of default classes or "engines" as Matthew is calling them. > Then for each module we inherit the classes and make a couple method > calls (ideally this is abstracted as well so to create a module all > you do is create a class which inherits the base class) which > generates the required database actions / html page. If you want > something different then the default, like Dennis describes, you > simply extent the required method in your inherited class. This way > the common code is abstracted and only needs to exist once while the > module specific code is in the module for easy modification. I think we're right on the same page here, but if you take for example the Campaign.php class, it should not be needed. All of the functions and variables it defines are generic and do not need to be re-created for each module that does simple data collection and display. If you want to write a module that does more than this, and will need it's own class, by all means, extend the EntityEngine class (or CRMEntity if it becomes the engine) and then continue on your way. > > The code is already partly structured this way (it's just not used > properly). There's already a base class CRMentity which every module > inherits from. What needs to be done is to clean up the CRMentity - > module relationship so that only methods common to all modules and > their default behavior is defined in CRMentity and only things which > need to be changed are defined in the module class. But even things that need to be changed, may not need to be changed and defined in separate module classes. For example all the get_leads, get_contacts, etc functions can be standardized and instead use a set of DB keys to track relationship_types allowed for a module. function get_leads($id,$entity) { if($this->is_relationship_type($entity->module,"Leads")) { stuff.. } else return false; } > Then we need to > create a class for each page type (again some of this already exists. > ala inculdes/Listview.php, but here it isn't used at all) with the > default behaviors of each page type. Now we have an option, either we > have each module inherit these page type classes (making changes as > needed ala CRMentity) and have a common set of calls to render each > page type or we create a SMALL file in each module with a couple of > calls to the page type class to render the page and we substitute new > functions as needed for customizations. Personally I think the first > option here is the better design, but unless you get it right it could > become difficult to modify the parts of the page you want without > re-witting a lot of the base class (should be avoided at all cost or > we're right back in the mess we are in now). Correct, and I think if you created the correct UI classes you could very easily overwrite the functions you want to customize and _only_ the functions you want to customize (like AddBlock() for example). > That was a bit of a long winded explanation, let me know if anyone > requires clarification. I think we're pretty close to being in the same school of though but maybe I needed to explain my thoughts in a bit more detail. I really just laid out a very high level overview of what I think should be done. Matt From mmbrich at fosslabs.com Fri Jul 14 09:54:58 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 10:54:58 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> Message-ID: <1152896098.16985.650.camel@localhost.localdomain> > I don't, for example, want to see something like where Accounts and > Contacts share the same DetailView module - because in my setup, there > are large differences between the DetailView we do for Accounts, and the > DetailView we do for Contacts. So in these cases you could over-ride the system DetailView by creating /Accounts/DetailView.html.php for your actual HTML stuff, and /Accounts/Detailview.php if you want to change the logic flow. If you are only changing the look/feel, then re-declare the AddBlock() function with your new special sauce inside of it and off you go. > It is a whole lot easier to deal with each module having its own code, > even if that code is 95% common with other modules in a vanilla install, > because that way, if I'm working on the Contacts DetailView, I don't > have to worry about changes spilling over into the operation of another > module. See above, the correct separation of these layers in the system can still give you the flexibility you need. > We're doing things in the field that are far more advanced than just > custom fields (although we make use of those too) and we need the > flexibility that comes with exposing the dirty details. > To create new field types it would just be a matter of creating a new UIType, populating the DB fields you want to have that uitype (via XML), and then creating the base HTML for it in the UIType.tpl file. {if {$uitype} == "230"} your_new_html {/if} On top of this you could just over-ride the system UI creator and replace it with your own display classes. > Same thing with database queries. It's tempting I know to try and > abstract all those away with wrapper functions (and there are some > wrapper functions that are OK - something like > getContactEmail($contactID) or getContactAccount($contactID) or > isDeleted($crmID) are all simple and handy and useful for simplifying > out some of the database access overhead. > > But as soon as you start getting into more complex queries, I want to > see the SQL right there in the code. I need to understand EXACTLY what > is going on, and I may need to muck with the query; especially if I have > changed/extended the database/table. I actually think the entity engine will need to have a query builder in it so that the queries can be built dynamically depending on the type of data you are going for. A true entity engine (like the one in ofbiz.org) will not ever let you see a query, nor should you need to if the entity engine is doing it's job correctly. > > For example, our users had a need for Quotes to preserve the order in > which Products were added to the Quote. The intent is that they wanted > the PDF export of a Quote to do something like this: > > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > But as the items came out of the database in the order in which they > were added to the database, what they got once they saved it might be > something like: > > Option C for Item 2 > Option A for item 1 > Big Expensive item 2 > ...etc > > >From a developer point of view, that's OK, 'cause all the items are on > there and the total is right, so what's the big deal? Well to them, this > WAS a big deal - a really big deal. They wanted this changed, and my > boss wanted it to happen NOW; so I extended the QuoteProductsRel to > include a sequenceNumber. > > Then they wanted to be able to add headings, like this: > > Heading 1 > Big expensive item 1 > Option A for item 1 > Option B for item 1 > Option C for item 1 > > Heading 2 > Big expensive item 2 > Option A for item 2 > Option C for item 2 > > So I extended QuoteProductsRel to include a heading field that, if > populated, would print on the line preceding the product it was > associated with. > > Etc etc etc. > > This sort of stuff is WAY easier if the code to do it is right there, > and not buried in a common function somewhere (like a lot of the UI code > is, where you have the Mother of all If Statements lurking in utils.php > that has to account for *every single module* before it presents the UI. i hate utils.php :). But the examples you lay out above would not at all be impossible. You would simply tell the entity engine (via an XML file) that you want a seqno and header value assigned to each entity of type=Quotes, and then in the query builder it will check for seqno and if it find it, ORDER BY seqno will be appended to the query string. Really what I am trying to accomplish is to make your life easier in the long run than what it currently is, even when diverging from the standard way of doing it with-in vtiger. There is a learning curve that will come along with this but correct documentation and developer support via this mailing list should help you get past any of that. Matt From allan.bush+vtiger_dev at gmail.com Fri Jul 14 10:13:28 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 14 Jul 2006 10:13:28 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <1152896061.16985.648.camel@localhost.localdomain> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> Message-ID: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> I'm pretty sure we're on the same page Matt, my reply was more of an attempt to convince Dennis then an attempt to disagree with anything you said. In your example though I'm not sure how much I like having a function called "get_leads" in the base class. I think there's way too much coupling between "modules" right now and I'd like to get away from that, however I'm not sure what the best way to do that is without losing any of the control we currently have. That's probably another discussion though. I agree with your design, I could probably argue all day over the implementation of the details, but as long as it's constant and logical I don't care too much. On 7/14/06, Matthew Brichacek wrote: > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > Proper use of a OO design would solves this for both of you. > > > > All the common code and default module behavior should be moved into > > the a set of default classes or "engines" as Matthew is calling them. > > Then for each module we inherit the classes and make a couple method > > calls (ideally this is abstracted as well so to create a module all > > you do is create a class which inherits the base class) which > > generates the required database actions / html page. If you want > > something different then the default, like Dennis describes, you > > simply extent the required method in your inherited class. This way > > the common code is abstracted and only needs to exist once while the > > module specific code is in the module for easy modification. > I think we're right on the same page here, but if you take for example > the Campaign.php class, it should not be needed. All of the functions > and variables it defines are generic and do not need to be re-created > for each module that does simple data collection and display. > If you want to write a module that does more than this, and will need > it's own class, by all means, extend the EntityEngine class (or > CRMEntity if it becomes the engine) and then continue on your way. > > > > > The code is already partly structured this way (it's just not used > > properly). There's already a base class CRMentity which every module > > inherits from. What needs to be done is to clean up the CRMentity - > > module relationship so that only methods common to all modules and > > their default behavior is defined in CRMentity and only things which > > need to be changed are defined in the module class. > But even things that need to be changed, may not need to be changed and > defined in separate module classes. For example all the get_leads, > get_contacts, etc functions can be standardized and instead use a set of > DB keys to track relationship_types allowed for a module. > function get_leads($id,$entity) { > if($this->is_relationship_type($entity->module,"Leads")) { > stuff.. > } else > return false; > } > > > Then we need to > > create a class for each page type (again some of this already exists. > > ala inculdes/Listview.php, but here it isn't used at all) with the > > default behaviors of each page type. Now we have an option, either we > > have each module inherit these page type classes (making changes as > > needed ala CRMentity) and have a common set of calls to render each > > page type or we create a SMALL file in each module with a couple of > > calls to the page type class to render the page and we substitute new > > functions as needed for customizations. Personally I think the first > > option here is the better design, but unless you get it right it could > > become difficult to modify the parts of the page you want without > > re-witting a lot of the base class (should be avoided at all cost or > > we're right back in the mess we are in now). > Correct, and I think if you created the correct UI classes you could > very easily overwrite the functions you want to customize and _only_ the > functions you want to customize (like AddBlock() for example). > > > > That was a bit of a long winded explanation, let me know if anyone > > requires clarification. > I think we're pretty close to being in the same school of though but > maybe I needed to explain my thoughts in a bit more detail. I really > just laid out a very high level overview of what I think should be done. > > Matt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > From mmbrich at fosslabs.com Fri Jul 14 10:18:54 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 11:18:54 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> References: <3E26E7A199CABA49822B3E6B741434F97D0908@exch.accuratetechnologies.com> <3bec26390607140732q3cbc86b4o8a85328911017237@mail.gmail.com> <1152896061.16985.648.camel@localhost.localdomain> <3bec26390607141013m60bea81ctf20c9f8da04686b0@mail.gmail.com> Message-ID: <1152897535.16985.654.camel@localhost.localdomain> On Fri, 2006-07-14 at 10:13 -0700, Allan Bush wrote: > I'm pretty sure we're on the same page Matt, my reply was more of an > attempt to convince Dennis then an attempt to disagree with anything > you said. > > In your example though I'm not sure how much I like having a function > called "get_leads" in the base class. I think there's way too much > coupling between "modules" right now and I'd like to get away from > that, however I'm not sure what the best way to do that is without > losing any of the control we currently have. That's probably another > discussion though. I'm not a big fan of how this is done either but you're right, this falls into another discussion about how to clean up current practices going forward with a new structure. > > I agree with your design, I could probably argue all day over the > implementation of the details, but as long as it's constant and > logical I don't care too much. Plenty of details that are yet to be worked out ;). Matt > > > On 7/14/06, Matthew Brichacek wrote: > > On Fri, 2006-07-14 at 07:32 -0700, Allan Bush wrote: > > > Proper use of a OO design would solves this for both of you. > > > > > > All the common code and default module behavior should be moved into > > > the a set of default classes or "engines" as Matthew is calling them. > > > Then for each module we inherit the classes and make a couple method > > > calls (ideally this is abstracted as well so to create a module all > > > you do is create a class which inherits the base class) which > > > generates the required database actions / html page. If you want > > > something different then the default, like Dennis describes, you > > > simply extent the required method in your inherited class. This way > > > the common code is abstracted and only needs to exist once while the > > > module specific code is in the module for easy modification. > > I think we're right on the same page here, but if you take for example > > the Campaign.php class, it should not be needed. All of the functions > > and variables it defines are generic and do not need to be re-created > > for each module that does simple data collection and display. > > If you want to write a module that does more than this, and will need > > it's own class, by all means, extend the EntityEngine class (or > > CRMEntity if it becomes the engine) and then continue on your way. > > > > > > > > The code is already partly structured this way (it's just not used > > > properly). There's already a base class CRMentity which every module > > > inherits from. What needs to be done is to clean up the CRMentity - > > > module relationship so that only methods common to all modules and > > > their default behavior is defined in CRMentity and only things which > > > need to be changed are defined in the module class. > > But even things that need to be changed, may not need to be changed and > > defined in separate module classes. For example all the get_leads, > > get_contacts, etc functions can be standardized and instead use a set of > > DB keys to track relationship_types allowed for a module. > > function get_leads($id,$entity) { > > if($this->is_relationship_type($entity->module,"Leads")) { > > stuff.. > > } else > > return false; > > } > > > > > Then we need to > > > create a class for each page type (again some of this already exists. > > > ala inculdes/Listview.php, but here it isn't used at all) with the > > > default behaviors of each page type. Now we have an option, either we > > > have each module inherit these page type classes (making changes as > > > needed ala CRMentity) and have a common set of calls to render each > > > page type or we create a SMALL file in each module with a couple of > > > calls to the page type class to render the page and we substitute new > > > functions as needed for customizations. Personally I think the first > > > option here is the better design, but unless you get it right it could > > > become difficult to modify the parts of the page you want without > > > re-witting a lot of the base class (should be avoided at all cost or > > > we're right back in the mess we are in now). > > Correct, and I think if you created the correct UI classes you could > > very easily overwrite the functions you want to customize and _only_ the > > functions you want to customize (like AddBlock() for example). > > > > > > > That was a bit of a long winded explanation, let me know if anyone > > > requires clarification. > > I think we're pretty close to being in the same school of though but > > maybe I needed to explain my thoughts in a bit more detail. I really > > just laid out a very high level overview of what I think should be done. > > > > Matt > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From nolan at peaceworks.ca Fri Jul 14 10:44:55 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Fri, 14 Jul 2006 13:44:55 -0400 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> Message-ID: <1152899095.32568.49.camel@rockcrusher> As one of the mentioned 4.2 developers mostly lurking on this list... Like others have mentioned, I've got 2 classes of modifications: 1. those _I think_ others may be interested in 2. those _I think_ others will not be interested in What I want to know is...is what _I think_ in any way connected with reality? More to the point... How do I know whether or not I *should* submit a given patch to the current tree for 4.2.5? In my previous (though admittedly minimal) exploration, I got the sense that 4.2.x was essentially "feature frozen" and that bug/security fixes and deployment/installation/maintenance stuff were fair game. For myself (and others like me), is 4.2 open for new features? If so, should we just continue to take it on ourselves to self-select those things _we think_ are more universal in nature? Should we try the shotgun approach (submit everything to 'Code Contributions' and see what gets picked up)? Is there a "proper place" to provide a list of changes we've made and give others the opportunity to speak for/against including them (or give a 'vTiger Linus' the opportunity to accept/reject them)? I think once I have a clear idea of how best to contribute, particularly to 4.2, I'll be more able to do so effectively. By the way, I think Matt's v5 architecture ideas are great, but they do muddy the waters for me a bit. Seeing those ideas, I have hope that something along those lines may be implemented, but it also makes me question *when* the right time will be to port some of my changes and additions to v5...I'd rather just do it once. peace, nokes On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > Hi! > This is a call to all the 4.x private development owners. > > Many of you would have been working on your own version of vtiger as you would have > customized it to your own needs. This is a call for those guys. > > The intent is to aggregate most of the common features that you have built and have them > integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch > or even in the 5.x branch as needed by the community. > > Pros: > > By doing the above, you will be able to be in sync with the latest and greatest developments > happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a > read as one would think of but we are working on it. Yesterday we had comments about the > code not being properly commented, we are working on that right now even as I type this post. > So, the idea I am conveying is that we are not perfect but are listening to the comments and > taking actions too. Hence, please do keep the faith. > > Cons: > > By maintaining your own code bases, you lose out on the community benefits like > identifying bugs, feature integration, new ideas, etc. > > We welcome your contributions. > > Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise > the folly. Let us get on with it and make vtiger a success. > I have learnt from my past mistakes. Join the team, come on board. > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Fri Jul 14 12:37:08 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Fri, 14 Jul 2006 15:37:08 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> > Really what I am trying to accomplish is to make your life easier in the > long run than what it currently is, even when diverging from the > standard way of doing it with-in vtiger. There is a learning curve that > will come along with this but correct documentation and developer > support via this mailing list should help you get past any of that. Except that you're killing me with your good intentions. The life of an integrator doesn't permit steep learning curves and heavy abstractions; there just isn't time to do so. I've got a dozen different systems to get to play together, a boss screaming at me to get this stuff done yesterday, and no time to devote to learning whatever abstraction layer you've decided to implement. And Murphy's Law being what it is, if your abstraction model has one flaw, that will be the thing that my boss wants as his top priority. "Perfect is the enemy of good enough" I don't want "perfect"; I want "good enough" I want to be able to dive into the source and start modifying how the thing works *right now* without having to trace back a billion functions or wrap my brain around your object model. I don't have time to do so, because I'm simultaneously trying to play with a dozen other pieces of the puzzle. Guys, I have been playing this game for a LONG time. I have written major applications to perform mission-critical business functions.(At one time, if my code broke DaimlerChrysler stopped building cars) I have seen and dealt with thousands of software projects, both as a participant and as an observer, and almost without fail, every time somebody sets out to do the "perfect" object-based, extensible, customizable framework, it just leads to tears. I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. If you write code that any decent developer can pick up, find his bearings in a couple of seconds, and then comprehend *without* the benefit of having read the thousand-page project definition in advance, then you are doing well. The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator - because if your code is so illegible (or so heavily abstracted, or has such a steep learning curve, or whatever) that I cannot figure it out on my own in a few minutes and so have to drop everything until I can get some assistance... well then, you've burned up my precious, precious time. That code might be sheer genius. It might be, once you have tackled the learning curve, breathtakingly beautiful. But if I can't just fire up vi and dive in, then it is WRONG. Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. The big problem with the current state of Vtiger 4.x is that it straddles both worlds. There are parts of the code that are fairly straightforward and out in plain sight, and only lack comments to make them "good enough". Then there are parts that want to be object-oriented with an API, but really depend on a couple of heavily-overloaded megafunctions buried deep in the depths of util.php (also uncommented) so you have to play API detective to figure out just what the hell is happening where. And then there's parts of the code that mix both. It'd be SO much easier to maintain if all the code that related to a module (less some *basic* toolkit functions that could reside in a common include) just lived in that module. Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility. DG From dan.means at teamsrs.com Fri Jul 14 13:25:56 2006 From: dan.means at teamsrs.com (Dan Means) Date: Fri, 14 Jul 2006 13:25:56 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <44B7FDD4.4080009@teamsrs.com> I couldn't have said this better than Dennis.... -- Dan Means Mission Viejo, CA www.dkmeansonline.com www.teamsrs.com From crm at email.si Fri Jul 14 14:34:37 2006 From: crm at email.si (Ales Petric) Date: Fri, 14 Jul 2006 22:34:37 +0100 Subject: [Vtigercrm-developers] What's with 4.2.x future ? Message-ID: <44B80DED.4010808@email.si> HI EVERYONE This is my first post to 'vTiger' developers mailing list About me: My native environment is development environment (around C/C++, VB, HTML, CSS, PHP, ASP, Python). My home system environment is 'Linux' based desktop os. like 'Debian' and 'Debian' based (my latest is 'Ubuntu') For my business server system I use 'Debian' stable. Like all I had to do some system tunning and other stuff related for system to work properly and live. I worked for small and big companies, within groups and on solo projects. My favorite project is project that is more to an end oriented that other. I had worked on lost project to but I had learned something from that, hope you to. Project called 'vTIger': Yes, 'vTiger' :), I am working with this great free source project for some time now (let me think back, 1 year and 6 month it is, sounds like my birthday :) Reason is that I am involved with business that uses 'CRM' software and solution for them 'vTiger' was the answer, from me to them :) Yes, it sells good if support is guaranteed and signed in contract (like must be included); Yes what's new :) What is new? That was my question looking 'vTiger' community. Let's get serious. In my business we had implemented over 150 issues, or tickets related, not features. We have less then 10 serious stuff implemented, tested and deployed. I believe, and some of you will confirm that this is big step back for community when stuff is included in 'vTiger' and not updated on live track inside community. As we now, there are many companys that offers hosting with 'vTiger' CRM, and many are just keeping one eye on 4.2.x. I belive that 'vTiger' is under 'GPL' and much more, there is community above that is responsible for maintaining the project. Community: Let's face it. There should be readable state and mission, end oriented leadership, free participation, known business model of 'vTiger CRM', useful documents on-line, tutorials, subgroups with a roles like module manager, testers, and many more beautiful stuff, ..I yes there is many but not enough. I have read that someone was begging not for himself for some other guy that they should give him some type of account that he can post code 'not(anonymous)' Question is. Can community afford that kind of behaviour, that no actions are taken. Many are complaining about non activity that is going on right now. Proposal: Let's build team of project/module managers and sys-admin guys to do some steeps needed to put out htp://new.vtiger.com/ based on latest release of 4.2.x thread. On the same portal if it is possible ? Within the same community if it is possible ? We can invite all existing groups that are using 4.2.x thread and join forces and merge existing sources and fixed issues. We need that, and more we need all help we can get within testing activities that are needed when new release comes out. With future plans of what's included in first build and what in next. Yes we can plan what features and build them in future within subgroups of module managers responsible to finish what was started. 4.2.x future to be when 4.3 and then 5.0, isn't that the way ? If there is comment, I now there is, and I now there is the way we can bring action into 'vTiger' community. What do ya say? Respect, Ales Petric From carylt at gmail.com Fri Jul 14 14:47:03 2006 From: carylt at gmail.com (Caryl Takvorian) Date: Fri, 14 Jul 2006 22:47:03 +0100 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <8075d1e0607141447y1b5a878at5321bb42dafcd01b@mail.gmail.com> Just for the sake of it, let me say that I whole heartedly agree with Dennis. I'm not unfortunately convinced that his (our) opinion will change anything, but I find the arguments truthfully compelling. Caryl On 7/14/06, Dennis Grant wrote: > > > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060714/02f2875a/attachment-0005.html From mmbrich at fosslabs.com Fri Jul 14 15:29:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Fri, 14 Jul 2006 16:29:30 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture moving forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090A@exch.accuratetechnologies.com> Message-ID: <1152916171.16985.800.camel@localhost.localdomain> OK, so I am going to highlight and comment on some of my favorite quotes from DG so far, this way when I start ignoring his emails you will all understand why. 1) It is a whole lot easier to deal with each module having its own code, even if that code is 95% common with other modules. This has to be hands-down the stupidest thing I have ever heard in my life and I can't believe that anyone who claims the experience you do actually posts this drivel on a public mailing list. 2) I am utterly convinced that the way to success is to write code that is optimised for human legibility and comprehension. I am utterly convinced that anyone who argues that 95% code similarities in vtiger modules is a "good enough" method is utterly stupid. 3) The second I have to go to a developer list to get assistance you, as a developer, have FAILED ME as an integrator ... well then, you've burned up my precious, precious time So your 'job' as an OSS systems integrator has never included needing to RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing question on a mailing list? 4) That code might be sheer genius. But if I can't just fire up vi and dive in, then it is WRONG. I'm starting to see the picture now.. you're lazy, and rather than do something about the current problems in the system you are going to whine about it. Sergio was right, my apologies Sergio. 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink it, and you'll wind up with something that only YOU understand... and I'm back with my privately-maintained fork. I think I've made it clear that simple, concise and logical are all design goals of the system. And you sir have made it clear that you have no intention of helping move this project forward by displaying your willingness to fork instead of work with a _real_ design structure that a _real_ OSS systems integrator would be very happy to have. Matt On Fri, 2006-07-14 at 15:37 -0400, Dennis Grant wrote: > > Really what I am trying to accomplish is to make your life easier in > the > > long run than what it currently is, even when diverging from the > > standard way of doing it with-in vtiger. There is a learning curve > that > > will come along with this but correct documentation and developer > > support via this mailing list should help you get past any of that. > > Except that you're killing me with your good intentions. > > The life of an integrator doesn't permit steep learning curves and heavy > abstractions; there just isn't time to do so. I've got a dozen different > systems to get to play together, a boss screaming at me to get this > stuff done yesterday, and no time to devote to learning whatever > abstraction layer you've decided to implement. > > And Murphy's Law being what it is, if your abstraction model has one > flaw, that will be the thing that my boss wants as his top priority. > > "Perfect is the enemy of good enough" I don't want "perfect"; I want > "good enough" I want to be able to dive into the source and start > modifying how the thing works *right now* without having to trace back a > billion functions or wrap my brain around your object model. I don't > have time to do so, because I'm simultaneously trying to play with a > dozen other pieces of the puzzle. > > Guys, I have been playing this game for a LONG time. I have written > major applications to perform mission-critical business functions.(At > one time, if my code broke DaimlerChrysler stopped building cars) I have > seen and dealt with thousands of software projects, both as a > participant and as an observer, and almost without fail, every time > somebody sets out to do the "perfect" object-based, extensible, > customizable framework, it just leads to tears. > > I am utterly convinced that the way to success is to write code that is > optimised for human legibility and comprehension. If you write code that > any decent developer can pick up, find his bearings in a couple of > seconds, and then comprehend *without* the benefit of having read the > thousand-page project definition in advance, then you are doing well. > > The second I have to go to a developer list to get assistance you, as a > developer, have FAILED ME as an integrator - because if your code is so > illegible (or so heavily abstracted, or has such a steep learning curve, > or whatever) that I cannot figure it out on my own in a few minutes and > so have to drop everything until I can get some assistance... well then, > you've burned up my precious, precious time. > > That code might be sheer genius. It might be, once you have tackled the > learning curve, breathtakingly beautiful. But if I can't just fire up vi > and dive in, then it is WRONG. > > Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink > it, and you'll wind up with something that only YOU understand... and > I'm back with my privately-maintained fork. > > The big problem with the current state of Vtiger 4.x is that it > straddles both worlds. There are parts of the code that are fairly > straightforward and out in plain sight, and only lack comments to make > them "good enough". Then there are parts that want to be object-oriented > with an API, but really depend on a couple of heavily-overloaded > megafunctions buried deep in the depths of util.php (also uncommented) > so you have to play API detective to figure out just what the hell is > happening where. And then there's parts of the code that mix both. > > It'd be SO much easier to maintain if all the code that related to a > module (less some *basic* toolkit functions that could reside in a > common include) just lived in that module. > > Please please PLEASE, for the love of GOD, don't go down the path of > objectifying everything and abstracting the code to the point of > incomprehensibility. > > DG > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From brian at awnow.com Fri Jul 14 18:48:13 2006 From: brian at awnow.com (Brian Laughlin) Date: Fri, 14 Jul 2006 18:48:13 -0700 Subject: [Vtigercrm-developers] Poorly written code is poorly written code. Message-ID: <27CABE0A5EFD714EA5B2F9B47EE5CB855BCFA2@svawmc1.awnow.local> 'Please please PLEASE, for the love of GOD, don't go down the path of objectifying everything and abstracting the code to the point of incomprehensibility.' This is not really a fair statement. OO code done well is a gem. The statement above automatically implies that it will be written poorly. OO code, procedure code or a sql query written badly is poorly written code - period. No method can overcome poor coding. It seems reasonable that v5 is about the future, one that creates better code base that is more reusable and it encourages more development talent to improve, iterate and integrate. With some effort I think we can mature this process so that the core product can continue to benefit from the community's contributions. There seems to be a simple fix to the debate that is ensuing. If you want to keep it as it is then support the 4.2.x branch, otherwise help to mature the code for v5. One last comment. There is a large class of developers that don't really care how the code was written or how it works as long as it works and works well. If you can extend its functionality or easily call it when you need it then for the most part they are happy. That doesn't stop those that want to dig deeper and tweak it at that level. More power to you. Regards, Brian Laughlin From mmbrich at fosslabs.com Sun Jul 16 20:31:30 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 21:31:30 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight Message-ID: <1153107090.5582.9.camel@localhost.localdomain> I wasn't able to get all the upgrades done last night, expect some more spotty access tonight as I try to finish up the list of to-dos Matt From mmbrich at fosslabs.com Sun Jul 16 21:31:29 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Sun, 16 Jul 2006 22:31:29 -0600 Subject: [Vtigercrm-developers] more vtiger.fosslabs.com work tonight In-Reply-To: <1153107090.5582.9.camel@localhost.localdomain> References: <1153107090.5582.9.camel@localhost.localdomain> Message-ID: <1153110689.5582.17.camel@localhost.localdomain> Upgraded SVN to 1.2.3 from backports.org. Let me know if you have problems with it. There is a backup of both the forge repo and the main repo from just before the upgrade. Matt On Sun, 2006-07-16 at 21:31 -0600, Matthew Brichacek wrote: > I wasn't able to get all the upgrades done last night, expect some more > spotty access tonight as I try to finish up the list of to-dos > > Matt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Mon Jul 17 02:18:50 2006 From: crm at email.si (Ales Petric) Date: Mon, 17 Jul 2006 10:18:50 +0100 Subject: [Vtigercrm-developers] Calling all private 4.x development owners In-Reply-To: <1152899095.32568.49.camel@rockcrusher> References: <10c677e83b8.-4140929648677257173.1990165057639984222@@vtiger.com> <1152899095.32568.49.camel@rockcrusher> Message-ID: <44BB55FA.4050909@email.si> Ok As private developer owner of 4.2.x I would like to be involved 'actively' in planning, maintaining and updating the 4.2.x. With what can I contribute: 1- I can bug fix (ticket solve) 2- I can suggest & plan with others what's to be in next release (4.2.X) and help with coding to achieve that 3- I can define groups for managing individual modules (maintainers) that will togather with other involved in 4.2.x deceide what's needed to build as add-on 4- I can do the functional analyse of current 4.2.x and publish .pdf, like system & user help (for developers and others related) 5- I can built three of functionality, like dir structure (for UseCase, TestCase and other related) 6- I can define which ticket/issue goes with X module or X functionality (for quick issue solving and other related) 7- I can help sync with other anonymous/private developers what was solved/debugged and help to merge existing code into next to be released 8 .. and many other stuff that I had have already done and not published...I can decode that for other users... What do I need: 1- Account with permissions to do something, I don't want to be anonymous updater. Now it's 8 vs 1 :( I it would be great to be involved with when to release and what's included in next 4.2.x. Ales Nolan Andres wrote: > As one of the mentioned 4.2 developers mostly lurking on this list... > > Like others have mentioned, I've got 2 classes of modifications: > > 1. those _I think_ others may be interested in > 2. those _I think_ others will not be interested in > > What I want to know is...is what _I think_ in any way connected with > reality? > > More to the point... > > How do I know whether or not I *should* submit a given patch to the > current tree for 4.2.5? In my previous (though admittedly minimal) > exploration, I got the sense that 4.2.x was essentially "feature frozen" > and that bug/security fixes and deployment/installation/maintenance > stuff were fair game. > > For myself (and others like me), is 4.2 open for new features? If so, > should we just continue to take it on ourselves to self-select those > things _we think_ are more universal in nature? Should we try the > shotgun approach (submit everything to 'Code Contributions' and see what > gets picked up)? Is there a "proper place" to provide a list of changes > we've made and give others the opportunity to speak for/against > including them (or give a 'vTiger Linus' the opportunity to > accept/reject them)? > > I think once I have a clear idea of how best to contribute, particularly > to 4.2, I'll be more able to do so effectively. > > By the way, I think Matt's v5 architecture ideas are great, but they do > muddy the waters for me a bit. Seeing those ideas, I have hope that > something along those lines may be implemented, but it also makes me > question *when* the right time will be to port some of my changes and > additions to v5...I'd rather just do it once. > > peace, > nokes > > > > On Thu, 2006-07-13 at 03:46 -0700, Richie wrote: > >> Hi! >> This is a call to all the 4.x private development owners. >> >> Many of you would have been working on your own version of vtiger as you would have >> customized it to your own needs. This is a call for those guys. >> >> The intent is to aggregate most of the common features that you have built and have them >> integrated into the vtiger core codebase. The integration might happen in the 4.2.x branch >> or even in the 5.x branch as needed by the community. >> >> Pros: >> >> By doing the above, you will be able to be in sync with the latest and greatest developments >> happening on vtiger. I understand that the current vtigercrm-5.x code base is not that easy a >> read as one would think of but we are working on it. Yesterday we had comments about the >> code not being properly commented, we are working on that right now even as I type this post. >> So, the idea I am conveying is that we are not perfect but are listening to the comments and >> taking actions too. Hence, please do keep the faith. >> >> Cons: >> >> By maintaining your own code bases, you lose out on the community benefits like >> identifying bugs, feature integration, new ideas, etc. >> >> We welcome your contributions. >> >> Yes, there was a time in the past when I was decidedly introvert and the project suffered. I realise >> the folly. Let us get on with it and make vtiger a success. >> I have learnt from my past mistakes. Join the team, come on board. >> >> Richie >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > __________ NOD32 1.1661 (20060714) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f0af863c/attachment-0003.html From sergiokessler at gmail.com Mon Jul 17 06:36:39 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 10:36:39 -0300 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> Message-ID: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak From dgrant at accuratetechnologies.com Mon Jul 17 06:51:45 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Mon, 17 Jul 2006 09:51:45 -0400 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG From richie at vtiger.com Mon Jul 17 07:48:07 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:48:07 -0700 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> Message-ID: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Hi Team! Let us take a step back and review what is happening. As the case stands, the intent is to provide an ideal vtiger architecture which needs almost everyones needs. It is plain that as of now, there are only 2 "strong/loud" arguments. I am sure you all will agree that both of them are not overly subscribed by any majority yet. Let us get some more ideas- however radical they be- into this list and then we will vote the good ideas in. By being too strongly worded on any particular idea, it will only stop short the other guys to put forth their ideas however miniscule/insignificant that might appear to be. I have myself faced this situations many times and I wish that the same does not happen here. Let us target 2 weeks from today as the time within which we should get all the ideas in. We can always short list as we have quite some experienced hands on board. vtigercrm-5.0.0 will be out within that time. Good to see some emotion here but I am sure we will hold to the rules of basic etiquettes and only wrt the point in concern. Thank You, Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- > OK, so I am going to highlight and comment on some of my favorite quotes > from DG so far, this way when I start ignoring his emails you will all > understand why. This is entirely the wrong attitude. You asked for my opinion, and I told you. It's not MY fault if I don't agree with you. You don't live in an ivory tower where you get to make proclamations from on high and all the peons get to live with your decisions; you are part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE. That means you have to listen to the people who are actually using your code in production environments, who have experience with these environments, and who deal with the consequences of your decisions on a daily basis. Something you are going to find out is that people downstream from you are going to do things with your code that will continually surprise and shock you. "I NEVER intended THAT!" is a fact of life for a developer. Here's a reality check for you - you do not have a monopoly on brains. "Your way" is almost certainly not the optimal way to deal with any particular problem. And the other side of that coin is that MY way, or Sergio's way, or anybody else's way is not going to be optimal EITHER. Project design is a series of tradeoffs and compromises working toward a common goal. You had better learn this in a hurry, or you will find yourself marginalized in a hurry. Free Software projects have a way of seeing ivory-tower developers as damage and routing around them. You do not have the option of taking your ball and going home. LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it is I am telling you the things that I am telling you. I am maintaining a fork of Vtiger that is running an actual live business; I am not pulling this stuff out of my ass. >> 1) It is a whole lot easier to deal with each module having its own >> code, even if that code is 95% common with other modules. > This has to be hands-down the stupidest thing I have ever heard in my > life and I can't believe that anyone who claims the experience you do > actually posts this drivel on a public mailing list. So in other words, you don't understand. Fine, I'll explain it to you again: My job, and the job of any integrator, is getting systems to talk to each other to work, from the outside, as a unified whole, as quickly as humanly possible. Non-IT bosses have little to no understanding of the complexity of systems integration and they have no patience with delay. For example, my boss wants the generation of a Quote in VTiger to call Microsoft Great Plains (for better or worse, the back-end business software I have to deal with) and pre-order all the component parts that make up the assemblies that are being quoted in the Quote. Then he wants the promotion of the Quote to a Sales Order to trigger a manufacturing order in GP so the parts get built. Then he wants the generation of an Invoice in Great Plains to create an Invoice in Vtiger - and he wants this to all happen with minimal to no human data entry. Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger and GP to be the same. And he wants it done in two weeks. And this is typical of the sort of thing I have to deal with. I've already written a query and display engine into our Software Licensing System, and I wrote (from scratch) a company Org Chart application that displays the relationships between Accounts in the CRM, and between Contacts within an Account (both currently implemented as standalone web services, but I've been told he wants them displayed as CRM tabs) I flat out do not have the luxury of the time required to study and learn new APIs all the time. It is bad enough that I have to deal with Microsoft doing this to me; I sure the HELL don't want vTiger doing this to me. Plus, if the API isn't flexible enough to do what I am REQUIRED to make it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to NOT use the API - which is wasteful of my time and your time, and severs the tie between vanilla Vtiger and my private fork, which is bad for BOTH of us (as we no longer get the benefits of each other's bug fixes) Plus... like I've said, I've been at this a long time. I have seen hundreds of projects waste millions of dollars trying to define the "perfect" API and object model, only to have it blow up in their face - usually because making the object model "perfect" took three times longer than anticipated, and then when they first present it to the user, the user goes "but that's not what I wanted" and (Murphy being Murphy) their object model is utterly incompatible with what the user wanted. I have seen exactly ONE object-oriented project succeed - the Chrysler employee pay system was written in Smalltalk, and it was BRILLIANT. It also had the benefit of a very tightly integrated development team, and a team lead who had the object religion in a big way and converted his team to it utterly. Part of his design process was that you were not allowed to code a single byte until you had defined the entire object (data and methods) on paper, it had passed his review, and then passed an open team review. It took around two months of paperwork and design review before you were allowed to write actual code. I was amazed at their discipline, and the project as a whole really impressed me - but they also had the advantage that (for legal reasons) their system had to be 100% standalone and was not allowed to interface with any other systems. You needed special access just to get into their portion of the building; it was walled off from everybody else. This project is 180 degrees off from that, and there is simply no way that sort of design methodology could work in this situation. >> 2) I am utterly convinced that the way to success is to write code that >> is optimised for human legibility and comprehension. > I am utterly convinced that anyone who argues that 95% code similarities > in vtiger modules is a "good enough" method is utterly stupid. You don't understand WHY, obviously, I would say this. The utter worst case scenario for an integrator is changing code in Module A and then functionality changes in Module B. I'm pounding away on Sales Orders, and suddenly, Quotes stop working - or (as happened recently) I start working on the Email module, and suddenly all our users are being emailed copies of our Helpdesk Tickets. Holy hell! Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly argue against that? Now, the simplest way to achieve that is to have separate copies of common code in each module - right? Now you may well argue that having separate copies of common code in each module makes maintaining common code a SERIOUS pain in the ass - and I agree wholeheartedly. The trick is separating out REAL common code from "code that is common by convenience" I am not opposed to REAL common code being placed into functions. What I AM opposed to are functions that exist like some of the ones in utils.php where you pass the function a UItype (which is a meaningless number) and then you get this huge cascading IF statement like this: If ($uitype == 63) { If ($module == 'CONTACTS' || $module == 'HELPDESK'') { Do this(); } Else { Do that(); } } That is NOT common code. Do you see this? DO you understand? Do you have ANY idea how much time has been wasted tracking down stuff like this? >> 3) The second I have to go to a developer list to get assistance you, as >> a developer, have FAILED ME as an integrator ... well then, you've >> burned up my precious, precious time > So your 'job' as an OSS systems integrator has never included needing to > RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing > question on a mailing list? All the time. But OSS documentation, typically (and in Vtiger, EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms of quality of response, timeliness, and applicability. I cannot afford to be dead in the water waiting on a response from a mailing list; there's just too much damn work to do to be held up waiting on someone who may or may not respond. And let's be honest here, up to this point, the Vtiger team has been singularly unresponsive - perhaps that will improve, but as of right now, if I had to wait in the dev team to answer my questions, I would never have gotten anything done. Good code is self-documenting. If I can't figure out what the code is doing by reading the code, the developer has failed, no matter how functional the code might be. >> 4) That code might be sheer genius. But if I can't just fire up vi >> and dive in, then it is WRONG. > I'm starting to see the picture now.. you're lazy, and rather than do > something about the current problems in the system you are going to > whine about it. Sergio was right, my apologies Sergio. Right, I'm so lazy that I'm investing hours of my time trying to educate you as to WHY I feel the way I do, in the hope that I won't be forced to re-invent the wheel or fork the bloody project. I'm not "whining", I am TEACHING. >> 5) Do you see what I'm getting at? Keep it SIMPLE and you win. Overthink >> it, and you'll wind up with something that only YOU understand... and >> I'm back with my privately-maintained fork. > I think I've made it clear that simple, concise and logical are all > design goals of the system. But you have done no such thing, because you are rejecting my trenchant and entirely valid points out of hand because they contradict your personal world view. > And you sir have made it clear that you > have no intention of helping move this project forward by displaying > your willingness to fork instead of work with a _real_ design structure > that a _real_ OSS systems integrator would be very happy to have. 1) I most certainly do NOT want to fork. I am trying, with all my might, to AVOID a fork. Forking hurts EVERYONE. But if you implement some ivory-tower API and object model such that it is LESS painful to fork than it is to deal with your model, then you will have FORCED me to fork. 2) I AM a real OSS integrator. I am telling you what it is like out in the real world. Put your ego aside for a while and LISTEN. DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9af843db/attachment-0005.html From richie at vtiger.com Mon Jul 17 07:57:28 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 07:57:28 -0700 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> References: <49216030607130840k6b2f7d9aq5c1ce336f74e9ec3@mail.gmail.com> <49216030607170636o73d5f5d2n7aa9bcc6ae227c0d@mail.gmail.com> Message-ID: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/d71cb2dd/attachment-0003.html From richie at vtiger.com Mon Jul 17 08:43:10 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 08:43:10 -0700 Subject: [Vtigercrm-developers] automated tests update Message-ID: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/f783fc2f/attachment-0005.html From richie at vtiger.com Mon Jul 17 09:01:27 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:01:27 -0700 Subject: [Vtigercrm-developers] have a go at the demo Message-ID: <10c7d3878ee.-2525705299028808692.-7798707862789036512@@vtiger.com> Dear Team, Kindly have a go at the demo so that we can identify the bugs and fix them. We are planning to freeze taking up any new bug-fixing post this week. Needless to say, if there be any pressing bugs, we will have to re-consider else we stick to this plan. We would like to take into consideration all the bugs that we get by this week alone. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/05c6f7c8/attachment-0003.html From richie at vtiger.com Mon Jul 17 09:04:40 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:04:40 -0700 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 Message-ID: <10c7d3b68c9.-1733958150241885349.-2381377074013605034@@vtiger.com> Ken asked me a question in my blogs about how we can have a better documentation for v5. I honestly do not know if any setup is available which can help us achieve the same other than that of a wiki. Any new ideas are welcome. It will be nice to have a distributed effort on for the documentation as well. Let us get some working backbone for collaborative documentation up and running fast. Any ideas/suggestions? Any experienced documentor on board, please raise hands! Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/effef8f7/attachment-0005.html From richie at vtiger.com Mon Jul 17 09:24:59 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:24:59 -0700 Subject: [Vtigercrm-developers] Help Needed Feature Message-ID: <10c7d4e0030.-6478902657238423422.8728970723888816495@@vtiger.com> Is there any Help Needed feature available in the forge? Ken asked me this and I could not answer the query. Please find the link to the blog post for contextual reference: http://blogs.vtiger.com/weblog_entry.php?p=28125#28125 I think what Ken is referring is to have a more vertically-distributed setup something like Help Needed in Leads Module Bug-fixing Help Needed in Leads Module Docs Help Needed in Leads Module Automation of test cases etc. Matt/Fathi, can we have this for all the projects in the forge please or does it already exist? I just checked the forge and did not find any links. Am I missing something? Probably, we can have a link to the vtigercrm-5.0.0 live source in the vtigerforge too. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/1c9b7dca/attachment-0003.html From richie at vtiger.com Mon Jul 17 09:31:34 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:31:34 -0700 Subject: [Vtigercrm-developers] automated trac registration Message-ID: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9e1e63d7/attachment-0005.html From richie at vtiger.com Mon Jul 17 09:34:57 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:34:57 -0700 Subject: [Vtigercrm-developers] Fwd: error Message-ID: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> ----j.ruisz at ruisz.com wrote ---- ============Forwarded Mail============ >From : j.ruisz at ruisz.com To : richie at vtiger.com Date :Fri, 14 Jul 2006 08:11:36 +0200 Subject : error ============Forwarded Mail============ Hello , trying to test the online demo of vtiger 5 i got this result: *Fatal error*: Call to a member function on a non-object in */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* on line *431* with best regards, mit freundlichen Gr??en, Joachim Ruisz Werbegrafik, Bildagentur, Webagentur Softwareentwicklung Joachim Ruisz A 8940 Liezen +43 664 312 4830 j.ruisz at ruisz.com http://www.ruisz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/332ceeeb/attachment-0003.html From richie at vtiger.com Mon Jul 17 09:35:17 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 09:35:17 -0700 Subject: [Vtigercrm-developers] Fwd: Translations Message-ID: <10c7d576ed5.6497289794643483356.-5939067564803299625@@vtiger.com> ----webmaster at vtigerfacile.com wrote ---- ============Forwarded Mail============ >From : webmaster at vtigerfacile.com To : richie at vtiger.com Date :Mon, 17 Jul 2006 02:31:42 +0200 Subject : Translations ============Forwarded Mail============ Vanakkam Shankar, i have made a little test for translation. I have added few line in app_strings file. And like for module customview, all dropdown in all editviews (Call/Meeting inclued) are translated. If we can have the same things in listview & detailview, the translation will be perfect, and vtiger 5 can be used in multilang without problem. I want to mention the value of select box is keep in english () Best regards, A?ssa Find the added strings in /include/languages/fr_fr.lang.php below //activities 'Planned'=>'Plannifi?', 'Held'=>'A eu lieu', 'Not Held'=>'N\'a pas eu lieu', 'Medium'=>'Normale', 'Private'=>'Priv?', 'Public'=>'Public', 'Daily'=>'Quotidienne', 'Weekly'=>'Hebdomadaire', 'Monthly'=>'Mensuelle', 'Yearly'=>'Annuelle', 'Completed'=>'Termin?', 'Deferred'=>'Report?', //Campaigns 'Excellent'=>'Excellent', 'Good'=>'Bonne', 'Average'=>'Moyenne', 'Poor'=>'Faible', 'Conference'=>'Conf?rence', 'Webinar'=>'S?minaire', 'Trade Show'=>'Salon', 'Public Relations'=>'Relations Publique', 'Partners'=>'Partenaires', 'Referral Program'=>'Programme', 'Advertisement'=>'Publicit?', 'Banner Ads'=>'Banni?re web', 'Direct Mail'=>'Email direct', 'Email'=>'Email', 'Telemarketing'=>'T?l?marketing', 'Others'=>'Autre', 'Planning'=>'Plannifi?', 'Complete'=>'Termin?', 'Cancelled'=>'Annul?', //Accounts //Industry list 'Apparel'=>'Appareillage', 'Banking'=>'Banque', 'Biotechnology'=>'Biotechnologie', 'Chemicals'=>'Industrie chimique', 'Communications'=>'Communications', 'Construction'=>'BTP', 'Consulting'=>'Conseil', 'Education'=>'Education', 'Electronics'=>'Electronique', 'Energy'=>'Energie', 'Engineering'=>'Engineering', 'Entertainment'=>'Divertissement', 'Environmental'=>'Environnement', 'Finance'=>'Finance', 'Food & Beverage'=>'Agro alimentaire', 'Government'=>'Secteur public', 'Healthcare'=>'Sant?', 'Hospitality'=>'Hopitaux', 'Insurance'=>'Assurances', 'Machinery'=>'', 'Manufacturing'=>'Manufacture', 'Media'=>'M?dia', 'Not For Profit'=>'But non lucratif', 'Recreation'=>'Amusement', 'Retail'=>'D?taillant', 'Shipping'=>'Livreur', 'Technology'=>'Technologie', 'Telecommunications'=>'T?l?communications', 'Transportation'=>'Voyage', 'Utilities'=>'D\'utilit? publique', 'Other'=>'Autre', //accounts type 'Analyst'=>'Analyste', 'Competitor'=>'Concurrent', 'Customer'=>'Client', 'Integrator'=>'Int?grateur', 'Investor'=>'Investisseur', 'Partner'=>'Partenaire', 'Press'=>'Presse', 'Prospect'=>'Prospect', 'Reseller'=>'Revendeur', 'Other'=>'Autre', 'Existing Business'=>'Client existant', 'New Business'=>'Nouveau client', 'Cold Call'=>'Appel direct', 'Existing Customer'=>'Client existant', 'Self Generated'=>'Auto g?n?r?', 'Employee'=>'Employ?', 'Partner'=>'Partenaire', 'Public Relations'=>'Relation publique', 'Direct Mail'=>'Email direct', 'Conference'=>'Conf?rence', 'Trade Show'=>'Salon', 'Web Site'=>'Site web', 'Word of mouth'=>'Bouche ? oreille', 'Other'=>'Autre', 'Prospecting'=>'Prospection', 'Qualification'=>'Qualification', 'Needs Analysis'=>'Requiert analyse', 'Value Proposition'=>'Proposition', 'Id. Decision Makers'=>'Attente d?cision', 'Perception Analysis'=>'Anallyse', 'Proposal/Price Quote'=>'Devis', 'Negotiation/Review'=>'N?gociation', 'Closed Won'=>'Clos gagn?', 'Closed Lost'=>'Clos perdu', 'Attempted to Contact'=>'Attente contact', 'Cold'=>'Froid', 'Contact in Future'=>'A recontacter', 'Contacted'=>'Contact?', 'Hot'=>'Chaud', 'Junk Lead'=>'Corbeille', 'Lost Lead'=>'Perdu', 'Not Contacted'=>'Non contact?', 'Pre Qualified'=>'Pr? qualifi?', 'Qualified'=>'Qualifi?', 'Warm'=>'Brulant', 'Acquired'=>'Acquis', 'Active'=>'Actif', 'Market Failed'=>'March? perdu', 'Project Cancelled'=>'Projet annul?', 'Shutdown'=>'Eteint', 'Open'=>'Ouvert', 'In Progress'=>'En cours', 'Wait For Response'=>'Attente de r?ponse', 'Closed'=>'Clos', 'General'=>'G?n?ral', 'Low'=>'Basse', 'Normal'=>'Normale', 'High'=>'Haute', 'Urgent'=>'Urgent', 'Minor'=>'Mineure', 'Major'=>'Majeur', 'Feature'=>'Fonctionnalit?', 'Critical'=>'Critique', 'Big Problem'=>'Gros probl?me', 'Small Problem'=>'Petit probl?me', 'Other Problem'=>'Autre probl?me', 'Hardware'=>'Mat?riel', 'Software'=>'Logiciel', 'CRM Applications'=>'Application CRM', 'Box'=>'Boite', 'Carton'=>'Carton', 'Dozen'=>'Douzaine', 'Each'=>'Pi?ce', 'Hours'=>'Heure', 'Impressions'=>'Impression', 'Lb'=>'Lb', 'M'=>'M', 'Pack'=>'Pack', 'Pages'=>'Pages', 'Pieces'=>'Pi?ces', 'Quantity'=>'Quantit?', 'Reams'=>'Rames', 'Sheet'=>'Pages', 'Spiral Binder'=>'Reliure', 'Sq Ft'=>'Sq Ft', 'Created'=>'Cr??', 'Delivered'=>'Livr?', 'Reviewed'=>'Corrig?', 'Accepted'=>'Accept?', 'Rejected'=>'Rejett?', 'Approved'=>'Approuv?', 'Sent'=>'Envoy?', 'Credit Invoice'=>'Avoir', 'Paid'=>'Sold?', 'Received Shipment'=>'Commande re?ue', 'Call'=>'Appel', 'Meeting'=>'Rendez-vous', 'Task'=>'T?che', '--None--'=>'Aucun', -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9ad522c6/attachment-0005.html From gopals at vtiger.com Mon Jul 17 10:58:01 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 10:58:01 -0700 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> Message-ID: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Hi, If there is automate option, it is better to notify user id and password to the correct email ids. I am already struggling with free forums and wiki registration process. People register with junk mail ids and spam our bug tracker as well. My be we can create a group mail id and alias to admin users, who can create trac users ids so that load is shared among developer community. Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hi! Team, is there any way we can have an automated trac registration? I can do the registrations till a point and the current mechanism is too crude. Jeff/Matt any ideas please? Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/c36beaeb/attachment-0003.html From mmbrich at fosslabs.com Mon Jul 17 11:18:22 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:18:22 -0600 Subject: [Vtigercrm-developers] Ideas for vtiger architecture going forward In-Reply-To: <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> References: <3E26E7A199CABA49822B3E6B741434F97D090B@exch.accuratetechnologies.com> <10c7cf553fd.3553495327061471870.6443730893616686361@@vtiger.com> Message-ID: <1153160302.5582.73.camel@localhost.localdomain> > It is plain that as of now, there are only 2 "strong/loud" arguments. > I am sure you all will agree that both of them are not overly > subscribed by any majority yet. Yes but there is only one idea on the table, and 1 set of criticisms followed by absolutely no suggestions on how to better the first idea. This was really my bitch about the first set of posts. > > Let us get some more ideas- however radical they be- into this list > and then we will vote the good ideas in. This is a great idea. I have been looking forward to someone else posting some ideas to get the ball rolling. I for one welcome radical ideas if anyone has any. > By being too strongly worded on any particular idea, it will only stop > short the other guys to put forth their ideas however > miniscule/insignificant that might appear to be. I certainly don't mean to scare off any developers that are going to actually bring some ideas to the table, quite the contrary. If someone has been playing around in 5.x and said to themselves "wouldn't it be easier if this was done like this..." then please tell us what you are thinking, even if it doesn't involve a full change to the architecture and only covers some small area of the code. > > I have myself faced this situations many times and I wish that the > same does not happen here. > > Let us target 2 weeks from today as the time within which we should > get all the ideas in. Lets not rush this, or pile on top of the workload that many vtiger devels are probably already experiencing. The only reason I brought my idea to the table this soon is because you and I had discussed this off list and I thought it needed to be in front of the community. > We can always short list as we have quite some experienced hands on > board. > vtigercrm-5.0.0 will be out within that time. But after 5.0.0 is out is when I think we'll start to see the most interesting ideas. Many devels may still be in 4.x and haven't had a chance yet to start playing with 5.x. Lets let them get their hands dirty in the new code first. > > Good to see some emotion here but I am sure we will hold to the rules > of basic etiquettes and only wrt the point in concern. I know I am a blunt person and sometimes that catches people off guard :), I rarely mean to come off as rude unless someone fully deserves it. Anyways, bring on the ideas for improving vtiger! Matt From mmbrich at fosslabs.com Mon Jul 17 11:22:49 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:22:49 -0600 Subject: [Vtigercrm-developers] automated trac registration In-Reply-To: <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> References: <10c7d540ddb.6508580131936356915.-1223415504297417796@@vtiger.com> <10c7da32fe6.-3880396566637354428.-6750441910797566885@@vtiger.com> Message-ID: <1153160569.5582.79.camel@localhost.localdomain> I can't think of a great way to do automated sign-up without using captcha or something similar, and we all know there are ways around those systems. I like your ideas of an admin list that people can request access from. And BTW, which interface are you guys using to give developers trac accounts? There is the trac module which was installed or there is the service page that I created to manage SVN and trac. The reason I ask is because the service page may be out of date now that we've upgraded trac a couple times since I wrote it. Matt On Mon, 2006-07-17 at 10:58 -0700, Gopal wrote: > Hi, > > If there is automate option, it is better to notify user id and > password to the correct email ids. I am already struggling with free > forums and wiki registration process. People register with junk mail > ids and spam our bug tracker as well. > > My be we can create a group mail id and alias to admin users, who can > create trac users ids so that load is shared among developer > community. > > Gopal > --- > S.S.G.Gopal > skype: sripadag > ph: +1 877 788 4437 > blog: http://gopal.vtiger.com > > > > > ----richie at vtiger.com wrote ---- > > > Hi! > Team, is there any way we can have an automated trac registration? I can do the registrations > till a point and the current mechanism is too crude. > > Jeff/Matt any ideas please? > > Richie _______________________________________________ > Get started with creating presentations online - > http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From mmbrich at fosslabs.com Mon Jul 17 11:24:20 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 12:24:20 -0600 Subject: [Vtigercrm-developers] Fwd: error In-Reply-To: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> References: <10c7d5721ba.-6206747396075354159.-2912525180112702001@@vtiger.com> Message-ID: <1153160660.5582.81.camel@localhost.localdomain> I'll upgrade the demo sometime this afternoon, I still haven't had a chance to sit down and write an automation system for this since. I plan to create something along the lines of Jeff's suggestion and automate it with post-commit hooks. Anyone who wants to help, just say the word. Matt On Mon, 2006-07-17 at 09:34 -0700, Richie wrote: > > > > > ----j.ruisz at ruisz.com wrote ---- > > ============Forwarded Mail============ > From : j.ruisz at ruisz.com > To : richie at vtiger.com > Date :Fri, 14 Jul 2006 08:11:36 +0200 > Subject : error > ============Forwarded Mail============ > > Hello , > > trying to test the online demo of vtiger 5 i got this result: > > *Fatal error*: Call to a member function on a non-object in > */home/site/html/products/crm/demo_5beta/include/database/PearDatabase.php* > on line *431* > > > > with best regards, > mit freundlichen Gr??en, > > Joachim Ruisz > > Werbegrafik, Bildagentur, Webagentur > Softwareentwicklung > > Joachim Ruisz > A 8940 Liezen > +43 664 312 4830 > j.ruisz at ruisz.com > http://www.ruisz.com > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From gopals at vtiger.com Mon Jul 17 11:37:05 2006 From: gopals at vtiger.com (Gopal) Date: Mon, 17 Jul 2006 11:37:05 -0700 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> References: <10c7d27b6b1.-5934338508341175893.-4923144839291770382@@vtiger.com> Message-ID: <10c7dc6f0c9.-5230172439552086929.-6694355083648319934@@vtiger.com> Hi Richie, I am aware of that currently we are using AdventNet QEngine for automating some of the test cases. But I am not clear, how can our external developer community use this tool in their local environment. Do you have any plans to get some more licenses for the sake of vtiger developer community? Thanks, Gopal --- S.S.G.Gopal skype: sripadag ph: +1 877 788 4437 blog: http://gopal.vtiger.com ----richie at vtiger.com wrote ---- Hello! Wanted to update on the automation front. We are working on getting a regression environment set up so that we can have all future tests run automated. We are 30% through with the task and plan to have almost 80% complete by the end of this week. The idea is to have these run in the night time so that by morning when we are in, the results are also in and we can do the fixes wherever needed. In due course of time, it will be nice if we have some volunteers who can take over this and run them and do the necessary fixes so that there is no dependency on any specific time-zone-based teams. Thanks, Richie _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/8b304edc/attachment-0005.html From jtk at yahoo.com Mon Jul 17 12:01:00 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 15:01:00 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: Gopal wrote: > I am aware of that currently we are using AdventNet QEngine for > automating some of the test cases. But I am not clear, how can our > external developer community use this tool in their local environment. > Do you have any plans to get some more licenses for the sake of vtiger > developer community? I'm glad to see regression tests on the agenda, but we don't need non-free tools to get this done. Selenium, which I've mentioned before, runs recorded tests in a browser, giving the most/only realistic test environment for javascript, etc. Selenium tests can be recorded by a firefox plugin, and the test source can be checked into subversion like any other source. This is what we should use, IMHO. http://openqa.org/selenium/ As far as running 'continuous integration testing'; some testing experts have used buildbot and vmware/vnc integration to continuously and automatically run unit and integration tests in a headless environment. http://www.google.com/search?q=buildbot+selenium http://agile.idyll.org/wiki/BuildBotTechnologyNarrative http://agile.idyll.org/buildbot/ All this testing technology uses free software. From mmbrich at fosslabs.com Mon Jul 17 14:25:52 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 15:25:52 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> Message-ID: <1153171552.5582.166.camel@localhost.localdomain> I haven't looked into Selenium yet but with JS does it work at the source level only, does it use gecko to actually execute and evaluate the JS or can it check for changes in the DOM like it does the source? In 5.x there are quite a few places where the DOM is being manipulated directly or indirectly and I don't think a source level verification tool will catch most of those. Maybe augmenting it with the scriptactulous unit test lib would work? http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Matt On Mon, 2006-07-17 at 15:01 -0400, Jeff Kowalczyk wrote: > Gopal wrote: > > I am aware of that currently we are using AdventNet QEngine for > > automating some of the test cases. But I am not clear, how can our > > external developer community use this tool in their local environment. > > Do you have any plans to get some more licenses for the sake of vtiger > > developer community? > > I'm glad to see regression tests on the agenda, but we don't need non-free > tools to get this done. > > Selenium, which I've mentioned before, runs recorded tests in a browser, > giving the most/only realistic test environment for javascript, etc. > > Selenium tests can be recorded by a firefox plugin, and the test source > can be checked into subversion like any other source. This is what we > should use, IMHO. > > http://openqa.org/selenium/ > > As far as running 'continuous integration testing'; some testing experts > have used buildbot and vmware/vnc integration to continuously and > automatically run unit and integration tests in a headless environment. > > http://www.google.com/search?q=buildbot+selenium > > http://agile.idyll.org/wiki/BuildBotTechnologyNarrative > > http://agile.idyll.org/buildbot/ > > All this testing technology uses free software. > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jtk at yahoo.com Mon Jul 17 15:53:33 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Mon, 17 Jul 2006 18:53:33 -0400 Subject: [Vtigercrm-developers] automated tests update References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: Matthew Brichacek wrote: > I haven't looked into Selenium yet but with JS does it work at the > source level only, does it use gecko to actually execute and evaluate > the JS or can it check for changes in the DOM like it does the source? > In 5.x there are quite a few places where the DOM is being manipulated > directly or indirectly and I don't think a source level verification > tool will catch most of those. Selenium directly drives the browser as if the user were clicking it. The demo http://www.openqa.org/selenium-core/demos.html illustrates the concept. > Maybe augmenting it with the scriptactulous unit test lib would work? > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting Unit tests in the client and server-side source would be enhancements, to be sure. However, I am skeptical about trying to retrofit unit test coverage to a large code base. The community would have a hard time achieving useful code coverage unless there were tests for *everything*, starting from early in the project. Selenium's end-result testing, and the fact that such tests can be recorded for submission by even novice users, would be an efficient use of limited community resources. If the testing fever strikes the community, perhaps all new code could be required to have unit tests, and so on. From sergiokessler at gmail.com Mon Jul 17 16:14:20 2006 From: sergiokessler at gmail.com (Sergio A. Kessler) Date: Mon, 17 Jul 2006 20:14:20 -0300 Subject: [Vtigercrm-developers] documentation for vtigercrm-5.0.0 In-Reply-To: <8091387652950704133@unknownmsgid> References: <8091387652950704133@unknownmsgid> Message-ID: <49216030607171614g2a47b5di900e13b06c4810f6@mail.gmail.com> richie, a wiki is the best aproach for this, don't worry... (of course, then you need people that do collaborate) /sak On 7/17/06, Richie wrote: > > Ken asked me a question in my blogs about how we can have > a better documentation for v5. > I honestly do not know if any setup is available which > can help us achieve the same other than > that of a wiki. > Any new ideas are welcome. > > It will be nice to have a distributed effort on for > the documentation as well. > Let us get some working backbone for > collaborative documentation up and running > fast. > > Any ideas/suggestions? > Any experienced documentor on board, please raise hands! > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > From mmbrich at fosslabs.com Mon Jul 17 17:13:46 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Mon, 17 Jul 2006 18:13:46 -0600 Subject: [Vtigercrm-developers] automated tests update In-Reply-To: References: <5747.13676837764$1153161476@news.gmane.org> <1153171552.5582.166.camel@localhost.localdomain> Message-ID: <1153181627.5582.194.camel@localhost.localdomain> On Mon, 2006-07-17 at 18:53 -0400, Jeff Kowalczyk wrote: > Matthew Brichacek wrote: > > I haven't looked into Selenium yet but with JS does it work at the > > source level only, does it use gecko to actually execute and evaluate > > the JS or can it check for changes in the DOM like it does the source? > > In 5.x there are quite a few places where the DOM is being manipulated > > directly or indirectly and I don't think a source level verification > > tool will catch most of those. > > Selenium directly drives the browser as if the user were clicking it. The > demo http://www.openqa.org/selenium-core/demos.html illustrates the > concept. I tried this out and did a little digging in the Core and IDE. From the looks of it, Selenium can handle a _lot_ of the javascript testing we would need, if not all of it. > > > Maybe augmenting it with the scriptactulous unit test lib would work? > > http://wiki.script.aculo.us/scriptaculous/show/UnitTesting > > Unit tests in the client and server-side source would be enhancements, to > be sure. However, I am skeptical about trying to retrofit unit test > coverage to a large code base. The community would have a hard time > achieving useful code coverage unless there were tests for *everything*, > starting from early in the project. > > Selenium's end-result testing, and the fact that such tests can be > recorded for submission by even novice users, would be an efficient use of > limited community resources. If the testing fever strikes the community, > perhaps all new code could be required to have unit tests, and so on. I had thought of this before too but my experience in requiring unit tests has not been good :). In the CGL project we tried to enforce a rule like this and it was shot down almost before it left the ground. In a PoC environment like that it's understandable but I think even in the case of vtiger the fever would have to be HOT to get everyone on board. Matt From richie at vtiger.com Mon Jul 17 22:40:42 2006 From: richie at vtiger.com (Richie) Date: Mon, 17 Jul 2006 22:40:42 -0700 Subject: [Vtigercrm-developers] XTemplate removed Message-ID: <10c80267f98.3578777089016548574.3997907602755987476@@vtiger.com> This is to inform that we have removed XTemplate dependency in vtigercrm5.0.0. XTemplate has been removed from the source as well. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060717/9fe2c2d6/attachment-0003.html From webmaster at vtigerfacile.com Tue Jul 18 02:18:43 2006 From: webmaster at vtigerfacile.com (=?ISO-8859-1?Q?A=EFssa?=) Date: Tue, 18 Jul 2006 11:18:43 +0200 Subject: [Vtigercrm-developers] Idea for future Message-ID: <44BCA773.9050506@vtigerfacile.com> Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa From richie at vtiger.com Tue Jul 18 03:20:36 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:20:36 -0700 Subject: [Vtigercrm-developers] need helping hands Message-ID: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> I am quoting Gopal's bug report. " As per discussion. I am testing product on the following setup: OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a-installer.exe php settings: error_reporting = E_ALL display_errors = On display_startup_errors = On log_errors = On After completion of installation 1.2 mb error log is generated in Apache error.log file. It is better to fix some of the notices and warnings, which will definitely improve the performance of the product. Thanks, Gopal " Need helping hands who can dig into this and give the fixes. We are held up with validation over here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/071764bc/attachment-0005.html From richie at vtiger.com Tue Jul 18 03:21:42 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 03:21:42 -0700 Subject: [Vtigercrm-developers] Idea for future In-Reply-To: <44BCA773.9050506@vtigerfacile.com> References: <44BCA773.9050506@vtigerfacile.com> Message-ID: <10c8127c4e2.-191772016694368201.-7661796100973677084@@vtiger.com> Hello! I do agree with that. I wanted it to be part of vtigercrm-5.0.0 but it was a feature so dropped it. It does not require too much effort actually. Will be taken up as part of 5.0.1 Richie ---- A?ssa<webmaster at vtigerfacile.com> wrote ---- Hi all, a friend as gived me an improvment idea for RSS. Actually channels RSS are alone in the system, with possibility to link channel RSS to an account or contact, the module became really valuable. I think this is a good idea. Regards, A?ssa _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/c3cec421/attachment-0003.html From richie at vtiger.com Tue Jul 18 05:13:08 2006 From: richie at vtiger.com (Richie) Date: Tue, 18 Jul 2006 05:13:08 -0700 Subject: [Vtigercrm-developers] need helping hands-2 Message-ID: <10c818dc9b0.-7967502206826138398.-2571256210646174921@@vtiger.com> We are getting quite some javascript issues in IE browsers. Any one out there game to test it in IE and help us by giving the fixes will be great. Please ensure that the fix does not break the Firefox/Mozilla support. Kindly post the fix in the trac and a blurb here. Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/a6b94bf0/attachment-0005.html From developer at infointegrated.com Tue Jul 18 05:33:39 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Tue, 18 Jul 2006 07:33:39 -0500 Subject: [Vtigercrm-developers] need helping hands In-Reply-To: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> References: <10c8126c4e6.983039410826105444.-3825873905166163433@@vtiger.com> Message-ID: <9160DA4D-DAAA-4C0D-B458-E401E03C5E49@infointegrated.com> Sounds like quite the challenge. I just started doing some more thorough testing of vtiger 5.0. I have created 3 new tickets on it. I was able to create patches for the first two. #1531 is to reset the Quick Create menu to Quick Create... after selecting an item (with a patch). #1532 cleans up the formatting of the AllMenu: putting headers on all columns, keeping the length more consistent (with a patch). #1533 is a bug when resizing the window too small. the HomePage Dashboard looks horrible. There needs to be some resize code, but I've not had time to look into patching this one. If I have time, I will also look for solutions to some of the error logs and IE JavaScript Issues. Not sure how much free time I'll have... Brian On Jul 18, 2006, at 5:20 AM, Richie wrote: > I am quoting Gopal's bug report. > " > As per discussion. I am testing product on the following setup: > OS: Win XP (SP2) XAMPP (apachefriends) -xampp-win32-1.5.3a- > installer.exe php settings: > error_reporting = E_ALL display_errors = On display_startup_errors > = On log_errors = On > After completion of installation 1.2 mb error log is generated in > Apache error.log file. > It is better to fix some of the notices and warnings, which will > definitely improve the performance of the product. > Thanks, Gopal > " > > > Need helping hands who can dig into this and give the fixes. > We are held up with validation over here. > > Richie > _______________________________________________ > Get started with creating presentations online - http:// > zohoshow.com?vt From dgrant at accuratetechnologies.com Tue Jul 18 05:58:03 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Tue, 18 Jul 2006 08:58:03 -0400 Subject: [Vtigercrm-developers] vtiger arch going forward Message-ID: <3E26E7A199CABA49822B3E6B741434F97D090C@exch.accuratetechnologies.com> >> It is plain that as of now, there are only 2 "strong/loud" arguments. >> I am sure you all will agree that both of them are not overly >> subscribed by any majority yet. > Yes but there is only one idea on the table, and 1 set of criticisms > followed by absolutely no suggestions on how to better the first idea. > This was really my bitch about the first set of posts. Then frankly, you misread. 1) All code must be commented. Ideally, this would be a priority such that commenting existing code would be an actual project, but realistically, the goal of "all NEW code must be commented" or perhaps "every time you touch the code, a comment must be inserted" is doable. 2) The current (4.x) architecture uses a number of "common" functions (so identified by virtue of living in the include directory) that are not really common. An easy test is that if at any time a soi-disant "common" function tests to see what module it was called from and then acts differently based on the result of that test, it ain't common. Those functions should be broken out of the include directory and moved into the appropriate module directory - perhaps something like modules/Foo/UI.php (although this naming convention is definitely open for discussion) 3) Any time you go to the database, the actual SQL should be exposed; it helps integrators understand the layout and function of the database and makes extending the database much easier. It's OK to streamline db functions somewhat though - something like: $query = 'SOME SQL'; @2D_array = query_db($query) or handle_db_error; Is OK. 3) All modules must be atomic. At no time is it EVER permissible that changing the code in module FOO *changes* the functionality of module BAR - with one exception; if module FOO ever *calls* module BAR, and a code change to BAR has broken the interface, then it is understood that FOO calling BAR will break (and shame on whoever changed BAR's interface) In some cases, this will actually move functionality INTO common code, and that's a good thing. For example, currently HelpDesk calls code in Emails to do its email notification stuff (HORROR!) This would be better served by a function in utils.php that called some sort of generic email API: $result = send_email($to, $from, $cc, $bcc, $subject, $body, $flags); 4) There are two major challenges facing the vtiger architecture, independent of code structure: a) Per-user localization, which in turn is broken down into: i) User language of choice; and ii) User operating currency (which may be a function of what office the user is working out of) b) Per-user security (a user cannot edit someone else's Quote, for example) Both of these are ABSOLUTE MUSTS going forward, and there's a lot of heavy lifting there. No matter what the code structure is, these two design structures must be part of the arch. I'm hoping that 5.0 has support for this already... >> Let us get some more ideas- however radical they be- into this list >> and then we will vote the good ideas in. > This is a great idea. I have been looking forward to someone else > posting some ideas to get the ball rolling. I for one welcome radical > ideas if anyone has any. Hrm, well, let's see how welcoming you *really* are. DG From jens at Strawberry.COM Tue Jul 18 06:16:35 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 15:16:35 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] Message-ID: <20060718151635.D16513@Strawberry.COM> -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- An embedded message was scrubbed... From: Jens Hamisch Subject: Patches required for PostgreSQL 8.1.4 Date: Tue, 18 Jul 2006 09:02:01 +0200 Size: 27774 Url: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/efd557cc/attachment-0005.mht From allan.bush+vtiger_dev at gmail.com Tue Jul 18 07:14:27 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 07:14:27 -0700 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <20060718151635.D16513@Strawberry.COM> References: <20060718151635.D16513@Strawberry.COM> Message-ID: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> I have given up on getting postgres support into 5.0 because I got tired of having my changes reverted and the database changing on me. The last straw was when all the database table names were changed without warning. If someone else wants to continue the effect feel free to take a look at this patch and take over the effort. On 7/18/06, Jens Hamisch wrote: > > -- > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > > ---------- Forwarded message ---------- > From: Jens Hamisch > To: vtigercrm-developers at lists.vtigercrm.com > Date: Tue, 18 Jul 2006 09:02:01 +0200 > Subject: Patches required for PostgreSQL 8.1.4 > Hi, > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > database. Compared to mySQL this database seems to require some code > changes. I've located and fixed the following problems: > > 1. SELECT count(*) count FROM ... won't work. > The AS clause is missing: SELECT count(*) AS count FROM ... > > 2. Referring table columns in case of joined tables in the > SELECT or ORDER BY clause requires the columns also to be > listed in a GROUP BY clause. > > 3. tablename.* won't work in a GROUP BY clause > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > LIMIT and OFFSET clause. > > 5. PostgreSQL supports transactions. However the current coding > results in transaction failures. > > I've attached my patches to this mail. Those patches at a first glance > address the problems 1-4. The transaction problem is not yet fixed. > I want to clean up the "simple" SQL statements first, before analyzing > such complex things. > > I'm not a 100% satisfied with the patches, because they introduce some > dbType dependencies into the "high level" vtiger code. Also structural > information is required in the function which expands the queries by > the required GROUP BY clause. I was thinking of moving those things > to a more abstract layer, but stopped doing this, because a generic > solution would either result in parsing and fixing each entire SQL statement > (including all its features and possibilities) or a redesign of the > affected SQL queries itsself. > > In most cases (especially the LIMIT changes) my patches might also work > for mySQL, so the database dependency possibly could be removed. This > might also apply to some of the GROUP BY patches. > > > Hope those changes will find their way to the vtigercrm5 mainline. > > Kind regards > -- Jens > > -------------------------------------------------------------------------------- > / > +##+|##+ STRAWBERRY Jens Hamisch > +v#+v v##+ EDV-Systeme GmbH Managing director > / v v\v > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > | . | Fax: (+49 8171) 41805-59 > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > \____/ Strawberry at Strawberry.COM > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > From jens at Strawberry.COM Tue Jul 18 08:12:13 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 17:12:13 +0200 Subject: [Vtigercrm-developers] [jens: Patches required for PostgreSQL 8.1.4] In-Reply-To: <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com>; from Allan Bush on Tue, Jul 18, 2006 at 07:14:27AM -0700 References: <20060718151635.D16513@Strawberry.COM> <3bec26390607180714m1b323590m1ef05305eb2df443@mail.gmail.com> Message-ID: <20060718171213.F16513@Strawberry.COM> Hi Allan, hi *, most changes I did seem not to be related to postgres only. So it would help a lot (and remove dbType dependencies) from the code if smb. could check if my changes will also be valid for mySQL ... Jens On Tue, Jul 18, 2006 at 07:14:27AM -0700, Allan Bush wrote: > I have given up on getting postgres support into 5.0 because I got > tired of having my changes reverted and the database changing on me. > The last straw was when all the database table names were changed > without warning. > > If someone else wants to continue the effect feel free to take a look > at this patch and take over the effort. > > On 7/18/06, Jens Hamisch wrote: > > > > -- > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > > > ---------- Forwarded message ---------- > > From: Jens Hamisch > > To: vtigercrm-developers at lists.vtigercrm.com > > Date: Tue, 18 Jul 2006 09:02:01 +0200 > > Subject: Patches required for PostgreSQL 8.1.4 > > Hi, > > > > I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 > > database. Compared to mySQL this database seems to require some code > > changes. I've located and fixed the following problems: > > > > 1. SELECT count(*) count FROM ... won't work. > > The AS clause is missing: SELECT count(*) AS count FROM ... > > > > 2. Referring table columns in case of joined tables in the > > SELECT or ORDER BY clause requires the columns also to be > > listed in a GROUP BY clause. > > > > 3. tablename.* won't work in a GROUP BY clause > > > > 4. LIMIT #,# is not supported. PostgreSQL requires a single > > LIMIT and OFFSET clause. > > > > 5. PostgreSQL supports transactions. However the current coding > > results in transaction failures. > > > > I've attached my patches to this mail. Those patches at a first glance > > address the problems 1-4. The transaction problem is not yet fixed. > > I want to clean up the "simple" SQL statements first, before analyzing > > such complex things. > > > > I'm not a 100% satisfied with the patches, because they introduce some > > dbType dependencies into the "high level" vtiger code. Also structural > > information is required in the function which expands the queries by > > the required GROUP BY clause. I was thinking of moving those things > > to a more abstract layer, but stopped doing this, because a generic > > solution would either result in parsing and fixing each entire SQL statement > > (including all its features and possibilities) or a redesign of the > > affected SQL queries itsself. > > > > In most cases (especially the LIMIT changes) my patches might also work > > for mySQL, so the database dependency possibly could be removed. This > > might also apply to some of the GROUP BY patches. > > > > > > Hope those changes will find their way to the vtigercrm5 mainline. > > > > Kind regards > > -- Jens > > > > -------------------------------------------------------------------------------- > > / > > +##+|##+ STRAWBERRY Jens Hamisch > > +v#+v v##+ EDV-Systeme GmbH Managing director > > / v v\v > > | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 > > | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 > > | . | Fax: (+49 8171) 41805-59 > > \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM > > \____/ Strawberry at Strawberry.COM > > > > > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From allan.bush+vtiger_dev at gmail.com Tue Jul 18 08:21:46 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Tue, 18 Jul 2006 08:21:46 -0700 Subject: [Vtigercrm-developers] Commit list is broken Message-ID: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> I haven't received any email from the commit/ticket list (vtigercrm-commits at lists.vtigercrm.com) since the 16th. I just made a couple changes which should have triggered emails and they haven't been received either so I'm fairly certain the list is down. From mmbrich at fosslabs.com Tue Jul 18 11:28:48 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Tue, 18 Jul 2006 12:28:48 -0600 Subject: [Vtigercrm-developers] Commit list is broken In-Reply-To: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> References: <3bec26390607180821h5318d543m41ba1060046550ad@mail.gmail.com> Message-ID: <1153247328.5582.214.camel@localhost.localdomain> This is probably from the SVN upgrade, the version we are on now moved all hook scripts to a diff area and I probably missed one. I'll see if I can fix it ASAP. Matt On Tue, 2006-07-18 at 08:21 -0700, Allan Bush wrote: > I haven't received any email from the commit/ticket list > (vtigercrm-commits at lists.vtigercrm.com) since the 16th. > > I just made a couple changes which should have triggered emails and > they haven't been received either so I'm fairly certain the list is > down. > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From jens at Strawberry.COM Tue Jul 18 11:44:48 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 20:44:48 +0200 Subject: [Vtigercrm-developers] Yet another postgres8 patch Message-ID: <20060718204448.D29275@Strawberry.COM> Hi, yet another patch addressing postgres8 Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- *** vtiger_crm/include/database/Postgres8.php.rev8092 Tue Jul 18 20:37:05 2006 --- vtiger_crm/include/database/Postgres8.php Tue Jul 18 20:38:50 2006 *************** *** 122,127 **** --- 122,131 ---- elseif( $table == "vtiger_profile2field") $subfields = array ( "profileid", "tabid", "fieldid", "visible", "readonly"); + //vtiger_field + elseif( $table == "vtiger_field") + $subfields = array ( "tabid", "fieldid", "columnname", "tablename", "generatedtype", "uitype", "fieldname", "fieldlabel", "readonly", "presence", "selected", "maximumlength", "sequence", "block", "displaytype", "typeofdata", "quickcreate", "quickcreatesequence", "info_type"); + //fields of the requested array still undefined else $log->info("function expandRecord: please add structural information for table '".$table."'"); *** vtiger_crm/include/utils/CommonUtils.php.rev8092 Tue Jul 18 20:25:23 2006 --- vtiger_crm/include/utils/CommonUtils.php Tue Jul 18 20:36:01 2006 *************** *** 960,971 **** { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in $blockid_list and vtiger_field.displaytype in (1,2,4) order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and vtiger_field.displaytype in (1,2,4) and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." group by vtiger_field.fieldid order by block,sequence"; } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); --- 960,974 ---- { if($is_admin == true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == "Users") { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN $blockid_list AND vtiger_field.displaytype IN (1,2,4) ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND vtiger_field.displaytype IN (1,2,4) AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } $result = $adb->query($sql); $getBlockInfo=getDetailBlockInformation($module,$result,$col_fields,$tabid,$block_label); *************** *** 976,987 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list ." and ".$display_type_check." and info_type = '".$info_type."' order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and info_type = '".$info_type."' and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } else --- 979,993 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2]== 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list ." AND ".$display_type_check." AND info_type = '".$info_type."' ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND info_type = '".$info_type."' AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } else *************** *** 988,999 **** { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "select vtiger_field.* from vtiger_field where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." order by block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and vtiger_field.block in ".$blockid_list." and ".$display_type_check." and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList.=" group by vtiger_field.fieldid order by block,sequence"; } } $result = $adb->query($sql); --- 994,1008 ---- { if($is_admin==true || $profileGlobalPermission[1] == 0 || $profileGlobalPermission[2] == 0 || $module == 'Users') { ! $sql = "SELECT vtiger_field.* FROM vtiger_field WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." ORDER BY block,sequence"; } else { $profileList = getCurrentUserProfileList(); ! $sql = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND vtiger_field.block IN ".$blockid_list." AND ".$display_type_check." AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList.=" GROUP BY vtiger_field.fieldid ORDER BY block,sequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $sql = fixPostgresQuery( $sql, $log, 0); } } $result = $adb->query($sql); *************** *** 1789,1796 **** } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "select vtiger_field.* from vtiger_field inner join vtiger_profile2field on vtiger_profile2field.fieldid=vtiger_field.fieldid inner join vtiger_def_org_field on vtiger_def_org_field.fieldid=vtiger_field.fieldid where vtiger_field.tabid=".$tabid." and quickcreate=0 and vtiger_profile2field.visible=0 and vtiger_def_org_field.visible=0 and vtiger_profile2field.profileid in ".$profileList." order by quickcreatesequence"; } $category = getParentTab(); --- 1798,1808 ---- } else { ! $profileList = getCurrentUserProfileList(); ! $quickcreate_query = "SELECT vtiger_field.* FROM vtiger_field INNER JOIN vtiger_profile2field ON vtiger_profile2field.fieldid=vtiger_field.fieldid INNER JOIN vtiger_def_org_field ON vtiger_def_org_field.fieldid=vtiger_field.fieldid WHERE vtiger_field.tabid=".$tabid." AND quickcreate=0 AND vtiger_profile2field.visible=0 AND vtiger_def_org_field.visible=0 AND vtiger_profile2field.profileid IN ".$profileList." ORDER BY quickcreatesequence"; ! //Postgres 8 fixes ! if( $adb->dbType == "pgsql") ! $quickcreate_query = fixPostgresQuery( $quickcreate_query, $log, 0); } $category = getParentTab(); *** vtiger_crm/modules/Users/Authenticate.php.rev8092 Tue Jul 18 19:55:38 2006 --- vtiger_crm/modules/Users/Authenticate.php Tue Jul 18 19:57:24 2006 *************** *** 40,47 **** { //Inserting entries for audit trail during login ! $date_var = date('YmdHis'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,$date_var)"; $adb->query($query); --- 40,47 ---- { //Inserting entries for audit trail during login ! $date_var = date('Y-m-d H:i:s'); ! $query = "insert into vtiger_audit_trial values(".$adb->getUniqueID('vtiger_audit_trial').",".$focus->id.",'Users','Authenticate',0,'$date_var')"; $adb->query($query); From libregeek at gmail.com Tue Jul 18 22:07:25 2006 From: libregeek at gmail.com (Manilal K M) Date: Wed, 19 Jul 2006 10:37:25 +0530 Subject: [Vtigercrm-developers] Something happened with forums.vtiger.com Message-ID: <2315046d0607182207k577376efv69026d9ce7e887c2@mail.gmail.com> Hi Team, Today Morning I got the reminder for the forum topic given below. How this happened? There are mo updates on this thread and it's almost 4 months old. Please look into it. regards Manilal ---------- Forwarded message ---------- From: webmaster at vtiger.com Date: 19-Jul-2006 07:38 Subject: New Topic Notification for forum "Announcements" - vtiger CRM 5 Alpha 5 Released To: Hello ! Sai has posted a new topic called "vtiger CRM 5 Alpha 5 Released" in the "Announcements" forum at vtiger. You can use the following link to view the topic: http://forums.vtiger.com/viewtopic.php?p=23074#23074 ----------------------------------------------- Posted text: Hi, We are pleased to announce the vtiger [b:7141f7c5eb]CRM 5.0 Alpha 5 release[/b:7141f7c5eb]. The intent of this release is to showcase to the vtiger community, the significant changes made after v5 Alpha 4 release i.e., changes since Mar 31, 06\' . We have conducted performance testing for some of the modules using a popular [b:7141f7c5eb]Web Based Testing Software (AdventNet QEngine 6.0),[/b:7141f7c5eb] which helped us to identify some of the bottlenecks in performance. We will publish the performance reports soon. We thank AdventNet for permitting us to make use of this interesting software and we gladly recommend it to everyone too, not because AdventNet allowed us to use it but because it is really good. We are also pleased to release the downloadable version of the [b:7141f7c5eb]vtiger CRM PHP API Documentation.[/b:7141f7c5eb] The demo of vtigerCRM 5 alpha 5 is available at http://vtiger.com/products/crm/demo_5alpha/index.php You can download the [b:7141f7c5eb]EXE, BIN, or tar.gz[/b:7141f7c5eb] from Sourceforge.net. [b:7141f7c5eb]NOTE:[/b:7141f7c5eb] We strongly recommend CRM community NOT to USE vtiger CRM 5 Alpha 5 for real-time deployment. In case you are looking for an immediate CRM solution for your business, please consider using the vtiger CRM 4.2.3 (latest stable version) or 4.2.4 which will be out shortly. [b:7141f7c5eb]Important URLs:[/b:7141f7c5eb] [b:7141f7c5eb]Download:[/b:7141f7c5eb] http://sourceforge.net/project/showfiles.php?group_id=117522&package_id=186641 [b:7141f7c5eb]Report Bugs[/b:7141f7c5eb] @: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/newticket Note: Please refer to the reported bugs before submitting a new bug. [b:7141f7c5eb]Release Notes:[/b:7141f7c5eb] * Smarty template applied to Currency Configuration Feature * List View feature database queries are optimized for all the modules * PHP API documentation for some of the major function * New module called Marketing is added. Campaigns module is now part of Marketing primary module. * AJAXified Notification Schedulers * AJAXified Inventory Notifications * AJAXified Picklist Settings * AJAXified Assign Module Owners * New UI for Integration of Mail Merge Templates * New UI for Company Information * New UI for Outgoing Mail Server * New UI for Backup Server Configuration * New UI for Terms and Conditions * New UI for Announcements * New UI for RSS module Thanks & Regards, Don ----------------------------------------------- You are receiving this email because you are watching the forum, "Announcements" at vtiger. If you no longer wish to watch this forum you can either click the "Stop watching this forum link" found at the bottom of the "Announcements" forum, or by clicking the following link: http://forums.vtiger.com/viewforum.php?f=1&unwatch=forum -- Thanks, The Management -- I would rather be a serf in a poor man's house and be above ground than reign among the dead From dgrant at accuratetechnologies.com Wed Jul 19 05:58:46 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Wed, 19 Jul 2006 08:58:46 -0400 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Simple question: when is the next (Beta?) release of V5.0 due out? DG From richie at vtiger.com Wed Jul 19 06:22:20 2006 From: richie at vtiger.com (Richie) Date: Wed, 19 Jul 2006 06:22:20 -0700 Subject: [Vtigercrm-developers] When is the next (Beta) release of 5.0 due out? In-Reply-To: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> References: <3E26E7A199CABA49822B3E6B741434F9010C4CE2@exch.accuratetechnologies.com> Message-ID: <10c86f3829c.5523764322808677804.-2671785383507032457@@vtiger.com> Simpler answer :-): No betas. Expect RC1 in 10 days or so. Richie ---- Dennis Grant<dgrant at accuratetechnologies.com> wrote ---- Simple question: when is the next (Beta?) release of V5.0 due out? DG _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/e1ba94eb/attachment-0005.html From Matjaz.Slak at atol.si Wed Jul 19 07:45:49 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Wed, 19 Jul 2006 16:45:49 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator In-Reply-To: <10c7cfde0ec.-7567737475230530784.1267434763934696102@@vtiger.com> Message-ID: Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/66b165ff/attachment-0003.bin From developer at infointegrated.com Wed Jul 19 21:45:03 2006 From: developer at infointegrated.com (Brian Devendorf) Date: Wed, 19 Jul 2006 23:45:03 -0500 Subject: [Vtigercrm-developers] Categories / Sub-Categories, Too Much In-Reply-To: References: Message-ID: If you haven't looked at the current collection of categories and subcategories, take a look. I think that it is becoming too much. Here's the current layout: My Home Page Home Activities Calendar Emails Marketing Campaigns Accounts Contacts Emails Leads Activities Calendar Notes Sales Leads Accounts Contacts Potentials Quotes Sales Order Invoice Products PriceBooks Notes Activities Calendar Support HelpDesk FAQ Accounts Contacts Products Notes Emails Activities Calendar Analytics Dashboard Reports Inventory Products Vendors PriceBooks Purchase Order Sales Order Quotes Invoice Tools RSS My Sites Notes Settings Settings I know the list is long and hard to read, but that's my point. I know and understand that different people will want their sub-modules in different places. As long as the method for changing this is documented, I think that is ok. The default configuration, though, should be simpler. This current layout is almost scary. At least for an end-user it would be. I feel this change should be made before 5.0 GA. To simplify, each item should only appear in one category. I have an updated proposal below that is the closest to meeting most of my customer's needs. With the All Menu, Quick Create, Related Items, and Tag Cloud, it shouldn't matter much if some modules are on different categories. I hope that there are still plans on combining activities and calendar into one item as well (I believe this was put off until after 5.0 GA). I think that an interface for managing these should also be planned post 5.0 GA. I also think the order of the items is important and (where relevant) the order should remain consistent. For example, the sub categories should remain in the same order under the category as it shows in the All Menu. What does everyone else think? Anyone else show this to existing clients and get questions about why the same module appears in many places? That's what got me started thinking of improvements. Any better ideas? My Home Page Home Emails Activities Calendar Contacts Notes Marketing Campaigns Leads Sales Accounts Potentials Quotes Sales Order Invoice Support HelpDesk FAQ Inventory Products Vendors PriceBooks Purchase Order Analytics Dashboard Reports Tools Settings My Sites RSS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060719/50687ed3/attachment-0003.html From richie at vtiger.com Thu Jul 20 01:06:18 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:06:18 -0700 Subject: [Vtigercrm-developers] unable to add users to trac Message-ID: <10c8af88631.-2915976287139770639.-215398406965928840@@vtiger.com> Hi Matt! Could you please have a look at the issue please? I am unable to add users to the trac anymore. I am using the following url. vtiger.fosslabs.com/service Do have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/02abcafe/attachment-0005.html From richie at vtiger.com Thu Jul 20 01:17:10 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:17:10 -0700 Subject: [Vtigercrm-developers] trac down? Message-ID: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Hi! The trac seems to be down. Matt, kindly have a look please. Thanks, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/df8c96af/attachment-0003.html From mmbrich at fosslabs.com Thu Jul 20 01:24:10 2006 From: mmbrich at fosslabs.com (Matthew Brichacek) Date: Thu, 20 Jul 2006 02:24:10 -0600 Subject: [Vtigercrm-developers] trac down? In-Reply-To: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> References: <10c8b0278ae.-9002778801615857072.1057344642665544178@@vtiger.com> Message-ID: <1153383850.5617.0.camel@localhost.localdomain> I was doing some work and had to give it a quick reboot. Should be back up and working now. Matt On Thu, 2006-07-20 at 01:17 -0700, Richie wrote: > Hi! > > The trac seems to be down. > Matt, kindly have a look please. > > Thanks, > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From crm at email.si Thu Jul 20 02:47:37 2006 From: crm at email.si (Ales Petric) Date: Thu, 20 Jul 2006 10:47:37 +0100 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44AE643B.1040800@vtigerfacile.com> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> Message-ID: <44BF5139.9050402@email.si> Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Ai"ssa wrote: > Hi Richie, > i have a login for track, but not the right to submit ticket. > thanks, > Ai"ssa (very busy !) > > Richie a ?crit : > >> Hello! >> >> I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. >> Please cross-check if you have received the relevant mails in the id from which you had made the access >> request. >> >> Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. >> >> richie at vtiger dot com >> >> Richie >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Get started with creating presentations online - http://zohoshow.com?vt >> > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/f47f9233/attachment-0005.html From richie at vtiger.com Thu Jul 20 01:58:46 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 01:58:46 -0700 Subject: [Vtigercrm-developers] trac account In-Reply-To: <44BF5139.9050402@email.si> References: <10c476f9dbe.-2514404851055697897.-5942011927368110348@@vtiger.com> <44AE643B.1040800@vtigerfacile.com> <44BF5139.9050402@email.si> Message-ID: <10c8b2890c0.2475106285347017844.4336268421121807772@@vtiger.com> Hi Ales! I have granted permission to the trac to all those who have asked for it. Not even 1 single request has been denied. Why should it be? The product is as much yours as mine just that someone has to be in some hiearchy somewhere does not mean that we have a monopoly over it. This is the first time I have got your request and I have granted access to you too. The 1 minute that I spend giving permission saves hours to the community as a whole. You are important, not only to me but to the community as well. I am sure you will do well. Richie ---- Ales Petric<crm at email.si> wrote ---- Hi Richie If this is true, I would like to get login account on 4.2.x and 5.x trac project. Maybe you have read my posts, on which nobody was replying, I was talking about 4.2.x which is big loss if you don't have a plan maintaining it. Any way maybe you will have 1 min to give someone else account with usable permissions. If you don't need another hand to speedup bug solving I understand. By Ales Aïssa wrote: Hi Richie, i have a login for track, but not the right to submit ticket. thanks, Aïssa (very busy !) Richie a ?crit : Hello! I have received quite a lot of requests for the trac access and ALL OF THEM HAVE BEEN granted access. Please cross-check if you have received the relevant mails in the id from which you had made the access request. Note: It is your right to have a trac access. So, please escalate IMMEDIATELY if you have not got your login. richie at vtiger dot com Richie ------------------------------------------------------------------------ _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/aeeddad4/attachment-0003.html From richie at vtiger.com Thu Jul 20 08:30:05 2006 From: richie at vtiger.com (Richie) Date: Thu, 20 Jul 2006 08:30:05 -0700 Subject: [Vtigercrm-developers] permissions revoked Message-ID: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Dear Team, I have revoked permissions for checkin in the main 5.0 trunk. Only the following have permission to checkin now into the 5.0 trunk. core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj All checkins have to be thru these guys alone. The permissions will be restored once the 5.0 is released. Requesting your understanding, Richie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/0cea747a/attachment-0005.html From tgironnay at lexsi.com Thu Jul 20 08:54:15 2006 From: tgironnay at lexsi.com (GIRONNAY Thibault) Date: Thu, 20 Jul 2006 17:54:15 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi all, Matjaz I'll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It's too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we'll have others hands up cabugs ________________________________ De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: * debugging (fixing parts that either don't work at all and/or work incorrectly) * improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: * multilanguage support (simply get rid of any and all hard-coded strings) * full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060720/fdd85202/attachment-0003.html From nolan at peaceworks.ca Thu Jul 20 10:50:43 2006 From: nolan at peaceworks.ca (Nolan Andres) Date: Thu, 20 Jul 2006 13:50:43 -0400 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: References: Message-ID: <44BFC273.5060604@peaceworks.ca> Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt From dgrant at accuratetechnologies.com Thu Jul 20 10:47:54 2006 From: dgrant at accuratetechnologies.com (Dennis Grant) Date: Thu, 20 Jul 2006 13:47:54 -0400 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <3E26E7A199CABA49822B3E6B741434F9010C4CE4@exch.accuratetechnologies.com> Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection My vtigercrm.log is full of these. Where are they coming from and what can I do to stop it? DG From jens at Strawberry.COM Thu Jul 20 23:34:10 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Fri, 21 Jul 2006 08:34:10 +0200 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com>; from Richie on Thu, Jul 20, 2006 at 08:30:05AM -0700 References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> Message-ID: <20060721083410.A22106@Strawberry.COM> Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM From Matjaz.Slak at atol.si Fri Jul 21 00:04:48 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 09:04:48 +0200 Subject: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator In-Reply-To: Message-ID: Hi! I agree completly. Security should be on the list of to-dos. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 "GIRONNAY Thibault" Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 17:54 Please respond to vtigercrm-developers at lists.vtigercrm.com To cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Matjaz I?ll be with you and your team in your enterprise, I agree with your priorities and have one another to add : the security. The organisation sharing privileges for example is indeed totally an illusion. It?s too easy too change those settings while not being admin or to see all records even if the privileges are private. I think this is very harmful to offer such buggy features and can discredit Vtiger for the people who have interests in security. Hope we?ll have others hands up cabugs De : vtigercrm-developers-bounces at lists.vtigercrm.com [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] De la part de Matjaz.Slak at atol.si Envoy? : mercredi 19 juillet 2006 16:46 ? : vtigercrm-developers at lists.vtigercrm.com Objet : Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi Richie and the rest of the team! You address me correctly, Matjaz is my name :) As I belive the 4.2.x stream is the current "production" vTiger environment for most of the users, my primary goal would be to focus on: debugging (fixing parts that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) I would also like to try and get the following not-quite-features, maybe bugs? implemented/fixed: multilanguage support (simply get rid of any and all hard-coded strings) full per user or at least per-system localization support (number format, date format, currency support etc) These two last items are - in my opinion - somewhere between debugging and new features. vTiger is already supposed to support multiple languages, however this support is not well implemented. The same can be said for localization - vTiger is supposed to be able to support per-user date format, but again there are areas where the implementation is not as good as it could be. Also, based on my researches into existing vTiger deployments, I see there are a lot of non-english users, but they probably are using forked code, as due to these two issues they cannot use the "official" 4.2.x stream code. I would like to get these users back on the team, and I know they might return only if we provide them with a 100% localisable product. This will enable them to post the patches they make back to the community or at least give them an opportunity to work with us on resolving them. I would try and keep us on this track, rather than go try implement new features and make large changes to UI - the place for these is v5. To achieve this, I would first gather any and all contributions currently lying around (in the forum, as provided by other people here etc.) - matching the categories above - and start the process of getting them in the code. I would like to see a show of hands from people that would be prepared to devote some time to debugging/updating tthese contributions - as some might need an update. I know me and my colleagues in our company will. If all goes well, we could try and implement a regular timeline (say every month) when we would be releasing point versions. If I get at least two or three people to help, I guess we could have our first result (4.2.5 I guess) in two months. I think there will be people using the 4.2.x stream for at least a year after v5 is released, and that if we as a team show them we are supporting them, than they will upgrade to v5 -> if we don't they might start looking elsewhere. Thoughts, anyone? Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Richie Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 17.07.2006 16:57 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc vtigercrm-developers at lists.vtigercrm.com Subject Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator Hi Matjaz! I hope I am addressing you properly if not please forgive me and direct to the proper mode of addressing. If you are game then great! Welcome to the club. Please select your stand-in helper so that at least we have a backup for Linus Matjaz. Let me know and I will grant you the relevant access. It would be nice if you could briefly state how you plan to address the disparate contributions. This is just to get an idea as there are lots of data floating around in the code contributions and mailing lists; wanted to know if you have any specific plan. I will be busy with the v5 release and will not be able to help you much so the query. I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki page which reflects the status of the contributions. I am not sure if that is updated till the 4.2.4 release though. http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions Allan, any tips from you will be nice. Richie ---- Sergio A. Kessler wrote ---- On 7/14/06, Matjaz.Slak at atol.si wrote: > > Hi! > > If there's no one else, I volunteer to be the v4 Linus. just do it. ;-) /sak _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -- Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/29e3465c/attachment-0003.bin From Matjaz.Slak at atol.si Fri Jul 21 04:36:00 2006 From: Matjaz.Slak at atol.si (Matjaz.Slak at atol.si) Date: Fri, 21 Jul 2006 13:36:00 +0200 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <44BFC273.5060604@peaceworks.ca> Message-ID: Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 Nolan Andres Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > > > > Matjaz I?ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It?s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > > > > Hope we?ll have others hands up > > > > cabugs > > > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > > > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > > * debugging (fixing parts that either don't work at all and/or work > incorrectly) > * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > > * multilanguage support (simply get rid of any and all hard-coded > strings) > * full per user or at least per-system localization support (number > format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > *Richie * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > > > > To > > > > vtigercrm-developers at lists.vtigercrm.com > > cc > > > > vtigercrm-developers at lists.vtigercrm.com > > Subject > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > Integrator > > > > > > > > > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si wrote: >> >> Hi! >> >> If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0005.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5476 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/c6859845/attachment-0003.bin From jtk at yahoo.com Fri Jul 21 06:09:10 2006 From: jtk at yahoo.com (Jeff Kowalczyk) Date: Fri, 21 Jul 2006 09:09:10 -0400 Subject: [Vtigercrm-developers] permissions revoked References: <20060721083410.A22106@Strawberry.COM> Message-ID: Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. From richie at vtiger.com Fri Jul 21 07:11:25 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:11:25 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: <20060721083410.A22106@Strawberry.COM> References: <10c8c8ed10f.3947318048230554597.2639884782692338233@@vtiger.com> <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916d296e.5312358042738553104.8864199634924158691@@vtiger.com> Hi Jens! Currently, we are working on fixing the breakages that we have committed. Let these stabilize, then we can integrate this together. ok? I do not want to add one more variable now. Hence the precaution. Richie ---- Jens Hamisch<jens at strawberry.com> wrote ---- Ritchie, could you please have a look at the postgres patches I've supplied to this list? I'd like to know if there's any intention in the vtiger team to support postgres8 (Means: To fix the broken postgres code in 5.0). If not, I will have to maintain my own local version, which is not appreciable. I've also noticed, that there's some problem around customer selection I'm going to drag down this weekend. The main list will not display all valid entries in the database, however using the "search" facility grants access to the "hidden" ones ... Jens On Thu, Jul 20, 2006 at 08:30:05AM -0700, Richie wrote: > Dear Team, > > I have revoked permissions for checkin in the main 5.0 trunk. > Only the following have permission to checkin now into the 5.0 trunk. > core-developers = mmbrich, richie, mickie, mangai, venkatraj, don, saraj > > All checkins have to be thru these guys alone. > > The permissions will be restored once the 5.0 is released. > Requesting your understanding, > > Richie > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt -- -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/ed49a8d5/attachment-0005.html From richie at vtiger.com Fri Jul 21 07:12:10 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:12:10 -0700 Subject: [Vtigercrm-developers] permissions revoked In-Reply-To: References: <20060721083410.A22106@Strawberry.COM> Message-ID: <10c916dd6be.-546019034062113847.-6787520244753134675@@vtiger.com> Yes, you are right. We will take this into consideration before vtigercrm-5.0.0 is out. In other words, postgres is going to be part of this very release. Richie ---- Jeff Kowalczyk<jtk at yahoo.com> wrote ---- Jens Hamisch wrote: > Ritchie, > could you please have a look at the postgres patches I've supplied to > this list? I'd like to know if there's any intention in the vtiger team > to support postgres8 (Means: To fix the broken postgres code in 5.0). If > not, I will have to maintain my own local version, which is not > appreciable. In an email sent to this list a few months ago, I suggested that full postgresql and mysql support is an imperative, however inconvenient, for all release versions starting with vtigercrm-4.2.5+ and vtigercrm-5.x, for this reason: There will probably never be a way to reliably migrate a populated production vtigercrm database from mysql to postgresql (or vice versa). The one you start with is likely to be the one you're stuck with. _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/51fe5c86/attachment-0003.html From richie at vtiger.com Fri Jul 21 07:13:48 2006 From: richie at vtiger.com (Richie) Date: Fri, 21 Jul 2006 07:13:48 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: References: Message-ID: <10c916f5716.-3447470126087516421.7834933168012625785@@vtiger.com> Matjaz, you already would have got the access mail for the trac. About the TRAC Wiki, Matt will do the needful. Let us know if you need anything else. Richie ---- Matjaz.Slak at atol.si<Matjaz.Slak at atol.si> wrote ---- Hi! Thank you! I hope I'll be able to finish up some of my other tasks within a week or so and then I'll start posting ideas about what to work on here. If anybody has any general wishes and/or requests about which item(s) you would like to have fixed in 4.2.x, post them here. By this I mean areas perceived by vTiger users. Try to fit them in the following categories: debugging (fixing user-perceived functions that either don't work at all and/or work incorrectly) improving usability (based on feedback from users) improving security (let us know of possible security holes) multilanguage support (simply get rid of any and all hard-coded strings) localization support (number format, date format, currency support etc - per user or at least per-system) other (we can create aditional categories if the need arises) For example: Private Custom Views - allow for a custom view to be marked as private and only be visible to the user that created it (usability) All View columns sortable - allow a user to click on any column and sort it (usability) Repeating calls/meetings - don't work at all? (debugging) etc... I'll be collecting them and posting them somewhere - the TRAC Wiki comes to mind as an appropriate place. We can the priorithise them and look into required work - and then create tickets for developers (us, again :) to work on. Richie, Jeff, Matt and/or others: would it me possible for me to have acces to post some content to the TRAC Wiki? I would create a document like "vTiger 4.2.x to-do area" that would include these items we wish to work on - and specific goals for them. Tickets would then be created based on these. This document would represent the general guideline. Matjaz Slak matjaz.slak at atol.si Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 Nolan Andres <nolan at peaceworks.ca> Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com 20.07.2006 19:50 Please respond to vtigercrm-developers at lists.vtigercrm.com To vtigercrm-developers at lists.vtigercrm.com cc Subject Re: [Vtigercrm-developers] An Impassioned        Plea        froma        VTiger        Integrator Hi all, Although I'd really love to be able to just contribute features without having to re-integrate (into v5,) I agree with priorities and I'll second the addition of security to the list. Security through obscurity is bad enough, but with open source projects, it simply becomes security through ignorance. I certainly wouldn't trust vTiger's security in an environment where the data is actually confidential and a malicious or competitive party would stand to gain by accessing it illicitly. I don't have the availability to co-ordinate things, but you can count on me for some quantity of bug-fixes, security patches, etc. peace, nokes GIRONNAY Thibault wrote: > Hi all, > >   > > Matjaz I’ll be with you and your team in your enterprise, I agree with > your priorities and have one another to add : the security. The > organisation sharing privileges for example is indeed totally an > illusion. It’s too easy too change those settings while not being admin > or to see all records even if the privileges are private. I think this > is very harmful to offer such buggy features and can discredit Vtiger > for the people who have interests in security. > >   > > Hope we’ll have others hands up > >   > > cabugs > >   > > ------------------------------------------------------------------------ > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > de* Matjaz.Slak at atol.si > *Envoy? :* mercredi 19 juillet 2006 16:46 > *? :* vtigercrm-developers at lists.vtigercrm.com > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > Integrator > >   > > > Hi Richie and the rest of the team! > > You address me correctly, Matjaz is my name :) > > > As I belive the 4.2.x stream is the current "production" vTiger > environment for most of the users, my primary goal would be to focus on: > >     * debugging (fixing parts that either don't work at all and/or work >       incorrectly) >     * improving usability (based on feedback from users) > > > I would also like to try and get the following not-quite-features, maybe > bugs? implemented/fixed: > >     * multilanguage support (simply get rid of any and all hard-coded >       strings) >     * full per user or at least per-system localization support (number >       format, date format, currency support etc) > > > These two last items are - in my opinion - somewhere between debugging > and new features. vTiger is already supposed to support multiple > languages, however this support is not well implemented. The same can be > said for localization - vTiger is supposed to be able to support > per-user date format, but again there are areas where the implementation > is not as good as it could be. > > Also, based on my researches into existing vTiger deployments, I see > there are a lot of non-english users, but they probably are using forked > code, as due to these two issues they cannot use the "official" 4.2.x > stream code. I would like to get these users back on the team, and I > know they might return only if we provide them with a 100% localisable > product. This will enable them to post the patches they make back to the > community or at least give them an opportunity to work with us on > resolving them. > > I would try and keep us on this track, rather than go try implement new > features and make large changes to UI - the place for these is v5. > > > To achieve this, I would first gather any and all contributions > currently lying around (in the forum, as provided by other people here > etc.) - matching the categories above - and start the process of getting > them in the code. *I would like to see a show of hands* from people that > would be prepared to devote some time to debugging/updating tthese > contributions - as some might need an update. I know me and my > colleagues in our company will. > > If all goes well, we could try and implement a regular timeline (say > every month) when we would be releasing point versions. If I get at > least two or three people to help, I guess we could have our first > result (4.2.5 I guess) in two months. > > I think there will be people using the 4.2.x stream for at least a year > after v5 is released, and that if we as a team show them we are > supporting them, than they will upgrade to v5 -> if we don't they might > start looking elsewhere. > > > *Thoughts, anyone?* > > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o.  |  http://www.atol.si  |  tel. +386 1 510 15 30 > > *Richie <richie at vtiger.com>* > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 17.07.2006 16:57 > > Please respond to > vtigercrm-developers at lists.vtigercrm.com > >                   > > To > >                   > > vtigercrm-developers at lists.vtigercrm.com > > cc > >                   > > vtigercrm-developers at lists.vtigercrm.com > > Subject > >                   > > Re: [Vtigercrm-developers] An Impassioned Plea from a        VTiger     >    Integrator > >   > >   > >                   > >   > > > > > Hi Matjaz! > I hope I am addressing you properly if not please forgive me and direct > to the proper mode of addressing. > > If you are game then great! > Welcome to the club. > Please select your stand-in helper so that at least we have a backup for > Linus Matjaz. Let me know and I will grant you the relevant access. > > It would be nice if you could briefly state how you plan to address the > disparate contributions. This is just to get an idea as there are lots > of data floating around in the code contributions and mailing lists; > wanted to know if you have any specific plan. I will be busy with the v5 > release and will not be able to help you much so the query. > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > page which reflects the status of the contributions. I am not sure if > that is updated till the 4.2.4 release though. > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > Allan, any tips from you will be nice. > > Richie > > > > > ---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- > > On 7/14/06, Matjaz.Slak at atol.si <Matjaz.Slak at atol.si> wrote: >> >>  Hi! >> >>  If there's no one else, I volunteer to be the v4 Linus. > > just do it. ;-) > > > /sak > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > <http://zohoshow.com?vt/> _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -- > > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt _______________________________________________ Get started with creating presentations online - http://zohoshow.com?vt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7be12bf9/attachment-0005.html From allan.bush+vtiger_dev at gmail.com Fri Jul 21 08:32:23 2006 From: allan.bush+vtiger_dev at gmail.com (Allan Bush) Date: Fri, 21 Jul 2006 08:32:23 -0700 Subject: [Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x In-Reply-To: <-8603876167918116646@unknownmsgid> References: <-8603876167918116646@unknownmsgid> Message-ID: <3bec26390607210832x65ed46eo60856d8e2972c110@mail.gmail.com> This is the page we should be using to keep track of everything to be done for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=new&status=assigned&status=reopened&milestone=4.2.5 It would be nice to have a 4.2.6 (or 4.2 future) milestone to keep the list realistic though. Fell free to organize, add and prioritize the things in that list. On the same note you here is the page of everything already accomplished for 4.2.5: http://vtiger.fosslabs.com/cgi-bin/trac.cgi/query?status=closed&milestone=4.2.5 On 7/21/06, Richie wrote: > > Matjaz, you already would have got the access mail for the trac. > About the TRAC Wiki, Matt will do the needful. > > > Let us know if you need anything else. > > Richie > > > > > ---- Matjaz.Slak at atol.si wrote ---- > > > > Hi! > > Thank you! > > I hope I'll be able to finish up some of my other tasks within a week or > so and then I'll start posting ideas about what to work on here. > > *If anybody has any general wishes and/or requests about which item(s) you > would like to have fixed in 4.2.x, post them here.* By this I mean areas > perceived by vTiger users. Try to fit them in the following categories: > > - debugging (fixing user-perceived functions that either don't work > at all and/or work incorrectly) > - improving usability (based on feedback from users) > - improving security (let us know of possible security holes) > - multilanguage support (simply get rid of any and all hard-coded > strings) > - localization support (number format, date format, currency support > etc - per user or at least per-system) > - other (we can create aditional categories if the need arises) > > > For example: > > - Private Custom Views - allow for a custom view to be marked as > private and only be visible to the user that created it (usability) > - All View columns sortable - allow a user to click on any column > and sort it (usability) > - Repeating calls/meetings - don't work at all? (debugging) > - etc... > > > I'll be collecting them and posting them somewhere - the TRAC Wiki comes > to mind as an appropriate place. We can the priorithise them and look into > required work - and then create tickets for developers (us, again :) to work > on. > > *Richie, Jeff, Matt and/or others:* would it me possible for me to have > acces to post some content to the TRAC Wiki? I would create a document like > "vTiger 4.2.x to-do area" that would include these items we wish to work > on - and specific goals for them. Tickets would then be created based on > these. This document would represent the general guideline. > > Matjaz Slak > matjaz.slak at atol.si > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > *Nolan Andres * > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > 20.07.2006 19:50 Please respond to > vtigercrm-developers at lists.vtigercrm.com > > To > vtigercrm-developers at lists.vtigercrm.com cc > > Subject > Re: [Vtigercrm-developers] An Impassioned Plea froma > VTiger Integrator > > > > > > > Hi all, > > Although I'd really love to be able to just contribute features without > having to re-integrate (into v5,) I agree with priorities and I'll > second the addition of security to the list. Security through obscurity > is bad enough, but with open source projects, it simply becomes security > through ignorance. I certainly wouldn't trust vTiger's security in an > environment where the data is actually confidential and a malicious or > competitive party would stand to gain by accessing it illicitly. > > I don't have the availability to co-ordinate things, but you can count > on me for some quantity of bug-fixes, security patches, etc. > > peace, > nokes > > GIRONNAY Thibault wrote: > > Hi all, > > > > > > > > Matjaz I'll be with you and your team in your enterprise, I agree with > > your priorities and have one another to add : the security. The > > organisation sharing privileges for example is indeed totally an > > illusion. It's too easy too change those settings while not being admin > > or to see all records even if the privileges are private. I think this > > is very harmful to offer such buggy features and can discredit Vtiger > > for the people who have interests in security. > > > > > > > > Hope we'll have others hands up > > > > > > > > cabugs > > > > > > > > ------------------------------------------------------------------------ > > > > *De :* vtigercrm-developers-bounces at lists.vtigercrm.com > > [mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] *De la part > > de* Matjaz.Slak at atol.si > > *Envoy? :* mercredi 19 juillet 2006 16:46 > > *? :* vtigercrm-developers at lists.vtigercrm.com > > *Objet :* Re: [Vtigercrm-developers] An Impassioned Plea froma VTiger > > Integrator > > > > > > > > > > Hi Richie and the rest of the team! > > > > You address me correctly, Matjaz is my name :) > > > > > > As I belive the 4.2.x stream is the current "production" vTiger > > environment for most of the users, my primary goal would be to focus on: > > > > * debugging (fixing parts that either don't work at all and/or work > > incorrectly) > > * improving usability (based on feedback from users) > > > > > > I would also like to try and get the following not-quite-features, maybe > > > bugs? implemented/fixed: > > > > * multilanguage support (simply get rid of any and all hard-coded > > strings) > > * full per user or at least per-system localization support (number > > format, date format, currency support etc) > > > > > > These two last items are - in my opinion - somewhere between debugging > > and new features. vTiger is already supposed to support multiple > > languages, however this support is not well implemented. The same can be > > > said for localization - vTiger is supposed to be able to support > > per-user date format, but again there are areas where the implementation > > > is not as good as it could be. > > > > Also, based on my researches into existing vTiger deployments, I see > > there are a lot of non-english users, but they probably are using forked > > > code, as due to these two issues they cannot use the "official" 4.2.x > > stream code. I would like to get these users back on the team, and I > > know they might return only if we provide them with a 100% localisable > > product. This will enable them to post the patches they make back to the > > > community or at least give them an opportunity to work with us on > > resolving them. > > > > I would try and keep us on this track, rather than go try implement new > > features and make large changes to UI - the place for these is v5. > > > > > > To achieve this, I would first gather any and all contributions > > currently lying around (in the forum, as provided by other people here > > etc.) - matching the categories above - and start the process of getting > > > them in the code. *I would like to see a show of hands* from people that > > > would be prepared to devote some time to debugging/updating tthese > > contributions - as some might need an update. I know me and my > > colleagues in our company will. > > > > If all goes well, we could try and implement a regular timeline (say > > every month) when we would be releasing point versions. If I get at > > least two or three people to help, I guess we could have our first > > result (4.2.5 I guess) in two months. > > > > I think there will be people using the 4.2.x stream for at least a year > > after v5 is released, and that if we as a team show them we are > > supporting them, than they will upgrade to v5 -> if we don't they might > > start looking elsewhere. > > > > > > *Thoughts, anyone?* > > > > > > Matjaz Slak > > matjaz.slak at atol.si > > > > Atol d.o.o. | http://www.atol.si | tel. +386 1 510 15 30 > > > > *Richie * > > Sent by: vtigercrm-developers-bounces at lists.vtigercrm.com > > > > 17.07.2006 16:57 > > > > Please respond to > > vtigercrm-developers at lists.vtigercrm.com > > > > > > > > To > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > cc > > > > > > > > vtigercrm-developers at lists.vtigercrm.com > > > > Subject > > > > > > > > Re: [Vtigercrm-developers] An Impassioned Plea from a VTiger > > Integrator > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matjaz! > > I hope I am addressing you properly if not please forgive me and direct > > to the proper mode of addressing. > > > > If you are game then great! > > Welcome to the club. > > Please select your stand-in helper so that at least we have a backup for > > > Linus Matjaz. Let me know and I will grant you the relevant access. > > > > It would be nice if you could briefly state how you plan to address the > > disparate contributions. This is just to get an idea as there are lots > > of data floating around in the code contributions and mailing lists; > > wanted to know if you have any specific plan. I will be busy with the v5 > > > release and will not be able to help you much so the query. > > I was earlier integrating it 1 by 1 till 4.2.3 and we do have a wiki > > page which reflects the status of the contributions. I am not sure if > > that is updated till the 4.2.4 release though. > > http://www.vtiger.com/wiki/index.php/Vtiger_CRM_Code_Contributions > > > > > > Allan, any tips from you will be nice. > > > > Richie > > > > > > > > > > ---- Sergio A. Kessler wrote ---- > > > > On 7/14/06, Matjaz.Slak at atol.si wrote: > >> > >> Hi! > >> > >> If there's no one else, I volunteer to be the v4 Linus. > > > > just do it. ;-) > > > > > > /sak > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > > > > -- > > > > Checked by AVG Anti-Virus. > > Version: 7.0.308 / Virus Database: 268.10.1 - Release Date: 14/07/2006 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Get started with creating presentations online - http://zohoshow.com?vt > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > > _______________________________________________ > Get started with creating presentations online - http://zohoshow.com?vt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/411ae3e6/attachment-0003.html From don at vtiger.com Fri Jul 21 09:31:48 2006 From: don at vtiger.com (don) Date: Fri, 21 Jul 2006 09:31:48 -0700 Subject: [Vtigercrm-developers] FATAL VT ERRORS - Where are these coming from? Message-ID: <10c91edb0e4.-4543952587404481040.-9186935435207679906@@vtiger.com> Hi DG, The logs given below are generated from the include/database/PearDatabase.php file. To avoid this kindly do the following: Edit the include/database/PearDatabase.php file and comment the following lines: -- $this->println("TRANS creating new connection"); in the function checkConnection -- $this->println("ADODB fetchByAssoc return null"); in the function function fetchByAssoc Hope this helps you. Kindly contact us for any further clarifications. Thanks & Regards, Don Thu Jul 20 13:49:13 2006,541 [31161] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:18 2006,583 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:18 2006,800 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:31 2006,831 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:32 2006,031 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:43 2006,363 [13673] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:43 2006,560 [13673] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:44 2006,203 [11544] FATAL VT - PearDatabase ->TRANS creating new connection Thu Jul 20 13:49:44 2006,406 [11544] FATAL VT - PearDatabase ->ADODB fetchByAssoc return null Thu Jul 20 13:49:48 2006,421 [11541] FATAL VT - PearDatabase ->TRANS creating new connection -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060721/7714d42a/attachment-0005.html From jens at Strawberry.COM Tue Jul 18 00:02:14 2006 From: jens at Strawberry.COM (Jens Hamisch) Date: Tue, 18 Jul 2006 07:02:14 -0000 Subject: [Vtigercrm-developers] Patches required for PostgreSQL 8.1.4 Message-ID: <20060718090201.B15699@Strawberry.COM> Hi, I'm currently running vtigercrm5 (revision 8057) using a Postgres 8.1.4 database. Compared to mySQL this database seems to require some code changes. I've located and fixed the following problems: 1. SELECT count(*) count FROM ... won't work. The AS clause is missing: SELECT count(*) AS count FROM ... 2. Referring table columns in case of joined tables in the SELECT or ORDER BY clause requires the columns also to be listed in a GROUP BY clause. 3. tablename.* won't work in a GROUP BY clause 4. LIMIT #,# is not supported. PostgreSQL requires a single LIMIT and OFFSET clause. 5. PostgreSQL supports transactions. However the current coding results in transaction failures. I've attached my patches to this mail. Those patches at a first glance address the problems 1-4. The transaction problem is not yet fixed. I want to clean up the "simple" SQL statements first, before analyzing such complex things. I'm not a 100% satisfied with the patches, because they introduce some dbType dependencies into the "high level" vtiger code. Also structural information is required in the function which expands the queries by the required GROUP BY clause. I was thinking of moving those things to a more abstract layer, but stopped doing this, because a generic solution would either result in parsing and fixing each entire SQL statement (including all its features and possibilities) or a redesign of the affected SQL queries itsself. In most cases (especially the LIMIT changes) my patches might also work for mySQL, so the database dependency possibly could be removed. This might also apply to some of the GROUP BY patches. Hope those changes will find their way to the vtigercrm5 mainline. Kind regards -- Jens -------------------------------------------------------------------------------- / +##+|##+ STRAWBERRY Jens Hamisch +v#+v v##+ EDV-Systeme GmbH Managing director / v v\v | . . . | Waldeckstr. 9a Car (Voice): (+49 172) 81 04 162 | . | D-82515 Wolfratshausen Voice: (+49 8171) 41805-0 | . | Fax: (+49 8171) 41805-59 \ . / Tel.: (+49 8171) 41805-0 Email: jens at Strawberry.COM \____/ Strawberry at Strawberry.COM -------------- next part -------------- A non-text attachment was scrubbed... Name: postgres-patches.tgz Type: application/octet-stream Size: 18385 bytes Desc: not available Url : http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060718/e9b482c8/attachment-0003.obj