…9561)

* web/forms: fix invalid date error for empty datetime-local inputs

Overview:

When a datetime-local input is empty, `valueAsNumber` returns `NaN` and `new Date("")` creates an Invalid Date. Previously, form serialization passed these invalid dates to the API, which caused  "RangeError: Invalid time value" when `toISOString()` was called. Now empty datetime inputs correctly serialize to `null`.

Testing:

1. Go to Directory > Tokens and App passwords
2. Create or edit a token
3. Uncheck the "Expiring" checkbox
4. Save the token
5. Verify no error occurs and token is saved without expiry

Motivation:

Closes: #19558

* web: lint

…erry-pick #19561 to version-2025.12) (#19582)

web/forms: fix invalid date error for empty datetime-local inputs (#19561)

* web/forms: fix invalid date error for empty datetime-local inputs

Overview:

When a datetime-local input is empty, `valueAsNumber` returns `NaN` and `new Date("")` creates an Invalid Date. Previously, form serialization passed these invalid dates to the API, which caused  "RangeError: Invalid time value" when `toISOString()` was called. Now empty datetime inputs correctly serialize to `null`.

Testing:

1. Go to Directory > Tokens and App passwords
2. Create or edit a token
3. Uncheck the "Expiring" checkbox
4. Save the token
5. Verify no error occurs and token is saved without expiry

Motivation:

Closes: #19558

* web: lint

Co-authored-by: Dominic R <dominic@sdko.org>

…9561)

* web/forms: fix invalid date error for empty datetime-local inputs

Overview:

When a datetime-local input is empty, `valueAsNumber` returns `NaN` and `new Date("")` creates an Invalid Date. Previously, form serialization passed these invalid dates to the API, which caused  "RangeError: Invalid time value" when `toISOString()` was called. Now empty datetime inputs correctly serialize to `null`.

Testing:

1. Go to Directory > Tokens and App passwords
2. Create or edit a token
3. Uncheck the "Expiring" checkbox
4. Save the token
5. Verify no error occurs and token is saved without expiry

Motivation:

Closes: #19558

* web: lint

We aim to fix
#19911 in the next patch
release, so this commit shouldn't include an API change, which is why we
do it a bit awkwardly. Additionally, `serializeForm` has no typechecking
for its return value (`return json as unknown as T`), and should be
refactored for type safety if at all possible.

There are at least two bugs we're solving in this commit:

1. Type checking fails on `serializeForm`, which results in
`expires: null` POSTed in a `UserServiceAccountRequest`, where it is not
allowed. The backend "correctly" returns a 400. For now we address this
by returning `undefined` from `serializeForm` on a `datetime-local`
input element when it is unset.

2. The schema allows for `expires: null` in `TokenModel`, but fails with
a 500 when that is actually sent. For now we address this with a `None`
check. (Note: this bug will not be encountered by the frontend after the
change from `null` to `undefined`, but it's still nice to fix.)

Both of these issues should eventually be solved by the backend handling
`ExpiringModel` in an `ExpiringModelSerializer` instead of the current
ad hoc way.

Introduced by #19561

core: fix datetime (de)?serialization

We aim to fix
#19911 in the next patch
release, so this commit shouldn't include an API change, which is why we
do it a bit awkwardly. Additionally, `serializeForm` has no typechecking
for its return value (`return json as unknown as T`), and should be
refactored for type safety if at all possible.

There are at least two bugs we're solving in this commit:

1. Type checking fails on `serializeForm`, which results in
`expires: null` POSTed in a `UserServiceAccountRequest`, where it is not
allowed. The backend "correctly" returns a 400. For now we address this
by returning `undefined` from `serializeForm` on a `datetime-local`
input element when it is unset.

2. The schema allows for `expires: null` in `TokenModel`, but fails with
a 500 when that is actually sent. For now we address this with a `None`
check. (Note: this bug will not be encountered by the frontend after the
change from `null` to `undefined`, but it's still nice to fix.)

Both of these issues should eventually be solved by the backend handling
`ExpiringModel` in an `ExpiringModelSerializer` instead of the current
ad hoc way.

Introduced by #19561

Co-authored-by: Simonyi Gergő <gergo@goauthentik.io>

core: fix datetime (de)?serialization

We aim to fix
#19911 in the next patch
release, so this commit shouldn't include an API change, which is why we
do it a bit awkwardly. Additionally, `serializeForm` has no typechecking
for its return value (`return json as unknown as T`), and should be
refactored for type safety if at all possible.

There are at least two bugs we're solving in this commit:

1. Type checking fails on `serializeForm`, which results in
`expires: null` POSTed in a `UserServiceAccountRequest`, where it is not
allowed. The backend "correctly" returns a 400. For now we address this
by returning `undefined` from `serializeForm` on a `datetime-local`
input element when it is unset.

2. The schema allows for `expires: null` in `TokenModel`, but fails with
a 500 when that is actually sent. For now we address this with a `None`
check. (Note: this bug will not be encountered by the frontend after the
change from `null` to `undefined`, but it's still nice to fix.)

Both of these issues should eventually be solved by the backend handling
`ExpiringModel` in an `ExpiringModelSerializer` instead of the current
ad hoc way.

Introduced by #19561

Co-authored-by: Simonyi Gergő <gergo@goauthentik.io>

…#19913 to version-2025.12) (#19941)

core: fix non-expiring service accounts and app passwords (#19913)

core: fix datetime (de)?serialization

We aim to fix
#19911 in the next patch
release, so this commit shouldn't include an API change, which is why we
do it a bit awkwardly. Additionally, `serializeForm` has no typechecking
for its return value (`return json as unknown as T`), and should be
refactored for type safety if at all possible.

There are at least two bugs we're solving in this commit:

1. Type checking fails on `serializeForm`, which results in
`expires: null` POSTed in a `UserServiceAccountRequest`, where it is not
allowed. The backend "correctly" returns a 400. For now we address this
by returning `undefined` from `serializeForm` on a `datetime-local`
input element when it is unset.

2. The schema allows for `expires: null` in `TokenModel`, but fails with
a 500 when that is actually sent. For now we address this with a `None`
check. (Note: this bug will not be encountered by the frontend after the
change from `null` to `undefined`, but it's still nice to fix.)

Both of these issues should eventually be solved by the backend handling
`ExpiringModel` in an `ExpiringModelSerializer` instead of the current
ad hoc way.

Introduced by #19561

Co-authored-by: Dominic R <dominic@sdko.org>
Co-authored-by: Simonyi Gergő <gergo@goauthentik.io>

…9561)

* web/forms: fix invalid date error for empty datetime-local inputs

Overview:

When a datetime-local input is empty, `valueAsNumber` returns `NaN` and `new Date("")` creates an Invalid Date. Previously, form serialization passed these invalid dates to the API, which caused  "RangeError: Invalid time value" when `toISOString()` was called. Now empty datetime inputs correctly serialize to `null`.

Testing:

1. Go to Directory > Tokens and App passwords
2. Create or edit a token
3. Uncheck the "Expiring" checkbox
4. Save the token
5. Verify no error occurs and token is saved without expiry

Motivation:

Closes: #19558

* web: lint