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';
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 "...
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.
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 ...
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 ...
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.
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.
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 ...
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.
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 ...
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 ...
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
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
I suspect doing this in jQuery via a custom behavior template addition:
is probably a lot lighter weight, than an extension
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
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