From 7.4 `roomID` is now required even if `channel` is passed in `chat.postMessage`.

[jadolg]

Description:

While testing the integration with v7.4.0, looks like roomID is now required even if channel is passed in chat.postMessage.

This change, if intentional, is not documented.

See here the discussion.

Steps to reproduce:

note: I'm going to use the Python wrapper since it's easier to explain that way in examples but the procedure is the same with curl.

1. Post a message via API.

logged_rocket.chat_post_message(
        "text1",
        channel="GENERAL",
    ).json()

3. Now try Responding to that message

logged_rocket.chat_post_message(
        "text2",
        channel="GENERAL",
        tmid=msg1_id,
    ).json()

Actual behavior:

The API will respond this to the second call:

{'error': "must have required property 'roomId'\n must NOT have additional properties\n must match exactly one schema in oneOf [invalid-params]", 'errorType': 'invalid-params', 'success': False}

Server Setup Information:

• Version of Rocket.Chat Server: 7.4 to 7.5
• License Type:
• Number of Users:
• Operating System:
• Deployment Method: Docker
• Number of Running Instances:
• DB Replicaset Oplog:
• NodeJS Version:
• MongoDB Version:

Client Setup Information

• Desktop App or Browser Version:
• Operating System:

Additional context

Relevant logs:

[ahmed-n-abdeltwab]

I will look into it.

[ahmed-n-abdeltwab]

There are two types of body for this API: channel and roomId. The tmid is included in the schema body of roomId, not channel, which is why this error is displayed.

[ahmed-n-abdeltwab]

The tmid field is described in the documentation as The ID of the thread to which the message belongs. I think it's more logical for the roomID to be require when using tmid

[jadolg]

The tmid field is described in the documentation as The ID of the thread to which the message belongs. I think it's more logical for the roomID to be require when using tmid

I think it should work with both as it was before though. Even if roomID makes more sense because it's not only about channels, the API should not break backwards compatibility unless properly deprecated.