A little while ago the team here at Compucorp wrote about Shoreditch, the first CiviCRM “theme’ extension. Over the past few months, we’ve been hard at work on a series of updates and changes ready for the theme’s release in a few weeks time! With much of the work on this first stage now completed we’re pulling back the curtain to give a peek at what’s in store.
We’ll be following up shortly with more technical details about what this means for developers and how to migrate to Shoreditch or start using the new Bootstrap styles (yay!) but in the meantime let’s take a little look!
Colours / Colors...
So, what’s changed? Well, the most obvious difference is the adoption of a new colour palette which significantly improves both the...Read more
At the end of this February Agiliway released the updated version of our Graphical CRM Calendar. Now CiviCRM extension contains a number of new cool features which make its use much easier and much more comfortable.
First of all, we updated CiviCalendar to support the latest version of CiviCRM.
Also, the functionality of the Calendar was significantly extended comparing to the original version of the extension which has been released a few months ago (you can find the information about the first version of CiviCalendar here). Additionally, we cleaned the code and fixed a couple of bugs.
Among the most important new features we should highlight the following:
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