ImportTechnicalAccountsFromCSVExecutor

Long Running Task (LRT) that bulk-creates or updates Technical Accounts in CzechIdM by reading a semicolon-separated CSV file. Each CSV row represents one technical account. The task maps configurable column names to entity fields, validates the whole row before it writes anything, supports dry-run mode, and never re-points an existing account to a different provisioning system.

• The task reads the attached CSV file line by line (first line = header).
• For each data row it looks up an existing Technical Account by the value in the identifier column (matched against code) scoped to the system named in systemcolumn. The same code may legally exist on different systems - the lookup returns only the account linked to the row's system, if any.
• Depending on whether the account exists and which behaviour flags are set, the account is created, updated or skipped.
• Before anything is written, the whole row is validated in one gate. Every problem found in the row is reported together and the row is aborted without a partial write.
• Optional columns assign identity and role guarantors, link the account to a provisioning system and associate it with a Technical Asset.
• All item-level results are written to the LRT task log.

Each of the column parameters below is the exact name of a column in the CSV header (case-sensitive). multivalueseparator is the exception - it is a value, not a column name.

read identifier from identifiercolumn
read system name from systemcolumn (if configured)
  |- find existing TechnicalAccount by code = identifier
  |    (scoped to the system from systemcolumn - see Code and Name Uniqueness Rules)
  |- NOT FOUND + cancreate = false   ->  log CSV_IMPORT_ACCOUNT_SKIPPED (EXCEPTION), stop
  |- FOUND + canoverwrite = false    ->  log CSV_IMPORT_ACCOUNT_SKIPPED (EXCEPTION), stop

validatePreSave - one gate, nothing is written yet
  |- new account: resolve system and mapping (mandatory), check the code is free on that system
  |- existing account: check the linked AccAccount against systemcolumn / mappingcolumn
  |- resolve every identity guarantor and every role guarantor
  |- resolve the technical asset by code, apply the canchangeta rule
  |- parse the disabled cell
  |- run the asset assignment check script for the resulting (asset, account) pair
  |- any problem  ->  all problems joined into one CSV_IMPORT_ACCOUNT_ERROR, row aborted

write
  |- existing account: tier / zone written to the linked AccAccount and saved FIRST
  |- save the technical account (the technical asset is already set on it)
  |- new account: create the AccAccount (uid = identifier) and the TechnicalAccountAccount link
  |- add identity and role guarantors

directidentitycolumn and guaranteerolecolumn can contain multiple values separated by the multi-value separator (default `|`). Whitespace around each value is trimmed.

Example cell value:

jnovak|pdvorak|mmaly

Each value is resolved independently, but a value that cannot be resolved does not get skipped - it fails the whole row together with every other problem found in it.

Every Technical Account is expected to have exactly one AccAccount. The link is maintained via the TechnicalAccountAccount join entity.

When cancreate = true and the identifier is not found:

• systemcolumn is mandatory. If it is not configured or the system is not found in CzechIdM, the row fails with CSV_IMPORT_ACCOUNT_ERROR.
• If mappingcolumn is configured, the named mapping must exist on the system and must be of type TECHNICAL_ACCOUNT PROVISIONING. Otherwise the row fails.
• If mappingcolumn is not configured, the system must have exactly one TECHNICAL_ACCOUNT PROVISIONING mapping. Zero or more than one also fails the row.
• Once system and mapping are validated, a new AccAccount is created (uid = identifier) and linked via TechnicalAccountAccount.

The system, mapping and uid of the linked AccAccount are never changed and no new AccAccount or link is created. The tier and zone of the linked AccAccount are written when the corresponding columns are configured.

The systemcolumn and mappingcolumn values are a hard consistency check: a mismatch fails the row.

Technical assets are looked up by their code (TechnicalAsset.code), not by the Name field. An asset code that cannot be resolved fails the row.

canchangeta does not switch the column off. The column is always read and the asset always resolved; the flag only gates a real change on an already existing account.

Whenever a row ends up with a technical asset, the pair (asset, target AccAccount) is validated by a configurable Groovy script through TechnicalAssetService.isAssetAssignable. The script is named by the private configuration property idm.sec.tech.accountAssetAssignment.checkScript.

# Script deciding whether a technical asset may be assigned to an account.
# Default: nothing is enforced out of the box.
idm.sec.tech.accountAssetAssignment.checkScript=techAccountAssetAssignmentAllowAll

• techAccountAssetAssignmentAllowAll - the shipped default, always returns true.
• techAccountAssetAssignmentZoneMatch - requires the asset zone and the AccAccount zone to match; an asset without a zone is always accepted.

The check is evaluated against the effective asset (the one from the CSV, or the one already assigned when the CSV does not change it, so it also runs on rows that do not mention an asset) and the target AccAccount, that is the account as it will look once the row's tier and zone are applied. When the script rejects the pair, the row fails with CSV_IMPORT_ACCOUNT_ERROR before anything is written.

• code is unique per system. The same code may exist on different systems - each combination (code, system) yields its own Technical Account.
• The lookup combines code with the system named in systemcolumn. An account linked to a different system is invisible to the lookup, so a new account is created for the row's system.
• The lookup degrades to code-only in three cases: systemcolumn is not configured, the cell is blank, or the system named in the cell does not exist in CzechIdM. Uniqueness is then not enforced either - there is no system context to validate against, so "orphan" accounts (those without an AccAccount link) are not constrained on code at all and several orphans with the same code may coexist.
• For a new account the task checks up front that the code is free on the target system and fails the row otherwise. The product-side processors (TechnicalAccountCodeCheckProcessor, TechnicalAccountAccountCodeCheckProcessor) are the second line of defence; on the import's create path only the latter can still raise TECHNICAL_ACCOUNT_ALREADY_EXISTS_ON_SYSTEM, when the link is saved.

• externalCode (FE label "Name") must be unique across all Technical Accounts in CzechIdM, regardless of which system the account is linked to.
• A blank namecolumn cell (resulting in an empty externalCode) skips this validation.
• Enforced by the framework in AbstractReadWriteDtoService.validateEntity. The conflict surfaces as DuplicateExternalCodeException at save time, which the task records on the item as CSV_IMPORT_ACCOUNT_ERROR.

The task supports CzechIdM's built-in dry-run flag. When dry-run is enabled:

• No Technical Accounts are created or updated.
• No guarantors are assigned.
• No AccAccounts or TechnicalAccountAccount links are created and no tier or zone is written.
• Rows that would be created or updated are logged with CSV_IMPORT_ACCOUNT_WOULD_BE_CREATED or CSV_IMPORT_ACCOUNT_WOULD_BE_UPDATED and state NOT_EXECUTED.
• Skipped and failing rows are logged exactly as in a real run, with state EXCEPTION - a dry run therefore reports the same failures a real run would hit, including a rejection by the assignment check script.
• Would-be operations are written to the application log at INFO level (prefix [DRY-RUN]).
• The task counter still increments, so the row count can be verified.

Only identifier and name columns - no system, guarantors or asset.

identifiercolumn;namecolumn
svc-api-gateway;API Gateway
svc-db-reader;DB Reader
svc-batch-runner;Batch Runner

Task configuration:

identifiercolumn;namecolumn;descriptioncolumn;validfromcolumn;validtillcolumn;systemcolumn;mappingcolumn;directidentitycolumn;guaranteerolecolumn;technicalassetcolumn
svc-ldap-reader;LDAP Reader;LDAP read-only service account;2024-01-01;;CMS AD - Users;AD users provisioning mapping tech.;jnovak|pdvorak;role-ldap-admin|role-infra-team;CORE-INFRA
svc-db-backup;DB Backup;Database backup service account;2024-01-01;2026-12-31;CMS AD - Users;AD users provisioning mapping tech.;mpolak;role-dba;DATABASES

Task configuration:

• ImportTechnicalAssetsFromCSVExecutor - the sibling task importing Technical Assets.