This is a first blog post about how we build the team portal for Roparun.
But first what is Roparun? The Roparun is a relay race of over 500 kilometres from Paris and Hamburg to Rotterdam, where people in teams, take part in an athletic event to raise money for people with cancer. It’s also called an adventure for life. This is also clear from the motto, which for years has been: ‘Adding life to days, when days often can’t be added to life’.
So each year Roparun organizes this race and around 400 teams participate in the event. The first part of the project was to setup donation functionality and that is working right now.
The next part of the project is to create a new portal for team captains where they can manage their team data, (e.g. name of the team, start location and the individual team members). We have chosen to have this in a separate Drupal website.
In CiviCRM each team captain is registered as a participant to the Roparun event with the role team captain. The team captain can login into the portal as soon as he has been registered as a team captain and till the event is over.
This user sync module uses the CiviCRM api to create drupal user accounts. See screenshot below for the configuration.
What you can see is that we use a custom api to retrieve the team captains. This custom api returns the email, contact id and the team id of the team captain. We store the e-mail address as the username and at the email field at the user level.
As soon as a new team captain is registered a new user record is created and the team captain receives an e-mail with a link to create a password.
As soon as an existing team captain is removed from CiviCRM the user account is cancelled and the team captain receives an email indicating that his account is disabled.
We have also created a drupal module to store the team id at the drupal user record and use this team id in the view (see https://github.com/CiviCooP/roparun_team_portal)
So the first bit is done, meaning a team captains can log in. The next bit is to build the portal with Drupal Views and Webforms. The building blocks we are going to use for that is CiviMRF Webform, CiviMRF Views and at the CiviCRM site the form-processor. I will keep you posted on the developments of the next steps.
What is the major advantage of the new approach over using profile advanced settings to create a Drupal user at the time of profile submission? Is it that a customization to create the user captain role was undesireable for some reason, or the default UI of CiviCRM profiles for creating/updating contacts was not what you wanted?
The reason for this approach is that the portal is a different site than the site in which CiviCRM runs. In my understanding the profiles only works on the same site as civicrm.