Front-load Request Status in notifications

[rory-brenan]

Description

Hi there, love your work!

I have Discord notifications configured. Currently, the synopsis of the movie/show makes up most of the notification, and comes immediately after the title. This means that notifications (from Discord itself e.g. push notifications on my phone - as distinct from the notifications Overseerr is sending to Discord) are truncated and I can't really get any meaningful information from them without clicking through to see the full content in the Discord channel.

I would therefore prefer to see the Request Status be near the start of each notification.

In fact I don't personally need to see the synopsis at all in notifications, especially not after the initial request. Appreciate others may disagree. So detailed configurability of notification content would be a nice bonus.

Thankyou!

Desired Behavior

Request Status before media synopsis.

[Stretch goal 1] no synopsis. [Stretch goal 2] Granular control over notification content.

Additional Context

No response

Code of Conduct

• [x] I agree to follow Overseerr's Code of Conduct

[sleighton]

Can't you just use the Overseer Webhook notification instead of the predefined Discord notification to create a custom discord notification that meets your specific requirements?

[rory-brenan]

Hi, thanks for replying! I hadn't spotted that option...

I've just tried enabling it, using the same Discord webhook URL as my existing Discord notifications (with all notification types enabled, and the JSON payload as per default). Unfortunately both real and test notifications fail to send, with the reason given as "Request failed with status code 400","response":{"message":"Cannot send an empty message","code":50006} Am I missing something obvious?

[sleighton]

@rory-brenan Note that the default JSON will not work, it is not in discord's format for the notification. See below for possible issues to check.

Gemini AI responds as follows:

The error message "Request failed with status code 400" and "Cannot send an empty message" (code: 50006) from a Discord webhook indicates that the request sent to Discord was malformed or lacked the necessary content, even if the payload appeared to contain data.

Possible causes and solutions:

• Incorrect JSON structure:

Discord webhooks expect a specific JSON format. Ensure your payload adheres to this. For example, the message content should be within a "content" field at the top level of the JSON object. Incorrect: {"str": {"content": "message"}} Correct: {"content": "message"} Solution: Validate your JSON structure using an online JSON validator and ensure it matches Discord's webhook documentation.

• Missing required fields:

While you might have data, Discord requires at least one of content, embeds, components, or files to be present and non-empty in the request body. Solution: Verify that at least one of these fields contains valid data in your JSON payload. Invalid or unparseable JSON: Special characters, improper escaping, or missing brackets can lead to unparseable JSON, causing Discord to interpret the message as empty. Solution: Carefully check for syntax errors in your JSON, especially concerning quotes and special characters.

• Content-Type header:

The Content-Type header in your request must be set to application/json for Discord to correctly interpret the payload. Solution: Ensure your request includes the header: Content-Type: application/json.

• Encoding issues:

Certain characters, especially non-ASCII ones, might cause encoding problems if not handled correctly, leading to an empty message interpretation. Solution: Ensure your data is properly encoded, typically using UTF-8.

• Empty strings in variables:

If you are dynamically constructing the message content from variables, ensure those variables are not inadvertently empty when sent to Discord. Solution: Add checks in your code to ensure that the variables used to populate content or other fields are not empty before sending the webhook.

[rory-brenan]

Thanks, sounds like I'd need to read up on Discord's API documentation and adapt the JSON or create a new one from scratch.

Happy to look into that at some stage - although I think it highlights that a more user-friendly way to customise the native Discord notifications would be a nice feature for Overseerr. I'll leave it with your judgement whether to add this to your roadmap or leave it as an edge case where it's on the user to build their own custom JSON. Thanks again!