I have finished a working prototype of the form-processor and action-provider extension. See my previous blog post for where the idea came from.
Below I will explain what you can do with this extension. Lets assume we have an external website where students can signup to volunteer in a summer program. When a student has signed up we want this data to be present in CiviCRM and the student added to the group student volunteers.
We then have a screen where we can enter the name, define the input fields (in our case email address)...Read more
On many occasions, clients have mentioned that the contact summary screen loses a lot of prime space to the communication preferences and demographics sections.
“Is there no way to collapse them by default like you can with custom data? They are rarely used but are needed”
They’re aware that demographics and communication preferences can be removed via the UI (/civicrm/admin/setting/preferences/display?reset=1)
This is a simple extension that collapses both the communication preferences and demographics sections by default on the summary page.
We’ve added a few fancy bits to the functionality which we’re sure you’ll enjoy…
Last month I made a proposal for a client to integrate CiviCRM with Outlook 365. This proposal was rejected because the client did not go for an e-mail migration to Outlook 365. So the need for this plugin was gone.
The plan was that this integration would do the following:
- all the contacts in CiviCRM exposed to the outlook address book
- all the groups and the group membership exposed as groups in the outlook address book
- above would be done with the restriction that you can only see the contacts and groups which you are allowed to see when you login into CiviCRM
- outlook address book is read only. Meaning that changes should be made in CiviCRM and become visible in outlook
I made a guesstimate that development including testing and documentation takes between 12-24 hours of development.
My own investment would be that I need probably 8-16 hours of learning before I can develop a plugin...
Last week we had a Sprint in the wonderful city of Brussels. This blog post is a recap of what I have been up to.
I started the sprint to work on a new extension the form processor. This idea came to my mind as I had a few clients at which I had to develop a custom api for data coming from their website (in those cases CiviCRM was separated from the website). And my idea was that I wanted to give system administrator and implementers a tool in which they could create those kind of API by themselves. So the form processor was born.
Below is a sketch of the screen of the form processor (click the image for a larger preview):
The form processor is designed so that the user first defines the...Read more
Aloha, everyone! As you all know, CiviCRM is shipped with a lot of useful report templates for each CiviCRM entities. You can use these templates to create difference report instances to interrogate your data.
However, if you are report geeks like us, you might sometimes find that the existing templates don’t quite give you the flexibility you need. There is the excellent extended reports extension which you should definitely check out here; but if you are trying to do something a bit more complex; or looking for a graphical output then your may still be exporting your data into Excel or Google sheets to do more analysis…
The CiviCRM Pivot Report extension intends to change all...Read more
We are thinking about creating a native CiviCRM extension Someone Else Pays.
In CiviCRM you could use the soft credits (with a new soft credit type) to register another contact pay for an event registration, a membership and in theory any contribution. Our customer Domus Medica is using that at the moment. We encounter some issues though. Some of the issues are possibly bugs but some are also because we think soft credits is originally not meant to cater for this. It was meant to cater for soft credits. So we prefer to create an extension rather than fix a few issues in a hackish way and then finding out we have some more.
At this point in time our thinking would be to:
- generate a new table (sep_contribution_payer) where the contribution_id and the paying contact_id are stored if there is a different payer
- add a new collapse window on the contribution forms (also membership and...
During the month of November, we made a concerted effort to stabilize the CiviCRM-Mosaico extension -- addressing several bugs, installation issues, missing features, and testing processes. I'm happy to announce a new beta releases of the Mosaico and FlexMailer extensions for CiviCRM. The updates include ~160 commits from ~15 contributors.
v2.0-beta3 has been made possible through the work of over a dozen people. Multiple contributions were provided by the maintainers (Deepak Srivastava of Veda and Tim Otten of CiviCRM) as well as the Compucorp theming team (Maged Adel, Mihael Mladenov, Mukesh Ram), Matthew Wire (MJW), and Samuel Vanhove (SymbioTIC). Additional contributions were provided by Anne Dru, David Snopek, Francesc Bassas, Jitendra Purohit, John Kingsnorth, Matthew Roberts, and Philipp Batroff. And, of course, all of this is built on the great upstream project, Void Labs' Mosaico.
(And I apologize if I've...Read more
With a clear roadmap towards improved CiviCRM experience, Agiliway team keeps aligning CiviCRM software capabilities with an end-user working environment. The newly released CiviCalendar extension is our most recent solution and an absolutely necessary stop. From now on CiviCRM users can easily visualize their daily, weekly and monthly activities within CiviCRM.
CiviCalendar is styled to resemble Microsoft Outlook Calendar. For visual distinction the list view is replaced with graphic calendar squares, while entries are shown in different colors. User-friendly interface and intuitive navigation make it a breeze for users to add items to the CRM calendar or view tasks...Read more
Today, Skvare has released a new version of CiviCRM Entity, 2.0-beta11. This release contains a new feature, an admin configuration page which allows site administrators to disable exposure of entity types to Drupal.
CiviCRM Entity is a Drupal module which exposed CiviCRM API entity types as native Drupal entity types, providing Views, Rules, Entity Reference field integration, and Drupal native pages and forms for each. It supports both CiviCRM 4.6 LTS and CiviCRM 4.7.
Previous versions of CiviCRM Entity allowed developers to control access to Drupal based pages and forms for entity types, but there was no way for administrators to control what entity types were available in Views, Rules, or Entity Reference fields. As CiviCRM Entity has evolved over the past 2 years, over 45 entity types have been supported, including all the major financial record types. There are cases where many of these entity...Read more