Hi Coleman,

I want to expose an address, phone, and email of a specific location type and it's not working as expected. I'll use phone to illustrate this example, but it applies to email and address as well.

I started by exposing one phone field of location "Directory". Looking at the default value, it's bringing in the primary phone number of that contact even though the primary phone location isn't "Directory". Then when I submit the form, the primary phone location type is changed to "Directory". This made sense when I went and added a second phone field and the Phone 1 field was then denoted with "(PRIMARY)". So I hid the first Phone 1 field and changed the Phone Location to "User Select" as I'm not interested in exposing the Primary phone here. And for Phone 2, I exposed the Phone Number and selected the default location type of "Directory". Now, when I submit the form, a non-primary "Directory" phone is added to that contact's record. Makes sense. Here's where the issue comes in.

IF I have a contact with a primary phone of, say, "Work" and another phone of say, "Home", and NO "Directory" phone defined, that "Home" phone is filled in as the default phone on the webform for the "Directory" phone. I would expect if I define a "Directory" phone (apart from the primary phone) on the webform that it would default to the value of a "Directory" phone defined for that contact. And that it would only update and/or fill in a "Directory" phone, leaving all other phone values alone.

Is what I'm trying to do possible now? If so, how could I accomplish it? If not, is it something that could be possible?

Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

colemanw’s picture

Title: Address / Phone / Email Location Types » Location Type Matching
Category: bug » feature

I don't know that I'd call this a bug, just that the module isn't designed the way you need it right now.
The problem is I couldn't think of a way to have it both ways. Either phone 1 will be matched to primary, or else it will be matched by location and phone types. Option 1 was way easier to implement, so that's what I did. Option 2 leaves us with some tough questions, such as "if a phone of the specified type doesn't exist, but a phone of a different type does exist, should we autofill or not" and also "what if two phones of the specified type exist?" even more difficult: "if two phones exist and neither is an exact match, but one has the correct location type and the other has the correct phone type, which do we choose?"

jaymcgraw’s picture

Okay, not a bug and great questions. I'm not sure how to solve for these dilemmas in the framework as it is currently setup to define a set number of phone fields.

But stepping outside of that...

What's the effort to provide an option to display all phones on the contact's record and providing functionality for the contact to add/edit/remove as he/she pleases? With the possibility of requiring at least 1. Same with address and email. I'm guessing it's a major effort and would itself have it's tough questions.

colemanw’s picture

One pretty hard limit of the webform module is that it doesn't support dynamically generated fields. At least not natively. Probably some creative use of the component hooks could allow for that to change (i.e. define a new component type "ajax multi" which could display one phone field along with an "add new" button). That sounds complex for something like email (with 2 fields - email and location type), and super complex for something like address. Treating a whole set of fields as if they were one field will come with some tradeoffs, and will probably lose a lot of customizability.
Just some initial thoughts.

jaymcgraw’s picture

I figured it wouldn't be a simple answer. But an interesting answer nonetheless. Probably not the route to go down at this time without further defining the constraints and possible issues.

I was thinking about this last night and remembered Civi would have had to address the same questions you posed in Comment 1 when they built Profiles. Do you know how these are addressed with specific-location fields in a profile? I've never tried it. I've always just exposed the primary.

colemanw’s picture

I think it can match either on "is_primary" or on location type. Pretty sure it will not match on phone type.
So maybe that's a good way forward.
Of course, if you use this module the way I was expecting you to, this wouldn't be an issue ;)
(that is, expose the location type to the form and it will be auto-filled with the correct value)

JKingsnorth’s picture

Title: Location Type Matching » Location / Type matching
Version: 7.x-2.4 » 7.x-4.10

Hi, we've just come up against this issue in a slightly different way:

We have a webform that lets people update 3 link fields. We've forced the types on these to be (1) Facebook, (2) LinkedIn and (3) Twitter.

A user comes along and enters a URL in the (1) Facebook, and (3) Twitter fields, then it saves correctly, and their links appear in CiviCRM with the right type.

The next time the user looks at the form, however, the Facebook URL appears in the correct field, but the Twitter field appears in the second box, which we've forced to the type 'LinkedIn'.

This is because it just puts the 'first' link in the first box, and the 'second' link in the second box - regardless of type.

If they then save the form, without making any changes, the Twitter URL is saved with the 'LinkedIn' type, which is incorrect.

Likewise, if the 'first' link on their profile happens to be a personal website, it appears in the first field, regardless of the type set on the form. And if they enter new links then the old ones are overwritten.

With all this in mind, it would be good to have the option for type matching - though I can see this may not be all that straightforward.

JKingsnorth’s picture

FileSize
4.82 KB
5 KB

I've added a couple of screenshots to demonstrate. So the user enters this information:

before

The next time they visit the webform they see:

before

colemanw’s picture

Hey John, thanks for cleaning up the issue queue and docs!!!

This issue continues to be a thorn in the side of the project. Would be great to get it resolved but the above questions are still not easy to answer.

There is a workaround to your dilemma, which is to:
1) Expose the 3 "website type" fields to the webform
2) Change their widget type to "hidden" so the user doesn't see them
3) Give them the default values you want

This will result in the default values being saved for new contacts, but not changed for existing contacts.
Hmm, that still leaves the problem of the labels... ok it's not perfect.

JKingsnorth’s picture

Hi coleman - setting them as hidden unfortunately wouldn't work in our use case since we specifically want to provide 'Profile update' forms for existing users ;]

(I know there is the static HTML profile embed from Civi. But pasting static HTML into a page feels very wrong; and this module lets us do so much more besides.)

JKingsnorth’s picture

Title: Location / Type matching » Support for matching location / type fields is limited
Category: Feature request » Bug report

I think this is really a 'bug' in the expected behaviour of the module, so I'll mark it as such.

colemanw’s picture

There has been some progress made on this issue. @JKingsnorth are you able to test out this solution?

Pull-request: https://github.com/colemanw/webform_civicrm/pull/24
Patch: https://patch-diff.githubusercontent.com/raw/colemanw/webform_civicrm/pu...

colemanw’s picture

Status: Active » Fixed
rocxa’s picture

I have just tried the dev version of this and the location based fields partly work.

For example:
When a form has multiple websites with different locations, either by user select or fixed location type, the data that is displayed doesn't always match up correctly.

However, if the user puts the correct website with the correct type into the fields they are saved correctly.

Basically the data saves ok but then displays wrong each time. This also applies when some of the website fields are left blank. The data still saves ok but displays in a seemingly random order rather than the location types of each field.

JKingsnorth’s picture

Status: Fixed » Needs work

setting to needs work based on rocxa's feedback

rocxa’s picture

JKingsnorth’s picture

Status: Needs work » Needs review
colemanw’s picture

@JKingsnorth could you test out that patch and see if it works for you?

rocxa’s picture

mpaulson’s picture

Status: Needs review » Closed (outdated)

This issue was filed against a branch (7.x-4.x) that is no longer supported. We're sorry we did not get to work through it, but once you upgrade to 7.x-5.x and if the issue persists, please feel free to re-open.