CiviCRM v1.6 - CRM - CiviCRM Wiki

CiviCRM v1.6

Added by Donald A. Lobo , last edited by David Greenberg on Dec 02, 2006 (view change)

Release Summary for v1.6

These features and improvements have been implemented for the 1.6 release. View open (unresolved) 1.6 issues here. View details for completed 1.6 issues here. Please give us your feedback and suggestions for tne next release (v1.7) here.

Custom Data

CRM-1177 Allow custom data fields to be associated with specific activity types, contact sub-types, relationship types, contribution types and membership types. (For example, if you configure a custom activity type for "Field Visit" - you could define one or more custom fields to only appear for that activity type.)

Permissioning

First version of implementation for ACL Spec, primarily for dynamic contact groups

Batch Update

CRM-1213 Ability to update a group of contacts using a profile with multiple / same values

Ajax-based UI improvements

Framework Integration using Dojo
Auto-complete drop-down 'search' on contact name - used for quick search block
Mouseover retrieves info block widget. Use for context sensitive help. Use to show all Contact details from Selector table (mouseover contact record - info block w/ all details overlays). See Netflix implementation for example.

CiviMember and CiviContribute Improvements

CRM-1240 Support PayPal Standard with Instant Payment Notification (IPN) as a payment processor for CiviContribute/CiviMember
CRM-1249 Support for in dedication / in memory / in honor of type contributions
CRM-1244 Mark test-drive contributions and provide search interface to find them.
Support for Recurring Donations (via PaypPal Standard Subscriptions service)
Include custom data (from contribution page profiles) in Confirmation page, Thank-you page and Emailed Receipt.
Bug fixes and minor features added to the above based on community feedback

CiviMail Improvements

Update AMaViS to newest upstream. [CRM-1178]
Ability to to re-send a message to another group, or duplicate and change things like subject and send to another group. [CRM-1166]
[CRM-1168]
Send step 4 should show a preview of the message. [CRM-1169]
Ability to cancel a mailing through the UI [CRM-1170]
Ability to enter an email addresses for the test send. [CRM-1171]
Ability to identify a group to send the test message to. [CRM-1172]
Why is a header required for civimailings? what if i don't want one? [CRM-1173]
The default view of the mailing jobs list should be reverse chronological order. [CRM-1175]

Miscellaneous

CRM-1181 Reduce table bloat my migrating various configurable "enums" (e.g. Gender, Location Types...) to a single table (civicrm_option_value).
CRM-1159 Search by Open Activities (phone call, meeting, custom activities)
Search for contacts created or modified w/in a date range and/or by a certain user
When tagging contacts as a result of a search, you can only add one tag at a time, user should be able to add multiple tags; similarly user should be able to remove multiple tags
Progress bar for large imports.
CRM-1248 Add micro-format markup to addresses.
CRM-1246 Allow user to enter a company name when editing an individual record. The company name is automatically saved as an organization with an "employee of" relationship.
Move most configuration settings from civicrm.settings.php into the database and provide an Admin interface for controlling them. (Exceptions would include datasource and path settings needed to run the module.)

Comments Hide Comments

JoeMurray

Sep 01, 2006 06:09

CiviContribute:

- allow a contribution page to be duplicated, so that tweaks are easier

- perhaps make it possible to specify that several pages share a total contributions 'thermometer'. We need this to add together the contributions from A/B tests for the same campaign, but lots of other uses are conceivable.

JoeMurray

Sep 01, 2006 06:30

CiviContribute:

Don't require labels - if they are not present just use amount

Jeff Porter

Sep 02, 2006 02:47

Civicontribute:

Support for global variables that would be used on all contribution pages (e.g. company info, tax related info (TaxID, donation statement ("This donation is tax deductable to the extend allowed by law.....")
Support for use of custom variables in receipt emails (custom1, custom2, etc.)
Support for "event" field for contribution type (make source just say "Online" or "Offline")
Contribution dashboard that shows all thermometers by type (selectable) - e.g. thermometers for each event, or thermometers by source (online, offline), or by group (finding members that contributed that are in specific groups)

James Stewart

Sep 07, 2006 07:58

Is the decision to use dojo final?

Given that drupal 5.0 is going to integrate JQuery it would make developers' lives easier-~~and bandwidth requirements lighter~~-if civicrm also used jquery.

Donald A. Lobo

Sep 07, 2006 08:29

James:

for now yes, we've been integrating dojo toolkit v0.3.1 into CiviCRM quite nicely and have been very impressed with its widget approach and the amount of seperation and cleanliness between CiviCRM code and the ajax code. We dont know jquery very well to make a comparison against dojo, but dojo does have a pretty awesome and fast growing widget system

lobo

Jeff Porter

Sep 14, 2006 06:37

CiviContribute:

Add offline contributions capability (not to replace import), but a set of simple data entry screens to record contributions as they come in (our group gets 1-2 checks per week and would rather enter them directly)
Track the item (contribution amount) selected in the list (either that or prevent multiple options from having the same value). If that variable could be passed to the db and also put on the receipt: You selected "Bronze Level: $200", that would allow us to use contribution pages to sell various sponsorship levels that may have the same "cost"
Field in the db to mark a test transaction as such along with an option to find and/or clear all test transactions

Paul Hardwick

Sep 14, 2006 20:06

CiviContribute:

Another vote for - Support for additional transaction processors (authorize.net)
Another vote for - recurring payments
payments to go to one of a list of accounts. For example an organisation could default to a umbrella account, but allow chapters to send the money directly to their account. This could also allow an international organization to allow donations to go into the local chapters account in their local currency

JoeMurray

Sep 15, 2006 07:48

CiviContribute:

An AJAX based high-volume data entry system for off-line transaction data entry, with batch totals for each bunch of transactions.
+1 for sending payments to one of a list of accounts.

David Greenberg

Sep 15, 2006 08:27

Paul and Joe,
Please describe the "payments to one of a list of accounts" feature in more detail. Would you want to link a payment processor "account" to a CiviCRM contribution type (which can then be linked to a given online contribution page)? Would you need a single online contribution page to be linked to multiple (payment processor) accounts - with some user-selection action determining the account used? Or ...

...dave

Paul Hardwick

Sep 15, 2006 23:40

I want to think about the exact structure a bit more, but made my post to make sure discussion got started early enough so that it might make ver 1.6 but here is a first shot

I'll break my wish into two levels. The first would be for a single country ( in my case USA) the second for an international group(we're getting there)

Single country (my case is USA)
- single contribution page could choose a single payment processor with the money going to a single bank account. But during creation of that contribution page you would be able to choose from multiple payment processors and multiple bank accounts. In my case (so far) its the ability to choose a final bank account (from a list) that is important. As we grow, each chapter will have the option of opening their own bank account when they are large enough. As for payment processors I am hoping for the addition of Authorize.net since that is who we already use to process our CC transactions, but hopefully in the near future we will be getting a larger presence in Europe and Asia and we will need to be able to select a payment processor who operates in the appropriate local currency (Euros in Europe being our next concern)
- While each contribution page itself could probably be restricted to a single processor/bank account, we would like civiCRM to have access to multiple processors/bank accounts so we could choose the appropriate one when the page was created. In our case the page will usually associated with a specific project and have a single destination, but our site will have multiple pages each involving the own unique project, which may be run by different chapters and each chapter can have their own bank account and may choose a diff transaction processor than the Authorize.net which is used by the parent
international
- we would need additional processors who could handle the local currency, with Euros being our first concern. But our chapters may have their own country specific transaction processor that they use. Of course supporting each transaction processors interface is another question, but if we don't have to way to handle more than one, that won't matter
- of course Europe or Asia based chapters would have their own bank accounts, instead of using the global one, to avoid the overhead and cost of currency conversion, and what are probably onerous banking regulations for international transfers.
- So if we have a contribution page for the parent organisation, we would like a way for the donor to choose their location so that we could process their donation with the appropriate combo of currency/processor/bank account. civiCRM might make this choice based on their country code

I'd like to think about this some more and try filling in more details when I've had some sleep, but hopfully this gives you some idea of what we're seeking.

Paul

Neil Adair Sep 19, 2006 21:35		+1 for recurring payments, our processor of choice (Moneris) supports this.

Dave Jenkins

Sep 20, 2006 03:01

Duplicate matching for Organizations would be a good improvement. In 1.5, no dup matching appears to be done when adding Orgs at the UI. With Dup Match set to email, I can create an Organization at the UI whose email matches an existing Individual or Org. This is bad news if using profiles to allow Users to edit their records.

Better still, persuade the Drupal developers to drop the requirement that Users have unique emails - people/orgs often share email addresses in the real world, e.g. (a) couples, (b) a sole trader as Organization and as Individual - and introduce a Username field in CiviCRM to do the User <-> Contact link. But I'm not holding my breath on this one!

Regards and thanks for all the good work and support,

Dave J

Henry Bennett

Sep 24, 2006 11:26

CiviMember

Phase 1 Specifications has a Menu / User Interface Element to import users. This appears to be missing in the 1.5 release and makes the whole component useless to me without it. (looks damn good through!)
When assigning a new membership to an individual the join date is capped. Ie I can't set an individuals join date as being before 2003.

David Greenberg Nov 13, 2006 07:54		Membership import has been incorporated in v1.6. Would be great if you are able to grab the beta when it comes out mid-November and try it with your data!

Sean Larkin

Nov 09, 2006 16:15

Send Mail Activity:

Given that civimail is such a technical install, and that it requires php5, it would be nice to see some improvements done to the simple "send an email" action. I'm not sure how Kabissa set this up in http://wiki.civicrm.org/confluence/display/CRM/Kabissa+Spec+9+-+Mailings+and+Newsletters, but it would be great to be able to add a view simple user fields to the body of an email message sent to 10-50 recipients. HTML-formatting, integrating TinyMCE would also be nice.

Thanks for your consideration. I'm just a Drupal newbie, so I have not idea how much work it would be to integrate these suggestions.

Cheers,

Sean

David Greenberg Nov 13, 2006 08:05		Sean - We are moving toward support for templated email messages in the "send an email" interface. 1.6 will support this for membership renewal messages - and we will generalize this for 1.7. See http://issues.civicrm.org/jira/browse/CRM-1382 for some details of the 1.6 "progress".

Chris Mott

Nov 24, 2006 22:10

Another vote for recurring payments!

I'm assessing Drupal+CiviCRM for a new site, and recurring payments is a common part of the organization's current contribution model.

Donald A. Lobo

Nov 25, 2006 13:22

Chris:

Recurring payments via PayPal's recurring subscription model is part of the 1.6 feature set

lobo

Elin Waring

Dec 02, 2006 23:35

On the dev list I asked how to change to fiscal instead of calendar year for the contribution dashboard and Lobo told me:

CRM/Contribute/Page/DashBoard.php, function preProcess and tweak the
date construction there. Most likely the change u need is:

$yearDate = date('Y') . '0701000000';

which does seem to have worked. If this could be configurable that would be great--it makes it much easier for the development folks to see the lybnty and sybnty people.

Of course, in my dreams, we could see an annual total for each donor on the contribution tab.

Denis Clijsters

Dec 09, 2006 05:34

An improvemnt inthe printing labels would also be nice. Is this already plannend?

For sending snalilmails, i use a DYMO label printern. But due a bug in de fpdf library the first 2 label are always empty. This means, when i want to print 1 label, i have to select 3 contacts and then I can print the last label (the contact i was planning to print).