So you want do something that isn't currently possible in CiviCRM. The first question to ask yourself is: Are you sure it isn't possible? CiviCRM is a sophisticated software package and much of its functionality isn't immediately obvious. It might be that CiviCRM can already do what you want it to.
A great way of finding out whether something is supported is by writing - and getting feedback on - a use case. A use case is a story that documents the experience of performing a specific task. When you write a use case, avoid technical or database specific language like "field" or "record". Instead, concentrate on your real-world objects and scenarios.
There are numerous ways to get feedback on your use case. Talk to other CiviCRM users, show them the use case and ask them how they would do it. Try talking to people in person, on the forum, or on IRC.
Be flexible in how you think about your organisations processes, and how you use CiviCRM functionality. Maybe what you want can be done but in a different way to how you imagined you would do it.If your use case isn't satisfied with current CiviCRM functionality, it might be time to start creating it.
CiviCRM is open source and you can freely modify the source code. If you or someone you know has the knowledge, there is nothing to stop you downloading the code, modifying it, and running the new code at your organisation with little or know communication with the CiviCRM community. However, there are a few reasons why working like this isn't a great idea. The more you communicate with the community the higher the chances of success for your project.
If you do change CiviCRM's source code, that is when it is most important to develop your code in co-ordination with the rest of the CiviCRM community.
If you don't, then you'll find upgrades become cumbersome as you'll have to individually check and rewrite any customisations. That can be non-trivial, especially if you don't know understand the significance of the changes in the newest version. It's easy to say that you won't need any new features - that CiviCRM is feature rich enough for you - but what happens when the community has implemented new features that your clients would like, or has solved the same problem you solved?
In contrast, if your changes are developed as part of the wider development process, the complex integration and testing work is done as part of the development process. And you'll benefit from the experience of the entire CiviCRM community in your developments.
Another reason for developing in co-ordination with the CiviCRM community is that the more interaction you have with the community, the more you'll understand CiviCRM, the better you will be at using it, and the more you can guide its development.
A clear and well thought out set of use cases for your organisation is a great starting point to developing new functionality, but you should go further and try to find a general solution that will be of use to many different organisations. Thinking more generally increases the likleyhood your ideas will be accepted into the core, and also helps you better understand your own needs. Disagreement and debate are a natural part of the planning process and will help ensure your functionality is implemented in the best possible way.
Consider going on a publicity drive on the CiviCRM blog or forums, or talking directly to others you think would find the functionality useful. The interest and support of other organisations using CiviCRM will help drive your project forward.
Also remember that the community is involved in a constant trade off between developing a product that 'can do everything' and ensuring the product is usable by everyone. Your very useful functionality might be seen as unecessary complexity for others. And even if the functionality can be turned on and off form a user perspective, it might still cause an extra layer of complexity 'under the hood'.
CiviCRM follows a regular development cycle. Major version increments (for example the change from 2.3 to 2.4) happen roughly two or three times a year. Minor revisions (e.g. from 2.3.2 to 2.3.3) happen as needed between releases. When developing code that is integrated into the core, you project will co-ordinate with this release cycle. Knowing when the major versions come out is useful when planning development projects. Check the CiviCRM web site for the release schedule.
1. API: http://wiki.civicrm.org/confluence/display/CRMDOC/API+Overview
2. Hooks: http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+hook+specification
3. Custom templates and CSS: http://wiki.civicrm.org/confluence/display/CRMDOC/Customize+Built-in,+Profile,+Contribution+and+Event+Registration+Screens
There has been error in communication with booki server. Not sure right now where is the problem.
You should refresh this page.