fix(spec): resolve UserType name collision with inline User.type schema

[BinoyOza-okta]

Summary

Fixes a long-standing bug where okta.models.UserType was generated with only an id field, missing every other property (name, displayName, description, created, createdBy, default, lastUpdated, lastUpdatedBy, _links) that the UserType component schema defines in openapi/api.yaml.

Customer-reported: any deserialization of a /api/v1/meta/types/user/* response into UserType silently dropped every field except id.

Root cause

Two schemas in api.yaml compete for the same generated class name:

1. components/schemas/UserType (line 82944) — the full model.
2. User.type (line 80775) — an inline anonymous object with a single id property.

OpenAPI Generator 7.x auto-promotes inline object schemas into standalone models and names them <ParentSchema <PropertyName> in TitleCase. Parent = User, property = type → generated name = UserType, which collides with the real component. The inline {id}-only shape wins, shadowing the full schema.

Evidence (pre-fix okta/models/user_type.py):

• Class docstring is copied verbatim from the inline User.type description ("The user type that determines the schema for the user's profile..."), not the component schema.
• Only field: id: Optional[StrictStr] with description "The ID of the user type" — the inline schema's exact wording.

This is why no other model is affected — User.type is the only spot in the spec where an inline object's auto-derived name matches an existing component name.

Fix

Spec-side change in openapi/api.yaml:

• Add a new named component UserTypeRef that captures the {id}-only shape used by User.type.
• Replace the inline object on User.type with $ref: '#/components/schemas/serTypeRef'.

UserTypeRef:
  type: object
  description: The user type that determines the schema for the user's profile...
  properties:
    id:
      type: string
      description: The ID of the user type

# User schema
type:
  $ref: '#/components/schemas/UserTypeRef'

The on-wire JSON shape of User.type is unchanged (still { "id": "..." }), so this is backward-compatible for API consumers.

Regenerated artifacts

Ran openapi/generate.sh (OpenAPI Generator 7.7.0). Resulting changes:

File	Change
okta/models/user_type.py	Now carries the full component schema (all fields, _links)
okta/models/user_type_ref.py	New — {id}-only model used by User.type
okta/models/user.py	type field re-typed from UserType → UserTypeRef
okta/models/user_get_singleton.py	Same as above
okta/__init__.py, okta/models/__init__.py	Export UserTypeRef
docs/UserType.md	Regenerated with full field list
docs/UserTypeRef.md	New
docs/User.md, docs/UserGetSingleton.md	Reference UserTypeRef

Tests

Added tests/test_user_type.py (12 cases, all passing) to lock in the fix and guard against regression:

• Regression guard: asserts UserType declares the full component field set and UserTypeRef stays {id}-only.
• from_dict: hydrates all response fields (incl. datetime parsing on created/lastUpdated), nested _links → UserTypeLinks, None input, and missing-optional handling.
• Construction: enforces name/displayName as required; accepts both alias and Python-field-name kwargs.
• to_dict: verifies the generator's read-only exclusion behavior (id, created, createdBy, default, lastUpdated, lastUpdatedBy are omitted on serialization) and that _links serializes via nested to_dict().
• JSON roundtrip: from_json → to_json preserves writable fields.

Run:

pytest tests/test_user_type.py -v
# 12 passed

Breaking-change note

The Python-level type of User.type changes from UserType to UserTypeRef. Any user code that explicitly annotates or isinstance-checks User.type against UserType will need to switch to UserTypeRef. Runtime/JSON behavior is unchanged.

Checklist

• Spec fix in openapi/api.yaml
• SDK regenerated via openapi/generate.sh
• New regression test added
• All new/regenerated files reviewed for correctness
• Docs regenerated

---

Fixes

• Fixes UserType response model discards all fields except id #535
• Fixes Fix UserType response fields #552