Ok here are the steps!
I'm on a Mac/MAMP and I use PhpStorm
A. Get Drupal
composer create-project drupal/recommended-project:8.9.13 d8civicrm.local
composer config extra.enable-patching true
composer config minimum-stability dev
B. Get CiviCRM
composer require civicrm/civicrm-core:5.35.0 civicrm/civicrm-packages:5.35.0 civicrm/civicrm-...
The recommended/supported version is 7.x-5.x
If you're on 7.x-4.x (or below...) you are strongly encouraged to upgrade. The newer 7.x-5.x branch includes many bug fixes along with improvements in the code base, e.g. many direct database queries have been replaced by API calls.
Next week we will be going through the drupal.org webform-civicrm issue queue and ...
Ben's answer sounds like a really good extra tool for this. Just for the record other solutions include
using Tags and CMS User extension https://github.com/Skvare/com.skvare.cmsuser
Drupal Rules eg https://github.com/eileenmcnaughton/civicrm_entity/pull/273/files
Using Webform and Webform CiviCRM modules create a webform with the fields required for the user and their organisation to create the contact and organisation in CiviCRM.
Then create a WebformHandler to programmatically create the user using the postSave() function. The WebformHandler is a single php file that needs to be saved in a custom module folder as:
You will want to find out where your module lives -> determine whether it lives in /sites/all/modules or in /sites/default/modules
Download a copy of the latest 7.x-5.x from our drupal.org project page: https://www.drupal.org/project/webform_civicrm
Unpack that tar.gz
Then replace what you have in /sites/all/webform_civicrm or /sites/default/...
We recently did a fair bit of work on multiple multi-value fields and that issue is fixed in the latest and tested by a UK partner and his client:
Fixed in 8.x-5.x - secured with a test and backported to 7.x-5.x - so it will be fixed when we push next releases to drupal.org
If you think that’s awesome 🥳 - you can ...
I've just tested this and thankfully I wasn't able to recreate the issue.
In your settings for the 'Existing Contact' component, please could you check that the 'Enforce Permissions' checkbox is selected? It should be ticked by default. This should prevent viewing of other peoples' data.
Thank you to both of you (Karin and Pete) for your suggestions : I have solved the problem.
I have disabled Token and Entity Tokens Modules (and requested associated Modules)
... then reactivated :
The probem comes from the Advanced User Management Module : when it is enabled, most of the tokens cannot be browsed (among which the default proposed ones in the ...
Please see -> What is the recommended/supported version of Webform CiviCRM module for Drupal 7?
First step would be to move to the supported version for D7WFC -> 7.x-5.x
Your error message tells me you're on 7.x-4.x
Finally it is working!
Two where important:
Disable "Enforce Permissions" for the contact field in the webform config, filled with a default value.
Look out for the field "Update Existing Case" on the CiviCRM tab. It was set to a case status value, so it would change an existing case.
Many thanks to @AndyClark and @RayWright!
I dont see any thing on module page that it says not compatible with 7.67 and Civi 5.19. The minimum requirement for 5x is CiviCRM 5.12+ and you are on 5.19. So i dont see any reason why it wont support.
All the screenshots are super helpful. I think because you have set it to be a static contact but did not tell it which contact, you are seeing an issue. Can you place the ID number of the desired case manager in the Contact (Kontakt) field right below "Set default contact from: Specified Contact"?
To test that it's working, you might turn on ...
Unfortunately there is no such clone feature yet. We've had to park it for now as other outstanding bugs: re: existing contact element, and re: static/live options take precedence.
So I've just removed the Tip (for now) and have added a ToDo statement:
My solution to this isn't elegant, but it gets the job done. I simply added a little code with hook_webform_submission_insert that takes the original webform submission data and resubmits the essential details to a second webform as many times as the user bought tickets. That second webform serves as the official list of tickets sold and sends an email for ...
One option is to use https://www.drupal.org/project/webform_conditional_values with Webform-CiviCRM integration if the ID is known before submission. If it's not available until after submission, you'll need to write code. Erik suggests one way, you could also write a Drupal module to push it to Civi.
You will probably need to develop an action that can take that ID from the data coming into the action and set it. There is a standard action to update a custom field (Set Custom Field) but it will ask for a value and will not be able to pick up the value from the input just like that.
Developing your own action is documented here: https://docs.civicrm.org/...
"I'd like the existing contact name that's selected to be stored in the new contact records, in a custom field" ->
Quick solution and better from a data point of view -> use Relationships.
That way you can not only see who has nominated a child for a present but also get a list of all kids nominated by a certain contact.
You could try enabling 'Groups' on the Civi processing tab set to user select and then limit the options of groups on the Webform tab in the configuratation for the group component. Once that's done you can set the email to 'Value of "Group(s)'.
It sounds like perhaps you have webform_conditional module installed even though conditionals are part of webform module?
☝️This is the answer. If webform_conditional module is uninstalled properly it simply is impossible for that module to still be throwing error messages.
No Required Radios example:
Alternatively in CiviCRM -> Custom Fields -> If you wanted to specifically record the 'none' option simply add it as an Option (Add Option) and it will automatically appear on your webform as an option as well!
I have identified the problem.
This occurred only for the activities where the activity participant wasn't set. So it's all about contact record type in the civicrm_activity_contact table. The issue happens when you load the activity where you don't have the target specified (record_type_id = 3). If this happens the activity data loads, but the custom fields ...