8

I'd use SQL. Take a backup first, of course, and test on a non-production server. Then run: UPDATE civicrm_address ca JOIN civicrm_contact cc ON ca.contact_id = cc.id SET location_type_id = 3 WHERE location_type_id = 2 AND cc.contact_type = 'Organization';


5

I solved this using the Drupal modules CiviCRM Entity and Views Bulk Operations. This gave me a very powerful way to search, filter, and mass-modify the addresses in our database. Create a new view that shows CiviCRM Address entities and provides a page Add a Bulk Operations: CiviCRM Address field and configure it under "Selected bulk operations" to "...


3

The cheapest solution would be to combine "Home" and "Main" into one option that can be used for both individuals and organizations. Just have to come up with a word that has both meanings...


2

In my testing, for the deduping, it actual matches against any email address no matter what the location type is. The location type you select for email is for new contacts and what location type their email address will be imported into.


2

Frankly, CiviCRM core should disable the Home address location for Organizations, and the Work address location for Households.


2

The location type is mainly as a "safe" way for recording a billing address that may differ from a contact's home, work, or other addresses. If you make a transaction that records a contact's billing address, you can't reasonably assume that the address is the contact's primary address. (Maybe it's your home address, or maybe it's the billing department of ...


2

Let me think a bit on how I would tackle this. I suppose that if I was only interested in the work addresses of Steven and Thomas I would simply add the work address on the Individual contact level. If I am however interested in the employer/employee relationship as well I can see no other option than having each branch as an Organisation. I would probably ...


2

You can not restrict location types to specific contact types in core CiviCRM. Obviously you can develop and extension that does this.


2

I think billing location type is used incase of Online membership purchase or registering a event or making donation inshort on forms where payment processor is involved(Billing block). Disabling this might cause issue/problem during submit of such form. Cheers Pradeep


1

As Erikh said you cannot control the location type options through CiviCRM UI but you can restrict filter them using either buildForm or fieldOptions hook. If you are using drupal than you can use webform with conditional filtering to filter the options. HTH Pradeep


1

There is an extension here which includes email fields in profiles on the contribution page. The standard billing email address field is removed when an email field is found in profile. If the contact is logged in - this field defaults to the 'Billing' email, if set, otherwise it is set to 'primary'. When the contribution is confirmed the email address is ...


1

One solution is to create your own custom module/plugin to do what is required. Steps: Use hook_civicrm_postProcess hook for the target contribution page, you can give the contribution id or name in if condition. Use civicrm contact create api call to edit email address type.


1

I suspect this is the result of poor assumptions. When you configure an individual to use a shared address of an org, Civi creates an employer/employee relationship with that org -- which makes sense. But it also assumes that employer/employee relationship is the current employer for the individual, which may be too much of an assumption. In your ...


1

I am not sure if this answers your question, but if you do not have an added profile type to collect a mailing address, the CiviContribute form will automatically only provide a place to check or enter billing address only. If you add a profile type that collects their mailing address also, then CiviCRM will ask on the front-facing form via checkbox if the ...


1

If you're on Drupal you can do this via views (where you have full control over which field types you pull in). Here's a good example: Views Proximity Search on Latitude / Longitude


1

I have the same problem. I have some installations that work correctly and some that's don't work. I made this patch, it's not a nice patch, becasuse it's not applied in CRM_Contact_Form_Search_Builder, but temporally works https://github.com/rubofvil/civicrm-core/commit/facfa396891229eb914397eb4920e75b6abff4a2


1

For completeness, my comment probably should have been an answer… I think this is probably a bug. It doesn't matter if you create a new location type or use a pre-populated one. The sql has a column that doesn't exists and it's going against the wrong table. Here's the sql: SELECT DISTINCT UPPER(LEFT(contact_a.sort_name, 1)) as sort_name FROM ...


1

I suspect doing this in jQuery via a custom behavior template addition: https://civicrm.org/blogs/dave-greenberg/now-its-easier-add-custom-behaviors-templates is probably a lot lighter weight, than an extension


1

If the solution suggested by Coleman does not work, you will have to create a little extension that removes some of the options based on contact type in a buildForm hook? Or alternatively validates the selected location type against the contact type in a validateForm hook


1

The problem is, that civicrm_contact and civicrm_address cannot be accessed at the same time due to triggers involved. I solved that issue by searching the relevant contacts on the civicrm user interface and adding them to a new group (e.g. with group id = 111). Then, the above statement could be: update civicrm_address inner join civicrm_group_contact on ...


Only top voted, non community-wiki answers of a minimum length are eligible