Group talk:Donor Transaction and Contact System

Got a question? Have an answer? This is the place to discuss Donor Transaction and Contact Systems.

Hi! So, how do we start things? What's the current plan? --Xavier Antoviaque, 14 dec. 2008

I think currently we are collecting interested people and names of existing projects in the genre. I have a specification started from some time ago, and I plan to add those notes to the page as a way to get that part of the discussion going. You could help by finding and listing more existing projects, or by starting to standardize the features and flaws lists for each so that we can more easily compare them. --johns 12:25, 16 December 2008 (EST)

Alright, I'll see if I can find the time to do that. Is there any specific template or a list of fields you would like to have for each entry? --Xavier Antoviaque, 31 dec. 2008

Not really; I think you can get a feel from what's already been put in the descriptions of projects that have been added, but things like language, license, home page, prominent examples of use, known limitations --johns 17:28, 5 January 2009 (EST)

Alright! I've asked Trevas to have a look at it, he should start working on it soon. --Xavier Antoviaque, 19 jan. 2009

I updated the current article to standardize the lists of donation/contact management software. There were two pieces of software that I removed from the list as it was when I started:

Rapport - no information is available on this one at all, so I removed it from the page.

GNU Calendula - http://savannah.gnu.org/projects/calendula - Since nothing was ever developed and this project hasn't seen any updated since 2004, I assume that this one never proceeded with development. I removed it from the list.

--Trevas, 21 Jan 2009

Export formats / APIs

Can we collect some information for each of these programs about what formats they can export and import data in, and what kind of APIs they provide? For example, I think that we may want to have a contact management system that does not handle financial transactions, but rather imports that information from another source (so that we know a particular person has made a donation). Or, we may have a separate shopping cart system, that needs to report back to the CRM that a person made a purchase. Thoughts? --johns 17:04, 2 April 2009 (EDT)

Specification

Is there a specification on what the required and/or preferred functionality is? --Leth 10:34, 25 May 2009 (UTC)

Large mailing capability

Could it be possible to design a system using controlled chain mailing? Instead of a traditional chain mailing, where each person sends to random persons, we could imagine that the recipient are all encrypted in the initial mail using different keys, and that each member that is selected to re-send the mail have one of the keys to decrypt the addresses of the people he/she must send it to (actually, I suppose that it would be better if the decryption-sending is automated). It could also be possible to check if everybody received the email by including a test mailbox at each stage of the propagation. That would be something like:

- 1st step: all the different keys are sent to the re-senders

- 2nd step: the main organisation sends the email to the 1st list of senders (lets say 10)

- 3rd step: each sender decrypt 10 email addresses from the email and sends the message to them, plus one confirmation message to the main organisation

- 4th step: same as above, but with different keys for each of the receivers

- and so on

Of course, I suppose that this is not perfect. Does anyone have an idea if it is possible, or if it has to be improved?

--Lionelb 17:38, 21 September 2009 (UTC)