[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