Closed michaelmcandrew closed 5 years ago
PS may or may not be related, but I am going to add a cheeky plug for a SE question on a similar topic: https://civicrm.stackexchange.com/questions/27361/what-is-the-purpose-of-contact-link-in-the-caldera-forms-activity-processor
@michaelmcandrew have you mapped the necessary fields for each Contact processor (First Name, Last Name, Email, etc.)?
If you haven't, that's likely the issue. The Contact processor won't create/update a contact in Civi if there's missing data :) and the Activity processor will fail to create an Activity if there's a missing Contact.
I've attached an example form (imortable as json
) that replicates your use case. It's zipped because github doesn't allow raw json files as attachments :)
@mecachisenros - thanks for the tip and the example and for you answer to my stack exchange question - I am understanding it better now :)
Just to explain my use case some more, on this particular form, my only interest in contact 1 is that they are the logged in person that submits the form. I don't want to collect any information about them. All of the fields I am collecting relate to contact 2.
I had presumed that because I had ticked the 'Auto populate contact data with CiviCRM data if user is logged in' field, that the id would get passed through regardless of the fields present but it seems that I do need at least one field from contact 1 present (though it can be any field, e.g. it worked with nick name for me).
Because I am not interested in collecting this data, I thought I would try using the Hidden Field type but for whatever reason this didn't work.
I feel like it should not be a requirement to have at least one field present from contact 1 for the auto populate to work and am going to investigate ways to get around that, unless you tell me it is a bad idea / there is a good reason that it is set up that way.
@michaelmcandrew got you, re 'it should not be a requirement to have at least one field present from contact 1' I see what you mean, I'm not sure if removing that requirement is the best approach at the moment, let me have a think about it as I have some features in mind regarding auto population along with some refactoring.
Thank you for reminding me of the hidden field auto population, that feature was removed by default in the last release, and it was on my todo list to add a setting to enable auto population on a per field basis, which is now done through the referenced commit.
So for now I suggest you go the hidden field path.
thanks @mecachisenros for adding that setting! Very helpful. I will check it out. I'm curious as to why it was removed by default. Is there a use case for that behaviour?
There were a couple of use cases where you would want a hard coded value for the hidden field but those would get overridden by Civi data at auto population/pre render stage.
ah yes - so you mean as a way to force an update of a field without the user being aware?
Yes, hidden fields (and any other field type) can be hidden/shown/loaded conditionally based on some other input, so you would force an update in Civi based on some user choice or other criteria.
got it - thanks :)
feel free to close :)
Not sure if this is a configuration issue or a bug, but I have contact 1 configured like this
and the activity configured like this ...
When I submit the form, I get errors along the lines of
Changing the source contact to a specific refererence fixes the issue.