openapi: Say message_content_delete_limit_seconds won't be 0 anymore.

I think this is ensured by an assertion in
parse_message_content_delete_limit in zerver/lib/message.py:
  https://github.com/zulip/zulip/blob/b13bfa09c/zerver/lib/message.py#L1482
This commit is contained in:
Chris Bobbe 2021-11-01 16:26:13 -07:00 committed by Tim Abbott
parent 0c2e4eec20
commit cce27aa47d
2 changed files with 4 additions and 3 deletions

View File

@ -67,7 +67,8 @@ below features are supported.
* [`POST /register`](/api/register-queue), [`GET
/events`](/api/get-events): `message_content_delete_limit_seconds`
now represents no limit using `null`, instead of the integer 0.
now represents no limit using `null`, instead of the integer 0, and 0 is
no longer a possible value with any meaning.
* `PATCH /realm`: One now sets `message_content_delete_limit_seconds`
to no limit by passing the string `unlimited`, rather than the
integer 0.

View File

@ -3580,7 +3580,7 @@ paths:
with this organization's
[message deletion policy](/help/configure-message-editing-and-deletion).
A 'null' value means no limit: messages can be deleted
Will not be 0. A 'null' value means no limit: messages can be deleted
regardless of how long ago they were sent.
**Changes**: No limit was represented using the
@ -10807,7 +10807,7 @@ paths:
with this organization's
[message deletion policy](/help/configure-message-editing-and-deletion).
A 'null' value means no limit: messages can be deleted
Will not be 0. A 'null' value means no limit: messages can be deleted
regardless of how long ago they were sent.
**Changes**: No limit was represented using the