Re: [Phpgroupware-developers] I am interested in working on cdb

[Patrick J. Walsh]

River,

    I hope to start working on cdb myself later this month.  I would
certainly love some help coding help and will let you know what you can do
once I get a chance to go through my own design docs and lay out a roadmap.

..ghost of mr_e

----- Original Message -----
From: "River Hume" <address@hidden>
To: <address@hidden>
Sent: Friday, January 11, 2002 3:34 PM
Subject: [Phpgroupware-developers] I am interested in working on cdb


> Greetings,
>
> I have been lurking for a few months now, looking for a niche to jump
into.
> A good friend of mine and I worked extensively on the conceptual design of
> a client based contact manager with very similar concepts to those
> mentioned in the recently posted synopsis of cdb (where every person,
> company, task, etc is a separate object and can be linked in as many ways
> as you can dream up to any other object, and there are no limits to things
> like phone numbers, email addresses, etc) and even began to implement it
> (developed the classes and most of the GUI) before the client who wanted
it
> dropped us on our asses. So we have a gr8 concept, and a big mess of
> bug-laden VB code that hasn't even been looked at in a few years. I have
> fwd'ed him a snippet of this list, and am hoping to get him involved as
> well. He doesn't write any php, but I do, and he is unlikely to have time
> for much more than helping with  implementation design. I think he and I
> both would be able to contribute IMMENSELY to this module! I am just now
> beginning to study the design docs in the savanna CVS. Please let me know
> who if anyone is planning to pick up where mr_e left off; I'd like to be
in
> touch :)
>
> Peas!
> -River
>
> >--__--__--
> >
> >Message: 3
> >From: "Patrick J. Walsh" <address@hidden>
> >To: address@hidden
> >Subject: Re: The return of mr_e  <was: [Phpgroupware-developers] Release
> >schedule.>
> >Date: Wed, 9 Jan 2002 11:19:53 -0800
> >Reply-To: address@hidden
> >
> > > 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
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>