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.
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:
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.
CiviCooP and Systopia and Palasthotel have been working together on CiviProxy and CiviProxy. This blog is a round up of what we have achieved in the last couple of days. The first thing we have achieved is that we had fun and a very good work atmosphere. We made long days and made lots of progress.
What are CiviProxy and CiviMcRestFace?
This year we had a sprint after CiviCon Cologne. So far I have only been to a sprint in Edale UK. The Germans copied everything from that sprint, remote location with hardly any internet. But with Germans you know it is done well. So the internet was faster (but still slow). The remote location had a bbq place, swimming pool and sauna.
Thursday 23th and Friday 24th of March we are having a mini-sprint in the Ede (NL) in which we will fix CiviCRM bugs. We are with four of us already (Erik Hommel, Alain Benbassat, Klaas Eikelboom and me) so it is going to be fun! That is the main reason and the other reason is that we want to contribute to CiviCRM Core.
Our plan is to have two days for fixing CiviCRM bugs once in the month or once in the two months. But at least regularly and fitting to our busy schedule.
So if you are in the neighborhood we want to invite you for joining us so it going to be more fun.
In this blog I want to explain the round up we have done around the refactoring of the acl_contact_cache. In the previous sprints we discovered that a lot of the performance was slowed down by the way the acl_contact_cache was used (or rather not used at all). See also the previous blog post: https://civicrm.org/blog/jaapjansma/the-quest-for-performance-improvements-5th-sprint
The last two days we spent another sprint at socialist party to improve performance. And again we used a guy with database knowledge to analyze our queries. We have optimized a few things so far one of the major areas to improve next was the ACL part of queries. That is the part of the query to decide which contacts you are allowed to see. So at the socialist party they have local chapter administrator who are only allowed to see the active members in their local area.
Last week we had a fourth sprint to improve CiviCRM performance at the socialist party.
During this sprint we started with looking at why the screen for adding and editing memberships loaded slow. The issue reported was that it took some time before the end date field jumped from the right side of the screen to the middle of the screen. It turned out that as long as the field was displayed at the right side the screen was still loading. Timing this gave a time of about 18 seconds before the screen was fully loaded.
We discovered a few causes: