What causes "Failed to create custom field '%{name}': %{message}" in opf/openproject?

Read the %{message} portion of the error — it is the exact validation failure (e.g. 'Name has already been taken') and names the field via %{name}.

opf/openproject · error · RuntimeError

Failed to create custom field '%{name}': %{message}

Error message

Failed to create custom field '%{name}': %{message}

What it means

During a Jira import run, each new Jira custom field is created through CustomFields::CreateService (type WorkPackageCustomField with a format chosen by the builder). When the ServiceResult is not successful, the job raises the interpolated admin.jira.errors.custom_field_creation_failed message, embedding the service's own validation message. The import run aborts at that field.

Source

Thrown at app/workers/import/jira_import_projects_job/jira_import_custom_fields.rb:347

          end
          return existing_cf
        end
        create_custom_field(jira_field, builder)
      end

      def create_custom_field(jira_field, builder)
        name, field_format = builder.custom_field_settings
        params = {
          type: "WorkPackageCustomField",
          name:,
          field_format:,
          is_required: false,
          is_for_all: false,
          **builder.custom_field_parameters
        }
        service_call = CustomFields::CreateService.new(user: @system_user).call(**params)
        unless service_call.success?
          raise I18n.t(
            "admin.jira.errors.custom_field_creation_failed",
            name: jira_field.payload["name"],
            message: service_call.message
          )
        end

        custom_field = service_call.result
        create_reference!(op_leg: custom_field, jira_leg: jira_field, jira_import: @jira_import, uses_existing: false)
        builder.custom_field_post_processing(custom_field)
        custom_field
      end

      # Picks the context entry whose (projects, issuetypes) match the issue's project key and
      # issue type id. Falls back to the first context if none matches - which can happen when
      # editmeta did not see the field for this (project, issuetype) pair but the issue still
      # carries a value for it (e.g. the field was removed from the screen after the value was
      # set). Falling back keeps the value rather than dropping it silently.
      def find_context_for_issue(entry, jira_issue)

View on GitHub (pinned to d9742c43f3)

Solutions

Read the %{message} portion of the error — it is the exact validation failure (e.g. 'Name has already been taken') and names the field via %{name}.
If a name collides, rename either the existing OpenProject custom field or the Jira field, then Retry the run.
If the name is too long, shorten the Jira field label and re-run.
For a half-completed previous run, revert it first so stale references are cleaned up.

Example fix

# before
service_call = CustomFields::CreateService.new(user: @system_user).call(**params)

# after (skip when an equally-named field already exists)
existing = CustomField.find_by(name: params[:name])
service_call = existing ? ServiceResult.success(result: existing) : CustomFields::CreateService.new(user: @system_user).call(**params)

Defensive patterns

Strategy: try-catch

Validate before calling

if CustomField.exists?(name: params[:name])
  Rails.logger.warn "Skipping existing custom field #{params[:name]}"
end

Try / catch

begin
  create_custom_field(jira_field, builder)
rescue StandardError => e
  raise unless e.message.start_with?(I18n.t('admin.jira.errors.custom_field_creation_failed', name: '', message: ''))
  record_skipped_field(e.message)
end

Prevention

Diff Jira field names against existing custom field names before starting the run.
Make field creation idempotent: match on name and reuse instead of blindly creating.
Keep the underlying service message in logs — the nested validation text names the exact constraint.

When it happens

Trigger: A Jira field whose name is already taken by an existing OpenProject custom field, exceeds the name length limit, or whose derived field_format fails validation — e.g. importing twice, or a Jira field name longer than the local column limit.

Common situations: Re-running an import after a partial first run that already created some custom fields; very long Jira field names (custom field labels with prefixes); two Jira fields whose sanitized names collapse to the same custom field name.

Related errors

AI-assisted analysis of opf/openproject@d9742c43f3 (2026-08-21). Data as JSON: /api/errors/19c70db552c80ffa. Report an issue: GitHub.