[Vtigercrm-developers] Calling for wishes and/or requests about which item(s) you would like to have fixed in 4.2.x

Mike Fedyk mfedyk at mikefedyk.com
Sat Aug 12 22:58:38 PDT 2006


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)
>
Hi Matjaz,

I was one of the maintainers for the 4.2.x branch a few months ago but 
have been inactive for a few months -- I wonder if my commit access is 
still there...  It is good to see activity for 4.2.x. :) 

I would like to add a few cleanup/features to the list. 

1) Currently leads and contacts are kept in separate tables in the 
vtiger 4.2.x database schema.  If these are merged, then a whole new set 
of possibilities are available including but not limited to: lead 
companies, database simplification, contacts associated with a lead 
company, leads associated with an account, potentials associated with a 
lead company.

With this change, we may want to rename "account" to "company" or simply 
add "lead accounts" or similar.  Suggestions wanted.

2) Separate the modules a bit more -- especially during installation.  
Each module should have ownership over the tables it uses and the code 
that creates it should be within the module's directory.  I want to be 
able to enable/disable modules or simply not include the files during 
installation and identify core modules that interconnect and can't be 
reasonably be removed. 

Integrating mcrowe's installation system is probably a good idea as it 
can manage this quite easily.

3) Licensing.  We need to make sure all licenses we use allow commercial 
use.  I know that jgraph is under the QPL which prohibits commercial use 
and that there was some code to replace jgraph but don't know the 
status.  Also I would like to see a move away from the SPL and VPL 
(Sugar Public License and Vtiger Public License) to the LGPL.

The LGPL does not encourage license renaming like the MPL does (which 
both the SPL and VPL are based upon), and there is no argument that it 
is Free Software.  It also allows for integration of proprietary modules 
which is a good thing since you don't want to be restricted from 
integrating vtiger with anything when consulting.

Once we remove the last remnants of SPL code we can get rid of the 
notice at the bottom of every page that we are based on sugarcrm code.

4) Clean up the HTML produced by vtiger.  Right now all of the pages 
produced by vtiger 4.2.x are rendered in Firefox's quirks mode.  This 
really kills performance on older computers.  I suggest getting an old 
computer with nothing faster than a Pentium 3 (you can max the memory 
out and put new drives in there to make it faster -- the important part 
is reducing the rendering time) and use that to test the rendering speed.

5) Fix the quick search.  Why doesn't it search for names and phone 
numbers in leads, contacts and accounts?  There is more too.  We need to 
focus on making everything easily searchable.

6) Associability.  There are arbitrary restrictions placed on the 
information put into vtiger that shouldn't be.  Why can't a contact have 
a potential?  Why can't a lead have a potential (hint it is explained 
above)?  Where is the "referred by" field for leads, contacts and 
accounts (and I mean proper references within the database, not just a 
text field)?  These issues need to be fixed -- the "referred by" field 
alone is the foundation for adding MLM specific features.

7) Expectability.  A lot of fields like sales percentage are just text 
fields when you would expect calculations to be based upon them and used 
elsewhere.  There a lot of places like this that need to be fixed.

8) Using custom field types better.  If it is a phone number, it should 
be grouped with the other phone number fields so custom fields don't 
stand out like they are an afterthought.

9) We need to focus more on external modules.  If sugar did something 
right, it was their focus on API and external modules.  One way to do 
this is to take out some of our problematic modules, like invoices, 
inventory, mail, etc. and make them external modules that are installed 
after the core is put in.  This will allow the code to be put up on the 
vtiger forge and allow for competing modules to be created.

10) We need an online upgrade system.  This will allow an existing 
installation to be upgraded with the click of a button.  No more 
questions on the forum about the upgrade process.  It will even export 
their database before doing any changes.  Does anyone else do this?

And yes I want this in the 4.2.x codebase.  It has a lot of problems but 
they are fixable.

Frankly I think the 5.0 release will be a flop.  The UI was just too 
complicated last time I checked a few months ago.  And if it is like 
previous releases it will require a few patch releases before it is 
usable.  I'd appreciate it if someone forward ported these changes to 
the 5.0 codebase once they're done in 4.2.x.  I really have no interest 
in 5.0 at this time, but will probably backport some of the fixes that 
are there.  I hope I'm wrong, but I think the UI change is a mistake.

P. S. I am now working for an ISO (Independent Sales Organization) in 
the credit processing industry.  They are in need of a scheduling system 
and unfortunately vtiger doesn't meet the requirements for that, so I'm 
looking at egroupware for that but it doesn't have the CRM features 
vtiger does. :-/  Any suggestions would be appreciated.



More information about the vtigercrm-developers mailing list