phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The return of mr_e <was: [Phpgroupware-developers] Release schedule


From: Patrick J. Walsh
Subject: Re: The return of mr_e <was: [Phpgroupware-developers] Release schedule.>
Date: Wed, 9 Jan 2002 11:19:53 -0800

> I am quite interested in this contact manager. Is the design document
> available anywhere?

    Sure, in CVS checkout the cdb module and look in the doc directory.
There are several files to look at.  Or just go here:
http://savannah.gnu.org/cgi-bin/viewcvs/phpgroupware/cdb/.

..ghost of mr_e

PS - Below is an excerpt from the cdb.sql-README.txt file which contains
some of the design goals.  There are a couple of goals missing from the
document, such as the ability to store contacts in LDAP or MYSQL, provide
for groupings of extended information, such as purchase histories and what
not, and so forth.  One of the biggest things is having organizations and
contacts have their own records and then creating associations between them.
So you can see everyone associated with an organization or all the
organizations that a person is associated with.

Design Goals
------------
  There are a number of situations where normal contact management
databases fall short and a select few situations where Outlook falls
short.

  Imagine the contact database of a Certified Public Accountant.  Such a
database would be filled with clients, attorneys, other cpa's, business
contacts, companies, trusts, personal contacts and so forth.  Many of
these people could fall into multiple categories: an attorney and a
client, for instance.  This brings me to the first design goal:

    1) Categorization of contacts where one contact may be in any number
       of categories.

  Most addressbooks allow for a person to have a home and work address
and home and work telephone numbers.  Unfortunately this can leave a
large number of phone numbers for the Notes section.  Consider the CPA's
rich clients who have multiple homes, perhaps multiple office locations,
a pager, a cell phone, a private line, a normal line, etc.  Don't laugh,
I have a good six telephone numbers myself and I have contacts who have
more than that!  This brings me to the second design goal:

    2) Allow for an unlimited number of phone numbers in which there are
       four primary numbers and any number of additional numbers.  Each
       number is associated with a phone category such as Business Phone,
       Business Pager, Business Fax, Home Phone, Home Fax, Vacation Home,
       and so forth -- and there can be any number of each of these.  The
       list of categories could be customized by the sysadmin.

       A similar system would be used for addresses with one marked as
       the primary mailing address for mail merge operations and such.

  Next, one often has a number of contacts in the same company.  For
instance, suppose our CPA uses a law firm, but several different
attorneys within the law firm for different areas of law.  Outlook and
most other contact databases force you to put the company information in
for each person.  This is a waste of time and space and is a potential
source of typos that could mess up filters for a particular company.
Further, a company can be a contact with further contacts within the
company.  This brings me to the third design goal:

    3) Create a system by which contacts can share company information.
       Company information includes the company name, main phone number,
       home page, notes, and id number.

       But lets not limit ourselves to companies -- let's call these
       organizations and let them be any legal entites: estates, trusts,
       companies and so forth.  In such cases the id number would be the
       federal id number used for taxes -- similar to an individual's
       social security number.  This is probably specific to CPA's.

       Any given contact can be associated with a number of
       organizations.  A person may be the executor of an estate, work
       for a company, and be a beneficiary of a trust.

  There is a need also for information that is specific to a particular
contact in conjunction with a particular organization.

    4) A contact may have an assistant's name, an assistant's phone
       number, a department name, a manager's name and so forth for
       each organization that a contact is associated with.

  There needs to be a framework for contacts who are also customers or
clients.  One would want to assign each of these people client or customer
id numbers for tracking billing histories, support histories, and so
forth.  But such data would be tracked in another database system.

    5) Each contact who is a customer/client would have a customer id,
       billing info, who they were referred by, and an account.  Further,
       organizations may also be customers/clients and as such they can
       also have customer id numbers, billing info, etc.

  Contact entries can store personal information to jog the memories of
forgettful people like me.

    6) Optionally store personal info such as hobbies, childrens' names,
       spouse's name, anniversary, etc.

    7) File As field for determining where to file a company or person --
       for instance, if a married friend has adopted her husband's name,
       but you can only remember her maiden name, you might have her last
       name properly listed, but still file her under her maiden name.

  There should be a mechanism for flagging and/or labelling contacts.
There are times when it becomes obvious that a contact's information is
out of date and you want someone to review the information.  Or you may
want to flag a contact for later followup.

    8) Each person can make their own set of status flags and these flags
       will act like Eudora labels.  When flagged, the contact row will
       be colored with the color of the flag. Each person could use this
       feature in their own way.  Sales people may want to label
       potential customers with different colors depending on their
       chance of making a sale.

    9) There will be a system wide list of follow-up flags that can be
       associated with a contact.  Such flags would be seen by anyone,
       in contrast to the user-specific labels above.  Example values
       that would add a colored flag to a column are:

              - Follow-up
              - For your information
              - Review
              - Call
              - Send E-mail
              - Send Letter
              - Arrange meeting

  Few contact management databases provide sufficient Internet
information.  There needs to be a framework for storing e-mail
addresses including personal and work e-mail, ftp, personal
home page, business home page, icq number and so forth.

    10) Use a table to store internet contact info.

    11) Provide a mechanism for storing a contact's spoken language
        so that correspondence is done in the correct language.



S




reply via email to

[Prev in Thread] Current Thread [Next in Thread]