LDAP Feeds module doesn't import LDAP attribute into taxonomy term [#1777952]

I made empty taxonomy vocabulary named "Departments".

In user profile i've created a new field named "Work department":
Label: Work department
Machine name: field_work_department
Field type: Term reference (related to "Departments" vocabulary).
Widget: Autocomplete term widget (tagging)

It works when I fill it from UI.

But if I try to import data via feeds importer which worked fine before I've added this new field it stops with the message:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?id=756&op=do StatusText: error ResponseText:

If I open page /import/ldap_data_to_user_fields/log I could see this message:

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'top management' for column 'field_work_department_tid' at row 1

Original item
array (
  'dn' => 'CN=John Doe,OU=ALL,OU=Users,OU=BELL,DC=domain,DC=company,DC=ru',
  'mail' => 'JDoe@company.ru',
  'samaccountname' => 'JDoe',
  'title' => 'Chief Executive Officer',
  'mobile' => '+7 (123) 456-7890',
  'department' => 'top management',
)

Entity
/* <some data cuted> */
 'field_work_department' => 
  array (
    'und' => 
    array (
      0 => 
      array (
        'tid' => 'top management',
      ),
    ),
  ),
/* <some data cuted> */

As I see this code trying to write text value into integer key field "tid".

Additionally all taxonomy terms for "Departments" vocabulary during this import were created correctly.

Comments

Comment #1

trumanru commented 7 September 2012 at 13:37

Title:

LDAP User module doesn't import LDAP attribute into taxonomy term

» LDAP Feeds module doesn't import LDAP attribute into taxonomy term

Comment #2

johnbarclay commented 7 September 2012 at 13:49

Thanks for the detailed diagnosis.

Patch would be very welcome on this. The LDAP Feeds module hasn't gotten a lot of love lately and has no simpletest coverage; largely because of the indeterminate state of feeds roadmap and betas. #301678: More flexible verse formatting

Any work on ldap feeds to make it more functional will take the edge cases out of ldap user provisioning to Drupal and help keep the complexity of the code base and ui down.

Comment #3

trumanru commented 7 September 2012 at 17:55

LDAP User module have same error. If I configure mapping for LDAP field [department] into the "Field: Work department" wich is taxonomy term I couldn't log in any LDAP User cause i've got the error:

PDOException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'top managers' for column 'field_work_department_tid' at row 1: INSERT INTO {field_data_field_work_department} (entity_type, entity_id, revision_id, bundle, delta, language, field_work_department_tid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => user [:db_insert_placeholder_1] => 757 [:db_insert_placeholder_2] => 757 [:db_insert_placeholder_3] => user [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => top managers ) in field_sql_storage_field_storage_write() (line 448 of C:\www\portal\modules\field\modules\field_sql_storage\field_sql_storage.module).

I'm beginner in Drupal and PHP and I'm not ready to complete this job. I could help any expert who will solve this problem. And I could try to do it later if my current project which is depended on LDAP module will be OK.

Comment #3.0

trumanru commented 7 September 2012 at 17:55

Issue summary:

View changes

Correcting mistake in error report.

Comment #4

johnbarclay commented 12 September 2012 at 03:03

The logic is in ldap_user/LdapUserConf::entryToUserEdit() and only accounts for fields which have a very simple form (see code below)

The bug fix for this would be to look at the $field returned from $field = field_info_field($value_name) and see if it is of this simple form. If its not, don't attempt to add it to the $edit array. And fix the documentation to this effect in the UI.

After this additional fixes/exceptions can be added to accommodate different fields such as taxonomy terms. At some point it will make sense to make feeds an optional module and leverage its plugins for some of these mappings. Things like vocabularies get tricky because of hierarchy and mapping of term vs term id.

 if ($value_type == 'field') {
         // Field api field - first we get the field.
         $field = field_info_field($value_name);
         // Then the columns for the field in the schema.
         $columns = array_keys($field['columns']);
         // Then we convert the value into an array if it's scalar.
         $values = $field['cardinality'] == 1 ? array($value) : (array) $value;

         $items = array();
         // Loop over the values and set them in our $items array.
         foreach ($values as $delta => $value) {
           if (isset($value)) {
             // We set the first column value only, this is consistent with
             // the Entity Api (@see entity_metadata_field_property_set).
             $items[$delta][$columns[0]] = $value;
           }
         }
         // Add them to our edited item.
         $edit[$value_name][LANGUAGE_NONE] = $items;
       }