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:
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.
On the CiviCRM part of the webform, in the 'Contribution' section there is a field 'Payment Processor Mode' where you can set either 'Test Mode' or 'Live Transactions' (and save this, of course, not forgetting to reset both this and Stripe dashboard when going live).
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 ...
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!
Sounds like there are two issues: 1) resubmit the form & 2) have that submit hit civi.
First issue: go to the form -> then click on settings -> then check the appropriate options under form and submission tabs. You may be interested in the below one under the submission tab:
Allow users to duplicate previous submissions
Second issue: it depends on ...
CiviCRM Custom fields configured as Data Type = Date all get added to Webform build tab as:
Ah you're then retyping that to a Date List field in the UI?
Yep - I see the issue. This will require a code fix. This particular field mapping just doesn't exist yet.
I do like the idea ...
The fix was to delete the entry in the table 'Settings' for 'checksum_timeout' and then update the 'Misc' settings which recreated that table entry. I did test this idea first...! Now the 'Contact Checksum UI' has picked the timeout up OK so it's looking like there was something not right about that table entry - although I can't see any difference at all ...
If you are using a checksum from civimail, then I believe we have managed to 'daisy-chain' forms by enabling the checksum field and contact ID on form 1, and then use those as tokens in the path used after the submission so that info is passed through to form2 etc
EDIT I see my memory was slightly incorrect. Rather than putting the tokens in the Redirection ...
That's one of the problems with checksum links - it's just a link connected to a specific user and although you sent the link to the specified contact, there is no guarantee that it is actually that person using it. The options come down to hoping people read your instructions and answer correctly.
You can ask people not to forward the mail ("Please ...
The problem is having null in civicrm_line_item:price_field_id & price_field_value_id
If a donor has one historical contribution that is missing the price field id & price field value id, then you cannot access their contribution tab.
The fix is to fill in the missing fields, a couple of options:
LineItem Edit extension and do them one by one
Posted in Webform CiviCRM Drupal Issue queue:
Webform CiviCRM indeed has not been specific about price_field_id or
price_field_value_id in the past - b/c CiviCRM core has been 'fetching' these
automatically. When there is a ton of price_fields though (both visible and
hidden), the fetching may not produce the correct result or no result at ...
The limit of 12 is hard-coded in the webform_civicrm module. You can find the line here
The most crude way to change it is to edit the source code. You will lose this change the next time the webform_civicrm module on the site is ...
Another potential approach for webforms which I've used (in both Drupal 7 and Backdrop), is to adjust settings on the "Existing Contact" webform component for that contact.
In the "Contact Field Handling" section, you can configure it to lock the Contact Fields, Email, etc. if they contain data, leaving them open for editing if they are ...
Yes there is a bug here with it not having a 'no default' option. from memory you can do something like this. switch to static, untick the option that is beahving as 'default', save, then re-edit, set back to dynamic and resave. does that work for you?
Other things that may work depending on the component type
Open 'source' and in the YAML find in the ...
Here's a small Drupal 7 module that checks if the combination of contact id and checksum is valid. I wrote it 3 years ago when I had the same problem as you described.
You can find it here: https://github.com/AlainBenbassat/webformchecksumchecker
Re -> Tab with Table style are these Multi value custom fields? We recently fixed a bug re: such custom fields in WFC D8/D9 and backported it to D7. What versions are you using? Are you able to clone from git or pull in a patch?
PS Multi value custom fields do complicate things (like eg reporting) so it may be a better option to create a regular Custom ...
We just set that "Not You?" message using standard drupal message functions (in D7 and D8). A theme will typically display such messages in a separate region above the content region. What you can try is change the Region settings -> i.e. change it from in your case Help -> Secondary.
D8 example - using Olivero Theme: works well:
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 ...
In Drupal 8 Webform-CiviCRM, this should be easier. Create an element of type "Calculated Twig" and give it the same key name as the "Groups" field. Now you can use Twig calculations based on the rest of the form's values to fill in the Groups field as you like.
I added a case to the webform and passed the case1 id via the URL.
I made sure the Case Type was "User Select" so CiviCRM does not expect to have case roles added, except for the case client. This was critical. When I selected a case type, the activity kept getting added instead of updated.
I passed the case client CID as a hidden contact on the ...