iTop - IT Service Management & CMDB / Discussion / Customizing iTop: Sudden error with LDAP Data Collector (Field not writable)

bit of a late reply but other things had priority in our business.

I have 3 syncs set up because we have different ldap groups that should get different user profiles in iTop.

So I created 3 config files, one for each group.

I run the sync 3 times, each time with another config via cron

/usr/bin/php /opt/ldap-data-collector-1.2.3/exec.php >/dev/null 2>&1 && /usr/bin/php /opt/ldap-data-collector-1.2.3/exec.php --config_file=/opt/ldap-data-collector-1.2.3/conf/params.local.iso.xml >/dev/null 2>&1 && /usr/bin/php /opt/ldap-data-collector-1.2.3/exec.php --config_file=/opt/ldap-data-collector-1.2.3/conf/params.local.portal.xml

here is an example of one conf.xml

<parameters>
  <itop_url>xxx</itop_url>
  <itop_login>xxx</itop_login>
  <itop_password>xxx</itop_password>
  <contact_to_notify>xxx</contact_to_notify>
  <ldapuri>xxx</ldapuri>
  <ldapdn>DC=xxx,DC=local</ldapdn>
  <ldaplogin>xxx</ldaplogin>
  <ldappassword>xxx</ldappassword>



  <!-- console_log_level: level of logging to console (std output)
  -1 : none, nothing will be logged to the console
   0 : System wide emergency errors only (LOG_EMERG)
   1 : Alert errors (LOG_ALERT)
   2 : Critical errors (LOG_CRIT)
   3 : Application level errors (LOG_ERR)
   4 : Warnings
   5 : Notice
   6 : Information
   7 : Debug traces
   -->
  <console_log_level>6</console_log_level>

  <!--
    dateformat: logging date format
    Example: [Y-m-d H:i:s] => will produce a log like "[2020-04-29 14:36:16]    [Info]  ......"
  -->
  <console_log_dateformat>[Y-m-d H:i:s]</console_log_dateformat>

  <!-- syslog_log_level: level of logging to Syslog
  -1 : none, nothing will be logged to syslog
   0 : System wide emergency errors (LOG_EMERG)
   1 : Alert errors (LOG_ALERT)
   2 : Critical errors (LOG_CRIT)
   3 : Application level errors (LOG_ERR)
   4 : Warnings
   5 : Notice
   6 : Information
   7 : Debug traces
   -->
  <syslog_log_level>-1</syslog_log_level>

  <!-- data_path: location where to store the temporary data (.raw and .csv files).
  Make sure that you change this value if you run several instances of the collector
  from the same location (with different configuration files).
  You can use the placeholder %APPROOT% to build a path relative to the location of the collector itself
   -->
  <data_path>%APPROOT%/data/params.local.portal</data_path>

  <!-- Maximum number of elements to process in one iteration (for upload and synchro in iTop) -->
  <max_chunk_size>1000</max_chunk_size>
  <!-- Timeout for waiting for the execution of one data synchro task (in seconds) -->
  <itop_synchro_timeout>600</itop_synchro_timeout>
  <!-- Whether or not to stop when an error occurs during a synchronization -->
  <stop_on_synchro_error>no</stop_on_synchro_error>
  <!-- When using cUrl to connect to the iTop Webservices the cUrl options can be specified below
  The syntax is:
  <NAME_OF_THE_OPTION1>VALUE_OF_THE_OPTION1</NAME_OF_THE_OPTION1>
  <NAME_OF_THE_OPTION2>VALUE_OF_THE_OPTION2</NAME_OF_THE_OPTION2>
  etc...

  Where NAME_OF_THE_OPTIONx and VALUE_OF_THE_OPTIONx are either:
  - The numeric value of the option
  - or the string representation of the corresponding PHP "define" (case sensitive)

  The four examples below are equivalent:
   <CURLOPT_SSLVERSION>CURL_SSLVERSION_TLSv1_2</CURLOPT_SSLVERSION>
  or
   <CURLOPT_SSLVERSION>6</CURLOPT_SSLVERSION>
  or
   <32>CURL_SSLVERSION_TLSv1_2</32>
  or
   <32>6</32>

  Since in PHP we have:
  define ('CURLOPT_SSLVERSION', 32);
  define ('CURL_SSLVERSION_TLSv1_2', 6);

  Note: because the recommandation about which is the best SSL/TLS version
        to use varies over time (as security bugs are found in the procotols)
        it is BETTER NOT TO force any SSL/TLS version at all and let the
        system decide which version to use.

        However if the web server running iTop requires a specific TLS/SSL
        version you can use the configuration to force it anyway...
        but be prepared to revisit this setting regularly.
  -->
  <curl_options>
    <CURLOPT_SSL_VERIFYHOST>0</CURLOPT_SSL_VERIFYHOST>
    <CURLOPT_SSL_VERIFYPEER>1</CURLOPT_SSL_VERIFYPEER>
  </curl_options>

<!-- Parameters for Person synchronization -->
<ldappersonfilter>(&amp;(objectClass=user)(memberOf=CN=iTop-Persons,OU=xxx,OU=Groups,DC=xxx,DC=local))</ldappersonfilter>
<itop_group_pattern>/^CN=itop-(.*),OU=.*/</itop_group_pattern>
<person_fields>
        <!--  Mapping between LDAP fields and iTop Person's object fields -->
        <primary_key>samaccountname</primary_key>
        <name>sn</name>
        <first_name>givenname</first_name>
        <email>mail</email>
        <phone>telephonenumber</phone>
        <mobile_phone>mobile</mobile_phone>
        <function>title</function>
        <employee_number>employeenumber</employee_number>
</person_fields>
<person_defaults>
        <!--  Default values for iTop Person's object fields -->
        <org_id>xxx</org_id>
        <status>active</status>
</person_defaults>
-->
<!-- Parameters for User synchronization -->
<collect_person_only>no</collect_person_only>
<ldapuserfilter>(&amp;(objectClass=user)(memberOf=CN=iTop-Users-Portal,OU=xxx,OU=Groups,DC=xxx,DC=local))</ldapuserfilter>
<synchronize_profiles>no</synchronize_profiles>
<user_fields>
        <!--  Mapping between LDAP fields and iTop UserLDAP's object fields -->
        <primary_key>samaccountname</primary_key>
        <login>samaccountname</login>
        <contactid>mail</contactid>
</user_fields>
<user_defaults>
        <!--  Default values for iTop UserLDAP's object fields -->
        <profile>Portal user</profile>
</user_defaults>
<!--
        Set a non empty (and unique) prefix if you run several instances of the collector against the same iTop Server
        This is the recommended method to collect data from several LDAP servers. (assign a unique prefix to each "source" LDAP server)
        Note: prefix is defined here since json_placeholders (below) can only reference global parameters
-->
<prefix>portal</prefix>
<json_placeholders>
        <!-- For compatibility with the version 1.1.x of the collector, define the data table names as following:
        <prefix></prefix>
        <persons_data_table>synchro_data_PersonAD</persons_data_table>
        <users_data_table></users_data_table>
         -->
        <prefix>$prefix$</prefix>
        <persons_data_table>synchro_data_$prefix$ldap_persons</persons_data_table>
    <users_target_class>UserLDAP</users_target_class>
        <users_data_table>synchro_data_$prefix$ldap_users</users_data_table>
    <full_load_interval>604800</full_load_interval><!-- 7 days (in seconds): 7*24*60*60 -->
    <synchro_status>production</synchro_status>
    <!-- How to import the profiles in iTop. Possible values: write_if_empty | master_locked
    Use write_if_empty if you want the collector to initialize the profiles for each account but let you edit them in iTop after the initial creation of the user
    Use master_locked if you manage the profiles directly in LDAP and let the collector synchronize them in iTop
    -->
    <profile_list_update_policy>write_if_empty</profile_list_update_policy>
</json_placeholders>

All of the Data Sync Sources show up in iTop but all of them run into the error with 4 Persons (as seen in my post)

If I look at one person which can not be updated I see the data sync sources just the same as everybody else (see screenshot in attachment).
It even says it got updated recently but the sync throws the error that it could not be updated.