Important: Imported telephone records use a stable identifier 

Description 

The import identifier of a synchronized phone-number record used to be built from its type, so it read phone:fe_users:<uid> for a telephone number. That made the identity of the record depend on a value that is now configurable, and a reconfiguration would have created a second record instead of updating the first one.

The identifier is now built from the source field of fe_users and never from the type:

  • telephone numbers: telephone:fe_users:<uid> (changed)
  • fax numbers: fax:fe_users:<uid> (unchanged)

The record is matched on that identifier alone. A record still carrying the legacy phone:fe_users:<uid> is recognized and renamed in one step. Where its type is still the unselectable phone, it is retyped in the same step. Where a contract carries both a legacy and a canonical record, the canonical one wins and the legacy one is left untouched, because its provenance cannot be established safely.

Impact 

Two stored values change for records the synchronization writes: import_identifier for telephone records, and type wherever it still held phone or fax and that value is not selectable on the installation. Anything outside this extension that keys on phone:fe_users:<uid> has to be adjusted.

No upgrade wizard is shipped, deliberately. Existing records are repaired by the next academic:updateprofiles run, the same command that wrote them, and that run is what the affected installations already schedule. A bulk migration would have to decide what the synchronization deliberately refuses to decide: which of two colliding records is the real one, whether soft-deleted and workspace rows take part, and what to write where the configured type is not selectable.

Six cases are consequently not repaired by a synchronization run, and an installation that needs them corrected has to act deliberately:

  • profiles carrying skip_sync = 1
  • frontend users that are deleted
  • profiles whose tx_academicpersons_feuser_mm relation was removed
  • records on page ids excluded by the configured --include-pids or --exclude-pids
  • installations that ran an import once and never run it again
  • records whose fe_users.telephone has since been emptied, which the synchronization removes rather than repairs

Affected Installations 

Every installation that imports profiles from frontend users with academic:createprofiles or academic:updateprofiles .