Ticket #1332930 (Feature Requests)
drungrin at gmail.com
Thu Aug 10 20:18:31 CEST 2006
I dont think that saving the all the field data in one vcard string is
a good idea.
How about searching my contacts that live on some city, some info that
is in this vcard string?
It isnt good to add a field to each contact info that is available...
I think that can be created 2 tables, one with the contact info type
and one that has an 1-n relationship between the contacts table and
tis contact info type table, where u can put the info.
Then u can search freely withouth performance issues and store and
extends all the contact info without having too many empty fields.
2006/8/10, Eric Stadtherr <estadtherr at gmail.com>:
> Should rev306 be backed out then? It goes against this concept.
> On Thu, 10 Aug 2006 10:03:06 +0200, "Thomas Bruederli" wrote:
> 2006/8/9, Tobias 'tri' Richter :
> > Hi guys,
> > I found roundcubemail a few weeks ago and found it really great. I was a
> > time Horde-Imp User but roundecubemail is much faster, nicer and easier.
> > the first thing i miss was a "better" adressbook.
> > I talked about this to thomas and he pointed me to the Ticket #1332930.
> > Then i have included a lot fields into the database table and made this
> > available under the adressbook. The fields i added now are all fields with
> > needed for vcard 2.1 support (export and import can then be done easier).
> > the problem now is, that the "right side" for each contact is a long list
> > maybe not everybody needs the field "tel work 2" for example.
> user create and remove the fields he/she needs for the current address
> (like the Apple Address Book or Gmail does). All field data is then
> put together into once vCard string and saved in ONE database field. I
> don't like the idea of having 200 fields in the contacts table and
> adding one more field each week after somebody called for it.
> > i will put my updates tomorrow to svn - but then i have to think about a
> > and fast solution for users that they can change what fields they what to
> > for here contacts and which fields should be faded out. maybe this can be
> > like the folder settings under settings or maybe there is a better
> We should create a new branch for this and commit the changes there
> until we have a final solution. It seems to be a bigger task and I
> tend to have the trunk only for quick fixes and use branches for new
> feature implementations.
> > i hope you can follow me - my english is not the best ;) - you can see it
> > svn tomorrow.
More information about the Dev