Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Jump to navigation
Jump to search
Looking at the full application import routines and the four-step forms for importing leads, it was clear that there was a lot of machinery that I didn't need or want to get involved with to simply import records. I decided to go back to the SOAP example and write a scipt to read the exercise data and create full records for the 50 provided leads.
"Import Step 2: Upload Export File" is Soap examples seem to have changed with the addition of a confusing title version number, so you must be careful about what example you use, and generally rely on the second step of source to be the "Import Contacts" wizard. It could read "Import Step 2: Specify Data File to load"definitive source ;-)
interim draft
</source>
resolved the include errors
The instructions also fail to mention that the application wants to create a .htaccess file (which doesn't exist in the distribution and would not necessarily be writable to the web user. As a failsafe, the information is printed to the screen in the installer. However it doesn't properly display (lacking newline characters) which would make the content suitable for copy and paste into the file. I found the source which generates the .htaccess content, and used that. An alternative is to simply touch and chmod a .htaccess file prior to running the installer.
== Ideas on How to do the import ==
=== Existing Work ===
=== Use the Source Luke ===
My second instinct was to look at the source. Answers are always found in the source, with the caveat that it can be confusing and/or time-consuming to find those answers.
Looking at the full application import routines and the four-step forms for importing leads, it seemed that there was a lot of machinery that I didn't need or want to get involved with to simply import records. For instance, why deal with all the form and UI handling when I looked simply needed to insert records into a database. This made me reconsider using the SOAP example to write a script. In essence, it would only need to read the exercise data and create full records for the 50 provided leads. From looking at the source code of the import routines, I noticed that the modules/Import/config.php file defined various types of data formats, and that the "Salesforce" one matched the needs I had for mapping source data to get our application contacts. <source lang="php"> Soap examples seemed # temp.php to have changed with show a concise view of the variables defined in the addition of a version numberconfig scriptdefine('sugarEntry', true);include ('./modules/Import/config.php');print "Defined variables: <br />\n<pre>"; print_r (get_defined_vars()); print "\n</pre>\n";# end temp.php# partial output: [salesforce_contacts_field_map] => Array ( [Salutation] => salutation [Description] => description [First Name] => first_name [Last Name] => last_name [Title] => title [Department] => department [Birthdate] => birthdate [Lead Source] => lead_source [Assistant] => assistant [Asst. Phone] => assistant_phone [Contact ID] => id [Mailing Street] => primary_address_street [Mailing Address Line1] => primary_address_street_2 [Mailing Address Line2] => primary_address_street_3 [Mailing Address Line3] => primary_address_street_4 [Mailing City] => primary_address_city [Mailing State] => primary_address_state [Mailing Zip/Postal Code] => primary_address_postalcode [Mailing Country] => primary_address_country [Other Street] => alt_address_street [Other Address Line 1] => alt_address_street_2 [Other Address Line 2] => alt_address_street_3 [Other Address Line 3] => alt_address_street_4 [Other City] => alt_address_city [Other State] => alt_address_state [Other Zip/Postal Code] => alt_address_postalcode [Other Country] => alt_address_country [Phone] => phone_work [Mobile] => phone_mobile [Home Phone] => phone_home [Other Phone] => phone_other [Fax] => phone_fax [Email] => email1 [Email Opt Out] => email_opt_out [Do Not Call] => do_not_call [Account Name] => account_name [Account ID] => account_id ) [salesforce_accounts_field_map] => Array ( [Account Name] => name [Annual Revenue] => annual_revenue [Type] => account_type [Ticker Symbol] => ticker_symbol [Rating] => rating [Industry] => industry [SIC Code] => sic_code [Ownership] => ownership [Employees] => employees [Description] => description [Account ID] => id [Billing Street] => billing_address_street [Billing Address Line1] => billing_address_street_2 [Billing Address Line2] => billing_address_street_3 [Billing City] => billing_address_city [Billing State] => billing_address_state [Billing Zip/Postal Code] => billing_address_postalcode [Billing Country] => billing_address_country [Shipping Street] => shipping_address_street [Shipping Address Line1] => shipping_address_street_2 [Shipping Address Line2] => shipping_address_street_3 [Shipping City] => shipping_address_city [Shipping State] => shipping_address_state [Shipping Zip/Postal Code] => shipping_address_postalcode [Shipping Country] => shipping_address_country [Phone] => phone_office [Fax] => phone_fax [Website] => website )</source>
== Some Issues discovered ==
"Import Step 2: Upload Export File" is a confusing title on the second step of the "Import Contacts" wizard. It could read "Import Step 2: Specify Data File to load"
Typographical bug: I saw that the term "custom_delimeted" is used in a self-contained way in
./modules/Import/ImportStep2.php
This term is used elsewhere spelled correctly, and thus could potentially lead to a bug down the line.
The source is formatted differently, or practically not at all in some cases, due to various editors using different space and tab settings, even across different Operating Systems which leads to different line endings. PHPBeautifier used in a commit hook would solve this in the repo. Coding standards and configuration files like vim modelines would solve this on the developer desktop.
