Managing data of party members and everything else related to political party. I've chosen CiviCRM because it is Open Source, it has many features and modules, it can be customized, it can be installed on any kind of servers or OSs, and it's powered by 3 major CMS systems. Yep, translation and localization were a major factor.
The CiviCRM community is a great place for support, to exchange ideas and to contribute back. Working with other developers or users has often allowed me to pool our resources together and lower our costs, while ensuring better quality since there were more people using it.
CiviCRM is an solid and feature-rich web based CRM that supports an organization's or non-profit's ability to service its members. In a recent implementation our client is using CiviCRM as an association management tool for memberships and event registrations. Associations are a HUGE area for growth in the CiviCRM market. The ability for an organization to own and control their own data via an open source platform is a liberating experience. Coupled with Drupal and/or Wordpress makes CiviCRM and ideal combination for ANY non-profit or association.
We produce custom civiCRM/Drupal solutions for professional organizations and societies to satisfy their membership management needs. In its standard configuration, civiCRM provides a great deal of functionality and its integration with Drupal is outstanding.
We are also active in extending civiCRM with custom extension modules which are in development at our Github account(https://github.com/awasson)
AustLII is the leader in the free access to law movement and has a philospophical bias towards open source systems. After investigating all the other possible major alternatives it seemed logical to turn to CiviCRM. We have software developer resources, and though it is not core business, we may be able to direct some of these resources towards improving CiviCRM for the community.
I have used Civi in past jobs, and I often recommend it to clients and organizations that I volunteer with. So often it's the most affordable and user-friendly way to track organizational contacts and related activities.
Submitted by jbertolacci on August 10, 2010 - 16:49
Being able to efficiently identify and merge duplicate contacts and related data is be an important -- and often time-consuming -- task for organizations getting data from multiple sources. The current CiviCRM dedupe and merge process does not scale well beyond a moderate number of contacts and consequently there has been dicussion on the forums and IRC about optimizing the dedupe and merge code in CiviCRM.
Submitted by Deepak.Srivastava on July 22, 2010 - 02:53
A school needed an online admission application process to be developed and integrated with CiviSchool. The application form is a different workflow from the online family forms. Web Access helped convert this idea to working application as part of the CiviSchool Project. I have been working with Web Access on this project and we have completed most of it. Now seemed to be a good time to let everyone know about what we have done so far. Here is how the admission workflow is -
Parent account setup :
A parent goes to the school site and uses a civicrm registration profile to create an account and enters the site. The account automatically gets assigned a "Applicant Parent" subtype.
Filling admission application forms :
From the dashboard parent fills admission application forms for an applicant (child). Parent can apply for 1 or more applicants. All applicants are assigned a "Applicant" subtype.
Submitting a payment :
Depending on whether financial aid is taken or not, parent submits a payment for an applicant. The payment is done via contribution page with contribution type - "Application Fee". Since parent is the one making the payment, to keep track of which applicant the payment is being done for, an extra argument is passed to the payment/contribution url. We using a hook to make all the checks and link the payment to the applicant.
Scheduling appointments :
Once the application is complete and payment is made (if needed), parent can schedule a child visit or a parent interview. A school tour could be booked at any stage of the process.
While doing a deployment for a large organization, our good friends at Rayogram hit upon a pretty severe export scalability issue. The primary export was failing for approx 40K rows. They contacted us to see if we can figure out whats happening and why. They first assumed that the big issue was using a custom feature (merge same address / merge household address) and wanted us to look at it and potentially optimize and fix the issue.
In general dealing with memory issues in PHP are not something i look forward to (it comes a close second to debugging core dumps in PHP). Basically you cannot afford to leak a lot of memory in every iteration. For the export, if you leak 10K for every iteration, u will need 400M for a 40K export not including any of the memory used before export was called. On my initial tracing of the code we were leaking between 15K of memory for every iteration. On my local labtop, i could process approx 5K contacts before running out of memory :(
It took me some time to get my head around the code and figure out what the potential problems were. I first eliminated our good friend DB_DataObject (which has a tendency to store things in a static global variables). I also ensured that we were free'ing various objects as soon as possible. Spent a few hours on this and realized that i was not making any significant progress.
Relationship are a natural way of storing relations between contacts. However, it doesn't work so well if you have several hundreds of related contacts as the realationship tab becomes unreadable quite quickly.
One of our client needed to associate each individual in their base to a local branch (we implemented a nice geo lookup based on the postal code to identify the local branch, but that's another story). It means that each local branch has 1000th of individuals. This could happen in other situations, for instance to keep a relationship between a "main teacher" and each pupil or who is the latest volunteer that contacted each person in a GOTV/ Canvassing campaign...
We've been hard at work implementing an online set of forms to collect family information for the school module. This is one of our final projects for the year and eliminates the tedious summer ritual for the admin staff of sending paper forms to the 200 school families and for the parent to fill out the same information every year. This also saves the admin staff from entering that same information into the SIS
We've built this work on the parent portal that we launched late last year. Parents can update information on themselves and their children anytime via their drupal account. The form is composed of 5 sub-forms:
Household Information: Name, Email, Phone and Address of the household. We currently support 2 household and 4 contacts. These are stored as CiviCRM contacts with a relationship link of type Parent / Child to the student. We created a custom group to store which household a parent belonged to. We did not use CiviCRM's household functionality.
I am writing this post to take community feedback on porting CiviCRM to PostgreSQL, the best way to do it, and to team up with any possible members willing to contribute to this effort. Here are my efforts until now. I have not been able to make it 'all' work on PostgreSQL, but certainly to a degree where I can see light at the end of the long tunnel. I am linking 3 PostgreSQL compatible files here:
structure.sql - this has the columns, primary keys, indexes, unique constraints
data.sql - this is the sample data included with CiviCRM
I am working on an import guide to help organizations match fields to CiviCRM's standard fieldsets. I noticed that the existing ERDs are pretty outdated. The new database schema is pretty large for one map so I decided to create a map for contacts.
As you have already read in the previous blog posts, one of the outcomes of the translation sprint is the fact that we’re switching our translation server to a new tool, Transifex.
We decided to go with Transifex for various reasons:
Transifex allows teams of people to collaborate on translations – this is not an issue when you have a single person working on a translation, but as soon as you have two or more contributors working remotely, it’s crucial to use a tool that streamlines the process and allows for easy and centralised communication,
the user hierarchy is simple, clean and seems to be efficient: project maintainers accept language maintainers who, in turn, accept language team members and coordinate given language’s development,
project maintainers can announce localisation-oriented things on the project’s page,
teams can have discussions on the per-language discussion boards,
the user interface for translations is better and easier to work with, and has the (dubious for some languages, but useful for others) ability to fetch Google Translate suggestions on-the-fly,
PO files can be locked for work in offline tools (like Poedit, Virtaal or others) and the locking is visible to other contributors.
It is said that optimizing too early is the root of all evil. However it is not so easy to say when is the right time.
Looking at CiviCRM performance there are a number of instances where even on medium sized installations search queries take a long time to execute.
One of the searches that caught my eye is the AJAX search at the top left in the menu bar.
Returning a maximum of ten entries from a medium sized database (~50k records) should take negligible time and on the CiviCRM test data this request was taking around 3 seconds (putting full load on server).