Ticket #1332930 (Feature Requests)
martin at martinm-76.dk
Fri Aug 11 15:18:19 CEST 2006
While on the subject of address book fields - I haven't checked the vCard 2.1 standard, but could we add a photo field? It would be optional to fill in of course, but it would be nice to have the option.
On Fri, 11 Aug 2006 13:12:13 +0200, Thomas Bruederli <roundcube at gmail.com> wrote:
> Tobias 'tri' Richter wrote:
>> if the rev306 patch doesn`t fit into the concept i'm sorry, i got it
> wrong. my thought was to have all vcard 2.1 fields in the contact table.
> i'm no longer sure about that but i thought that only these fields which i
> created in the contact database table are allowed in the vcard 2.1
> standard. So there is no need to have more then these fields in the
> database or otherwise you break the vcard 2.1 standard. There is also a
> newer vcard 3.0 standard but this standard isn't very common and there are
> only a few fields which are new.
>>> 2006/8/10, Eric Stadtherr <estadtherr at gmail.com>:
>>>> Should rev306 be backed out then? It goes against this concept.
>> no problem about that - my patch was only a idea to improve the
>> if there are other ideas or concepts it will be great.
>> to make the addressbook look better even with all vcard fields in the
> database, it can be a option to show only these fields which are filled.
> And then if you edit the contact there can be a new button somewhere to
> view all fields. If you then fill a field which wasn't shown before
> (because it wasn't filled), it is shown after you saved your changes for
> the processed contact.
> Mac or GMail users might already know what I'm talking out, others
> please see the attached image. I imagine a dynamic address edit form
> that lets the user create new input fields and address sections as
> he/she needs them.
> My first intension was to save all data "serialized" as a vCard or Lfid
> string in one single database field and unpack it when needed. But I
> also like the suggestion of Eric having a table holding all the vCard
> fields and values and meanwhile I'd prefer that solution.
> Once again, I hope you all understand my ideas about the design of the
> "new" address book. It's a bit more complex than just having one table
> and 50 fields to edit and that's also the reason why I haven't
> implemented it yet. It should be more RoundCube-like :-)
More information about the Dev